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

From: David Borman <[email-masked]>
Date: Sun, 7 Oct 2001 20:40:46 -0500 (CDT)

> Date: Sun, 07 Oct 2001 18:04:03 -0700
> From: Joe Touch <[email-masked]>
> Subject: Re: Why use Slow Start when destination is local?
...
> Tim Moors wrote:
>
> > Richard Stevens wrote in RFC 2001 and p. 311 of TCP Ill. vol.1 that the
> > Tahoe release of TCP "performed slow start only if the other end was on a
> > different network", but that this was changed with the Reno release of TCP
> > so that slow start was always performed.
> > 
> > Does anyone know why Tahoe didn't perform slow start for local
> > communication?  
>
>
> Slow start is designed to avoid overloading router queues; for a local 
> network, there is (presumably) no router to overload.

I seem to recall that one of the issues was that it has become harder
and harder in some network setups to reliably determine whether or not
the other host is on the local wire.  Bridges, proxy ARP, and VLANs are
but a few examples where you actually have a "router" between the hosts,
but just by looking at the address/netmask it would appear that they are
on the same wire.  Failure to do slowstart in these situations leads to
the same problems that slowstart was intended to solve.  So, by always
doing slowstart, you are no longer making any assumptions about the
underlying network setup.

			-David Borman, [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Sun, 07 Oct 2001 19:33:26 -0700

> underlying network setup.

Bridges don't queue like routers do, so shouldn't need slow start.

Proxy ARP and VLANs break the notion of what is local on a few levels; 
that they break this assumption too is not news. :-) That may be a 
reason to use them only in a limited and temporary fashion, rather than 
a reason to assume they are prevalent.

The bigger problem is the use of tunnels; it is reasonable to require 
that not only is the address 'local' but also is attached to a physical 
(vs virtual) interface.

This all does beg the question of how much slow start hurts in the local 
case, though. In CPU-limited regimes, it's a reason to turn off 
congestion control, but those regimes (where the CPU load of congestion 
control is substantial) aren't as common. It may still be a useful 
assumption for thin clients, but in general the benefit may not be 
worthwhile.

Joe

---

From: Julije Ozegovic <[email-masked]>
Date: Mon, 08 Oct 2001 09:25:38 +0200

Hi!

Consider also modem gateways.

I remember problems using DECstation 5000 workstations running 
ULTRIX V4.2a rev47 OS on LAN, and Cisco CS500 gateway with 
V.22bis (2400 b/s) modems attached.

Measurement traces from 1995 show that up to 10 (ten) 
unnecessary retransmissions were generated per segment. This was 
mainly the consequence of large RWIN regarding the BD product, 
(and was solved accordingly), but lack of slow start did not help!

Julije Ozegovic
http://www.fesb.hr/~julije

Joe Touch wrote:

>>> Slow start is designed to avoid overloading router queues; for a 
>>> local network, there is (presumably) no router to overload.
>>>
>>

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 08 Oct 2001 10:07:31 -0400

>Bridges don't queue like routers do, so shouldn't need slow start.

That assertion is certainly no longer true, if it ever was true.

>Proxy ARP and VLANs break the notion of what is local on a few levels; that they break this assumption too is not news. :-) That may be a reason to use them only in a limited and temporary fashion, rather than a reason to assume they are prevalent.

Be conservative in what you send...

Ran

---

From: Alan Cox <[email-masked]>
Date: Mon, 8 Oct 2001 16:05:28 +0100 (BST)

> Bridges don't queue like routers do, so shouldn't need slow start.

You forgot the word "Some"

Lots of el cheapo bridges queue.

Alan

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Oct 2001 09:23:49 -0700

> Be conservative in what you send...

This refers to the _implementation_ of a protocol. Be conservative in 
_what_ you send, not _how much_. It goes back to 1980, long before 
congestion control was added.

If we were really conservative in everything we wouldn't find path MTUs 
by sending large-packet probes.

There are a number of places where the Internet protocols interpret 
links as different from paths, and treat links more aggressively. Most 
notably among these is broadcast and subnet-directed broadcast.

As I said above, there are lots of protocols that break what proxy ARP 
and VLANs try to do. Revisionist redesign of the Internet architecture 
to support these newer tricks isn't going to help, though.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Oct 2001 10:13:14 -0700

RJ Atkinson wrote:

> At 12:23 08/10/01, Joe Touch wrote:

>>There are a number of places where the Internet protocols interpret links 
>>as different from paths, and treat links more aggressively. Most notably 
>>among these is broadcast and subnet-directed broadcast.
>>
> 
> Both of which are being killed off in IPv6.  Wonder why ?
> Now you know.

I now know why IPv6 isn't being widely deployed too :-))

Joe

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 08 Oct 2001 12:56:00 -0400

At 12:23 08/10/01, Joe Touch wrote:

>_what_ you send, not _how much_. It goes back to 1980, long before congestion control was added.

Traditionally, this concept has also referred to how much one sends.

>If we were really conservative in everything we wouldn't find path MTUs by sending large-packet probes.

        Conservative is meant in the sense of not harming the shared 
resources.   PMTU probing does not cause such harm.

Ran