Subject: Re: [Tsvwg] Re: Why use Slow Start when destination is local?

From: Vernon Schryver <[email-masked]>
Date: Mon, 8 Oct 2001 17:21:21 -0600 (MDT)

> > Firstly not every switch or bridge is exactly 100% quality
> > Secondly your slow start congestion avoidance is avoiding on wire congestion
> > Thirdly your local "network" on an interface can be many weird and wonderful
> > things - ATM lane, frame cloud, SMDS even PPP bridging - none of which react
> > well to being blasted with data causing congestion.
>
> The number of ways some of those break the Internet architecture is 
> long, starting with the lack of true broadcast (defeating ARP, RIP, etc.)

Really?  So nothing but LANs implement the "Internet architecture."

Similar objections apply to requiring tighter coupling between the
network interface and the network code than in classic sockets than
the driver discarding the packet with ENOBUFS on queue overflow..

>  
> > Its one of those ideas that only looks good in a paper
>
> The same could be said about ATM lane, frame clouds, SMDS or PPP 
> bridging :-)

STREAMS (at least the shouted flavor) is another paper tiger, even if
the protocol code can in some implementations get back pressure from the
hardware driver's queue.

I think I read a claim in this thread that the reason to turn off slow
start had is related to CPU utilization.  Perhaps that's the case in
some implementations, but in my experience the reason you want to turn
off slow start on a LAN is that you don't want to waste a bunch of
RTT's running slowly.  That was painfully true even at 100 Mbit/sec.
At 1 Gbit/sec or 10 Gbit/sec, and with windows big enough to deal
with the large ratio of bandwidth/RTT and bandwidth/interrupt latency,
by the time you get the window slow-started-open, many TCP transfers
are finished.

Vernon Schryver    [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Oct 2001 17:11:06 -0700

> Really?  So nothing but LANs implement the "Internet architecture."

Lots of things expect either point-to-point or subnets; in the first 
case, you don't need the hardware address of the other end. In the 
latter, you do, in which case there has to be a way to find it.

The above generally break where they use subnets AND point-to-point links.

Joe

---

From: David Nicol <[email-masked]>
Date: Mon, 08 Oct 2001 20:26:06 -0500

> Vernon Schryver    [email-masked]

Maybe it would make sense to track good window size by peer 
rather than by connection?

-- 
                                           David Nicol 816.235.1187
                                            1,3,7-trimethylxanthine

---

From: Alan Cox <[email-masked]>
Date: Tue, 9 Oct 2001 12:49:47 +0100 (BST)

> rather than by connection?

What makes you think that different ports go via the same path or even to
the same host ? Both are routinely untrue (bulk routing via satellite with
interactive traffic going landlink, web caches by inktomi and friends)

Alan

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Oct 2001 08:31:04 -0700

> interactive traffic going landlink, web caches by inktomi and friends)

Same host? RFC1122.

Same path? There's nothing that requires that two packets to the same 
port go to the same path.

In short, the same rules that make tracking window size reasonable 
within a single connection.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Oct 2001 08:31:04 -0700

Same host? RFC1122.

Joe

---

From: David Nicol <[email-masked]>
Date: Wed, 10 Oct 2001 17:04:25 -0500

> ...

Okay, track by peer-port pair.  Are there really NAT points that
offer different MTU depending on which back-end peer is handling
this particular request?  Anyone working on HTTP over UDP?

-- 
                                           David Nicol 816.235.1187
                                            1,3,7-trimethylxanthine