Subject: Why use Slow Start when destination is local?

From: "Tim Moors" <[email-masked]>
Date: Sun, 7 Oct 2001 17:44:55 -0400

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?  Was there a reason for this, or was it just a mistake that
was corrected in Reno?  Is the following justification valid?: MAC protocols
(e.g. Ethernet) often control congestion for link-local communication,
making transport layer congestion control unnecessary for local
communication.

(I searched the archives, and the only discussion I found of this topic was
in Mar 1997, where the definition of "local" was queried: local to a LAN, or
local to a subnet as defined by the address class.  That discussion didn't
address WHY there should be no SS for local communication.)

Tim Moors
___________________________________
Web: http://uluru.poly.edu/~tmoors/

---

From: Joe Touch <[email-masked]>
Date: Sun, 07 Oct 2001 18:04:03 -0700

Hi, Tim,

First, can we move this thread to the TSVWG mailing list? I thought 
TCPIMPL was closed as a WG, and this is definitely relevant to ongoing 
work in TSVWG.

Tim Moors wrote:

> communication?  

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

> Was there a reason for this, or was it just a mistake that

> communication.

Ethernet doesn't control congestion. Its backoff deals only with 
collisions, which shouldn't (or can't?) occur on full-duplex links anyway.

> address WHY there should be no SS for local communication.)

This was raised at the Minneapolis IETF in a hallway discussion with 
Reiner Ludwig and Andrei Gurtov, who posted the attached note to the 
freebsd-net mailing list; I think Andrei's goal was to find the origin 
of the code, though.

Joe

----------------

Date: Tue, 17 Apr 2001 18:04:38 +0300 (EET DST)
From: Andrei Gurtov <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: initial congestion window
Sender: [email-masked]

Hi folks,

 At the last IETF meeting there were some debates around FreeBSD using a
16-KB initial congestion window in TCP when destination IP address is from
the local subnet. Does anybody remember when it was introduced into the
code and what kind of ideas were behind?

Some reasons were given why it may not be a good idea:

-the benefit of not having slow start on LANs is very small, i.e. some
milliseconds

-it is not a conformant TCP feature, i.e. not allowed by TCP Congestion
Control (RFC2581) and is explicitly given in Known TCP Implementation
Problems (RFC2525) "2.1 No initial slow start" and "2.3 Uninitialized
CWND"

-people may have the same subnet mask also over a slow PPP link. In this
case the effect of the huge initial window is quite bad, see for example
http://www.cs.Helsinki.FI/u/gurtov/papers/effect_of_delays_on_tcp_performance.pdf

-in case of congestion on Ethernet, packets queues build up at the
network interfaces in hosts and agressive TCP start-up behaviour can
further increase congestion losses

What are your thoughts on this?

Andrei

tcp_output.c:

int ss_fltsz = 1;
SYSCTL_INT(_net_inet_tcp, OID_AUTO, slowstart_flightsize, CTLFLAG_RW,
        &ss_fltsz, 1, "Slow start flight size");

int ss_fltsz_local = TCP_MAXWIN;               /* something large */
SYSCTL_INT(_net_inet_tcp, OID_AUTO, local_slowstart_flightsize,
CTLFLAG_RW,
        &ss_fltsz_local, 1, "Slow start flight size for local networks");

[...]
                if (
                     in_localaddr(tp->t_inpcb->inp_faddr)
                    )
                        tp->snd_cwnd = tp->t_maxseg * ss_fltsz_local;
                else
                        tp->snd_cwnd = tp->t_maxseg * ss_fltsz;

To Unsubscribe: send mail to [email-masked]
with "unsubscribe freebsd-net" in the body of the message

---

From: "Andrei Gurtov" <[email-masked]>
Date: Mon, 8 Oct 2001 15:06:07 +0300

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Joe
> Touch
> Sent: 8. lokakuuta 2001 4:04
> To: Tim Moors
> Cc: [email-masked]; [email-masked]
> Subject: [Tsvwg] Re: Why use Slow Start when destination is local?
>
>
> Hi, Tim,
>

...

> freebsd-net mailing list; I think Andrei's goal was to find the origin

Yes, and I tried to convince FreeBSD folks that blasting a full receive
window instead of doing a slow start is not a good idea.  The discussion in
freebsd-net can be found at
http://docs.freebsd.org/mail/archive/2001/freebsd-net/20010422.freebsd-net.h
tml

I agree with David that having the same subnet mask does not necessary mean
the hosts are connected with Ethernet. It could be WLAN or something else
slower than Ethernet. Also, the receiver can be busy or slow and sending a
huge burst to it can leads to packets being discarded.

Some other reasons were given why a huge initial window may not be a good
idea:

-people may have the same subnet mask also over a slow PPP link. In this
case the effect of the huge initial window is quite bad, see for example
http://www.cs.Helsinki.FI/u/gurtov/papers/effect_of_delays_on_tcp_performanc
e.pdf

-in case of congestion on Ethernet, packets queues build up at the
network interfaces in hosts and aggressive TCP start-up behaviour can
further increase congestion losses

Andrei

---

From: Alan Cox <[email-masked]>
Date: Mon, 8 Oct 2001 15:43:24 +0100 (BST)

> http://docs.freebsd.org/mail/archive/2001/freebsd-net/20010422.freebsd-net.h

I agree - it isnt a good idea for a variety of reasons.

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.

Its one of those ideas that only looks good in a paper

Alan

---

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

Andrei Gurtov wrote:

...
> -the benefit of not having slow start on LANs is very small, i.e. some

Milliseconds on a link with microsecond delays are enormous, BTW.

> Problems (RFC2525) "2.1 No initial slow start" and "2.3 Uninitialized

FWIW, RFC2525 refers to the complete omission of slow start 
specifically. It never refers to disabling it on specific links, even 
though this was in the code at the time.

> http://www.cs.Helsinki.FI/u/gurtov/papers/effect_of_delays_on_tcp_performanc

There are, BTW, a few other bits of code that depend on 'local' vs. 
'remote', as interpreted by the subnet and the interfaces, notably:

	- MSS default

	- SYN/SYNACK piggybacking for T/TCP
		(delaying the SYN/SYNACK when there was data in
		the SYN and the connection is local)

> further increase congestion losses

That's an odd interpretation of congestion. If all this is happening 
inside the host, it seems like something much more explicit should be 
happening between the NIC and the OS, rather than dragging TCP into the 
fray.

Joe

---

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

FWIW, I'm not advocating for retaining the "avoid slowstart on local 
links" code.

Just pointing out that:

	- it assumes links are different from paths
		as do many Internet protocols

	- the number of 'tricks' it defeats is not justification to
	  change it
		most of the tricks are as bad if not worse, and
		break in too many other ways

We need to be more careful about what we think is local, which might 
also include more careful use of a notion of direct connection when it 
isn't in fact direct.

Joe

---

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

> 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.)

> 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 :-)

Joe

---

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

Pablo Molinero Fernandez wrote:

> Joe Touch wrote:
> If we take into account several user space/kernel space switches of some 
> milliseconds in both the sender and the receiver, 

That's a very slow switch. Should be in the 10's of microseconds.

> that the transmission 
> time of a full frame in each 10-Mbit segment is 1.2 ms, 

That's for data...

> that we need one SYN/SYN-ACK handshake before we can pass the 
> information to the end-user

SYN/SYN-ACKs don't have full frames of data :-)

Joe

---

From: Pablo Molinero Fernandez <[email-masked]>
Date: Mon, 08 Oct 2001 11:36:58 -0700

If we take into account several user space/kernel space switches of some 
milliseconds in both the sender and the receiver, that the transmission 
time of a full frame in each 10-Mbit segment is 1.2 ms, and the fact 
that we need one SYN/SYN-ACK handshake before we can pass the 
information to the end-user, then the increase of some ms in the 
completion time has a smaller impact than suggested.

Pablo Molinero