Subject: Slow start question ...

From: "Ramesh Shankar" <[email-masked]>
Date: Mon, 22 May 2000 08:50:48 -0600

If the peer to which a TCP connection has been established is on a "direct connected" network (i.e. the route doesn't point to a gateway), why exactly is slow start required? Linux and NetBSD seem to do slow start for this case while FreeBSD doesn't seem to (I haven't picked through the source to verify this though). Since slow start is meant to "probe the available network bandwidth" of a route (involving routers), it seems to me that I really shouldn't have to use slow start for the case mentioned above. 

One of the e-mails in this list mentioned a case where the outbound interface queue was overwhelmed by a burst of packets when slow start was not used. Slow start seems to be a wrong way to solve this problem. This problem could happen even when too many connections are opened, and hence is a fundamental inter-layer flow control problem.

Any insight would be greatly appreciated.

Thanks,

S.R.

---

From: Alan Cox <[email-masked]>
Date: Mon, 22 May 2000 17:56:30 +0100 (BST)

> If the peer to which a TCP connection has been established is on a "direct connected" network (i.e. the route doesn't point to a gateway), why exactly is slow start required? Linux and NetBSD seem…

Your definition of direct connected includes things like ATM networks, slow
dialup links, and even IPIP tunnels across the internet.

Are you telling me you dont want slow start on these ?

The fundamental flaw in your argument is to assume the routers are at IP level.
There are resource issues both on all networks including your own buffering
on modems, switches, bridges and other devices below the IP layer. The
slow start procedure makes us behave well to them as well.

Alan

---

From: Jamshid Mahdavi <[email-masked]>
Date: 22 May 2000 10:15:34 -0700

There is also no way of knowing what the layer 2 topology is.  For
example, you could be sending out of a 100 Mb/s interface, but the
receiver might only be on a 10 Mb/s interface.  These days, pretty
much anything can be bridged together; wireless, DSL, ATM, and more
could all be quietly masquerading as part of your "local ethernet".

Since there can be congestion on any of these transitions, it is still
necessary to do slowstart and congestion avoidance to hosts on the
local network.

--J

"Ramesh Shankar" <[email-masked]> writes:

> If the peer to which a TCP connection has been established is on a
> "direct connected" network (i.e. the route doesn't point to a
> gateway), why exactly is slow start required? Linux and NetBSD seem
> to do slow start for this case while FreeBSD doesn't seem to (I
> haven't picked through the source to verify this though). Since slow
> start is meant to "probe the available network bandwidth" of a route
> (involving routers), it seems to me that I really shouldn't have to
> use slow start for the case mentioned above.
> 
> One of the e-mails in this list mentioned a case where the outbound
> interface queue was overwhelmed by a burst of packets when slow
> start was not used. Slow start seems to be a wrong way to solve this
> problem. This problem could happen even when too many connections
> are opened, and hence is a fundamental inter-layer flow control
> problem.
>

---

From: Jan Koum <[email-masked]>
Date: Mon, 22 May 2000 21:59:18 -0700

looking at freebsd, it seem that slowstart *is* disabled for local
network:

$ sysctl -a|grep slowstart
net.inet.tcp.slowstart_flightsize: 1
net.inet.tcp.local_slowstart_flightsize: 65535

this is probably correct for 95% of the time, since having bridged
wireless and atm are not very common. but you are right, to be 100%
correct, freebsd should probably also have local slowstart enabled.

-- yan

---

From: Michele Clark <[email-masked]>
Date: Tue, 23 May 2000 12:30:56 -0400

Which version are you running?  

In FreeBSD 2.2.8, there's a sysctl option 
net.inet.tcp.no_local_slowstart.  It's default value is 0, I
believe, which forces slow start on the local network.  (This option
wasn't present before 2.2.8.)

-Michele

---

From: Luigi Rizzo <[email-masked]>
Date: Tue, 23 May 2000 18:57:24 +0200 (CEST)

> wasn't present before 2.2.8.)

actually the default is as before so it does not do slow_start
on the local network (i.e. blasts a whole window of data at startup).
I introduced this because experiments with dummynet (where you
usally end up using local machines) would give unrealistic
results otherwise.

	cheers
	luigi

> > looking at freebsd, it seem that slowstart *is* disabled for local
-----------------------------------+-------------------------------------
  Luigi RIZZO, [email-masked]  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)
  Mobile   +39-347-0373137
-----------------------------------+-------------------------------------

---

From: Jan Koum <[email-masked]>
Date: Tue, 23 May 2000 10:41:58 -0700

my output is from 4.0 -- i didn't think there was a sysctl in earlier
versions since 3.x doesn't have a sysct:

        /*      
         * Don't force slow-start on local network.
         */     
        if (!in_localaddr(inp->inp_faddr))
                tp->snd_cwnd = mss;

but 2.2.x does seem to have a sysctl:

        /*
         * Don't force slow-start on local network.
         * Make this depend on the sysctl variable below
         */
        if (!no_local_slowstart || !in_localaddr(inp->inp_faddr))
                tp->snd_cwnd = mss;

and 2.1 does not have a sysctl:

        /*
         * Don't force slow-start on local network.
         */
        if (!in_localaddr(inp->inp_faddr))
                tp->snd_cwnd = mss;

with no_local_slowstart set to 0, this evaluates to true:
  (!no_local_slowstart || !in_localaddr(inp->inp_faddr)

so i think 2.2.8 (just like the comment indicates) does not force slow
start on the local network either.

-- yan