Subject: Re: slow-start bit

From: David Borman <[email-masked]>
Date: Mon, 17 May 1999 12:15:39 -0500 (CDT)

John,

> Subject: Re: slow-start bit 
> Date: Sat, 15 May 1999 11:05:38 -0700
> From: John Hanley <[email-masked]>
> ...
> How about just causing the receiver to never delay ACK if more than
> `threshold' time has elapsed since the last ACK sent by the receiver?
> Certainly `threshold' would be < 200ms; I'm thinking around 100ms or 50ms.
> If it is much less than sender's RTO interval, then receiver would effectively
> suppress delayed ACK *without* the sender signaling that in an option bit.

Many years ago I put the slow-start code into UNICOS.  The poor
interaction between the initial packet during slow-start and the
delayed ACK/ACK every other packet stratagey became quite obvious,
both at connection startup and after the connection had been idle
for awhile and the sender restarted slow-start.  There are two ways
to address this.  Either the receiver doesn't delay ACKs during
slow-start, or the sender sends more than 1 packet to get past the
ack every other packet strategy.

I figured that I couldn't change all the other TCPs out there, and
since either one will improve throughput, I implemented the reciever
changes.  When a connection was first opened, I immediatly acked the
first N packets (actually, first N*maxseg bytes) , and then went back
to the ack-every-other-packet strategy.  I chose N=8 for no particular
reason, other than it was a power of 2, and 16 seemed too big.  I didn't
just use N=2, because it helps to get through slow-start when you ACK
every packet, and with N=8 you can get through a couple of round-trip
times before going back to ack-every-other-packet.  It worked fine, so
there never was any reason to change it.

The actual implementation took IRS and added N*maxseg to it.  As long
as data arrived with a seq number less than that, it was immediatly
acked.  Once we passed that point, the pointer was pulled along
equal to seg.rcv_next.  Then, in TCP input, if the idle counter
got large enough to kick in slow-start, I reset the value to
seg.rcv_next + N*maxseg, so that packets would be immediatly ACKed
again.

The nice thing was that with these changes our throughput improved
both in Cray->Cray transfers, and other->Cray transfers.

Combine those receiver changes with the new initial window of 4K,
(see RFC 2414), and you can eliminate a lot of the artificial
delays due to bad delayed ACK interaction.

I don't see a need for a "slow start" bit.  Effectivly it would be
a "please ACK immediatly" bit, and would be ripe for abuse by
setting it in every packet, in which case you'd have to put in code
to determine whether or not the bit is legitimate, which by the
way would be similar code to what I've just described, so just
skip the bit.

			-David Borman, [email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 17 May 1999 12:30:20 -0700 (PDT)

> seg.rcv_next + N*maxseg, so that packets would be immediatly ACKed

Just curious, besides UNICOS, have you put it into other stacks, like BSDI?
I am wondering how common this is, and if it is a good idea for people to
implement that.

							K. Poon.
							[email-masked]

---

From: Rick Jones <[email-masked]>
Date: Mon, 17 May 1999 14:01:11 -0700

> I am wondering how common this is, and if it is a good idea for people to

I've seen evidence that perhap sLinux and HP-UX 11 will immediately ack
at least the first segment received. I've not looked for anything beyond
that.

rick jones

-- 
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, or post, but please do not do both...
my email address is raj in the cup.hp.com domain...

---

From: "David S. Miller" <[email-masked]>
Date: Mon, 17 May 1999 15:08:31 -0700

Date: Mon, 17 May 1999 14:01:11 -0700
   From: Rick Jones <[email-masked]>

   > Just curious, besides UNICOS, have you put it into other stacks,
   > like BSDI?  I am wondering how common this is, and if it is a
   > good idea for people to implement that.

   I've seen evidence that perhap sLinux and HP-UX 11 will immediately
   ack at least the first segment received. I've not looked for
   anything beyond that.

On Linux we implemented things this way because if hosts handle the
initial congestion window values correctly (ie. don't advance it for
the initial SYN, unfortunately almost all stacks do) this is quite
desirable behavior.

Later,
David S. Miller
[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 17 May 1999 15:27:52 -0700 (PDT)

> the initial SYN, unfortunately almost all stacks do) this is quite

Oh, I was not just asking if TCP would ack the first segment.  I think many
stacks already did that.  David changed UNICOS not to delay any ack for the
first N=8 segments.  This I do not believe is quite common.  Is it?

							K. Poon.
							[email-masked]

---

From: "David S. Miller" <[email-masked]>
Date: Mon, 17 May 1999 16:42:05 -0700

Date: Mon, 17 May 1999 15:27:52 -0700 (PDT)
   From: Kacheong Poon <[email-masked]>

   > On Linux we implemented things this way because if hosts handle
   > the initial congestion window values correctly (ie. don't advance
   > it for the initial SYN, unfortunately almost all stacks do) this
   > is quite desirable behavior.

   Oh, I was not just asking if TCP would ack the first segment.  I
   think many stacks already did that.

I believe several also do not, to match up with the "SYN congestion
window" bug.

   David changed UNICOS not to delay any ack for the first N=8
   segments.  This I do not believe is quite common.  Is it?

This is not common as far as I am aware.  Perhaps it is done to jack
up the congestion window quickly over high speed links?

Later,
David S. Miller
[email-masked]

---

From: Andi Kleen <[email-masked]>
Date: Tue, 18 May 1999 03:50:44 +0200

> first N=8 segments.  This I do not believe is quite common.  Is it?

Linux 2.2 acks the first segment after slow start (this means at the beginning
or when an ooo or old segment has been seen)

-Andi
-- 
This is like TV. I don't like TV.