Subject: RE: [newtrk] ... and, speaking of cruft ...

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Oct 2004 19:05:31 -0700

If all new protocols are required to use SRV signalling there is no problem
running out of port assignments, there will be no new assignments to be
made.

The list of port assignments would simply become yet another piece of legacy
cruft that does not require ongoing maintenance and thus does not create any
process burden.

The connection delay is not significant. If you look at the number of times
HTTP sites redirect at the TCP level the idea of doing it in DNS does not
look at all bad.

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Wednesday, October 06, 2004 8:50 PM
> To: Hallam-Baker, Phillip
> Cc: 'Harald Tveit Alvestrand'; Spencer Dawkins; NEWTRK Mailing List
> Subject: Re: [newtrk] ... and, speaking of cruft ...
> 
> 
> 
> On Oct 4, 2004, at 1:03 PM, Hallam-Baker, Phillip wrote:
> 
> > As far as I am concerned there is no reason to use reserved 
> ports. They
> > should be discontinued. 95% of the assignments are for applications 
> > that
> > will never be used by more than a handful of users.
> >
> > SRV made static port assignments obsolete. NAPTR went further.
> 
> uh, no.  SRV allowed new apps to determine at runtime to use a 
> non-default port.  it did not affect existing apps.  whether SRV was 
> actually a good idea is debatable, but there wasn't much risk 
> in trying 
> it as long as it didn't affect existing apps.  OTOH expecting 
> old apps 
> to honor SRV would clearly degrade interoperability.
> 
> NAPTR allows URIs to be mapped onto service locations via DNS, but 
> that's a separate issue.
> 
> both SRV and NAPTR slow down new connections, because they require 
> extra DNS lookups.  this can also affect reliability, especially if 
> additional servers have to be consulted.  (DNS is too unreliable and 
> too slow already, SRV and NAPTR make it worse.)
> 
> SRV also makes it difficult to monitor and/or intercept particular 
> kinds of traffic which is either good or bad depending on your 
> point-of-view.
> 
> Keith
> 
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Oct 2004 22:36:56 -0400

> The connection delay is not significant.

it's obvious you've never tried to measure it.

>  If you look at the number of times

well, it's not as if HTTP is inherently a good example of desirable 
protocol design.  the heavy use of redirects in HTTP does significantly 
affect both its latency and its reliability.

Keith

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 7 Oct 2004 06:22:39 -0500

> protocol design.  the heavy use of redirects in HTTP does 
> significantly affect both its latency and its reliability.
>
> Keith

And it's not as if anyone cares about HTTP snappiness, because if they 
did, pipelining would be (1) implemented in the 
80-percent-market-share browser and (2) enabled by default in all 
browsers, not just the cool ones ...

I HAVE measured the effect of resource-at-a-time requests over GPRS 
links. The thrill of watching 0.5-to-1.0-second RTTs for 30 
unpipelined GETs that retrieve 30-to-300-byte GIFs over a maximum of 
two simultaneous connections to a server cannot be understated :-)

But this is drifting off-topic for NEWTRK, and I'm not even sure my 
original question about IANA port assignments was ever ON-topic...

Spencer

.