Subject: Re: 'Slow-Start Restart after Idle' draft

From: Joe Touch <[email-masked]>
Date: Thu, 22 Oct 1998 11:47:21 -0700 (PDT)

> From [email-masked] Thu Oct 22 11:37:39 1998
> From: [email-masked] (Raghu Mallena)
> Subject: 'Slow-Start Restart after Idle' draft
> To: [email-masked]
> Date: Thu, 22 Oct 1998 11:36:20 -0700 (PDT)
> Cc: [email-masked], [email-masked], [email-masked],
>         [email-masked] (Raghu Mallena)
> 
> 
> I have a couple of questions on draft-ietf-tcpimpl-restart-00.txt
> (Issues in TCP Slow-Start Restart After Idle) and I was hoping
> that either the authors(Amy Hughes, Joe Touch, John Hiedemann)
> or someone else on the tcp-impl group who read it or implemented
> it can clarify this for me. 
> 
> My main question is about the Congestion Window Monitoring (CWM)
> solution proposed to avoid bursts.   The draft talks about
> replacing the following lines in tcp_output():
> 
> 	idle = (snd_max == snd_una);
> 	if (idle && now - lastrcv >= rto)
> 		cwnd = 1; 
> 
> with
> 	maxwin = 4 + snd_nxt - snd_una;
> 	if (cwnd > maxwin)
> 		cwnd = maxwin;
> 
> This proposal does burst control as expected,  but I wanted to make 
> sure that it does not undercut the regular slow-start algorithm 
> during normal start up.  It would be really bad if it did  because 
> exponential window growth is highly desirable for high speed LAN 
> connections so that the stable max window size can be reached 
> as soon as possible.
> 
> I took some traces and noticed that the initial slow-start behaviour
> will not be compromised *if* Delayed Ack works as expected.
...
> But what if Delayed Ack does not work as well and you start getting
> one Ack for every N packets with N>2?  

That algorithm does not work well when ACKs are lost, or when
'delayed acks' is not correctly being followed (i.e., sending less
ACKs is not correct behavior; receiving less ACKs may occur, however).

> One reason I can think of why the smooth 2-for-1 Ack flow
> might not happen is because of the way some of the BSD-derived
> stacks are implemented.  

Have you seen this behavior, or is this a thought-experiment?

> In Header Prediction mode, tcp_input() 
> routine does not call tcp_output() directly which means that
> an ACK will not be sent out for the second packet immediately.
> Instead, the input routine wakes up the socket and the
> thread that wakes up then calls tcp_output() after removing
> the data from the socket buffer.   In the mean time,  if there
> were a bunch of other packets that came in,  all of them are
> ACKed *at once* in the output routine. 

'delayed ACKS' would require that there were at least one ACK
for every two full segments received correctly, regardless of
what other data arrived in the meantime. This would result in 
an ACK burst.

> Any comments?  The fact that CWM can backfire if the
> ACKs dont come in smoothly is quite subtle.   Should the draft
> talk about this dependence?   Any real world experience from
> implementors who have incorporated CWM into their stack?

We have a modification in progress, which merges the best aspects
of CWM and Floyd's Maxburst. It avoids the effect you observed above,
where ACK losses cause CWM to reduce its window unnecessarily.

However, it is also clear that most of the algorithms considered
encourage interleaving of send and receive processing. Stalling
that interleave generates bursts; these bursts are what we are trying
to avoid, regardless of the reason.

Joe

---

From: [email-masked] (Raghu Mallena)
Date: Thu, 22 Oct 1998 12:53:20 -0700 (PDT)

> Have you seen this behavior, or is this a thought-experiment?

Not a thought-experiment.  I have seen this happen very often while
working on Gigabit Ethernet driver and TCP/IP performance
tuning over it.    If I recollect correctly,   some traces 
showed one ACK for about every 10 packets or so at times.   This
was with no packet loss of any sort.  

> what other data arrived in the meantime. This would result in 

Host Requirements RFC (rfc1122) that describes Delayed Ack says
that "there SHOULD be an ACK for at least every second segment".
Note that its a SHOULD and not a MUST.  So its not really
incorrect behaviour for stacks to send a single ACK for all
the data received during the time the stack spends in
processing the second segment. (i.e wake up the socket etc
as I described above).    I know atleast two stacks that do
this and I wont be surprised if there are more. ( For reference,
Steven's TCP/IP vol-II describes a similar scheme as well). 

> where ACK losses cause CWM to reduce its window unnecessarily.

Cool!  I will give it a shot when its ready. 

> to avoid, regardless of the reason.

I am not sure that what I described above can be considered a
burst.   Anyway,  I just wanted to point out the dependency that
CWM has on Delayed Ack implementations so the authors are aware
of it incase this needs a mention in the draft. 

- raghu

---

From: [email-masked] (Sam Manthorpe)
Date: Thu, 22 Oct 1998 13:05:05 -0700 (PDT)

> what other data arrived in the meantime. This would result in 

The way I read it RFC-1122 does not `require' this, but rather
recommends it:

            A TCP SHOULD implement a delayed ACK, but an ACK should not
            be excessively delayed; in particular, the delay MUST be
            less than 0.5 seconds, and in a stream of full-sized
            segments there SHOULD be an ACK for at least every second
            segment.

-- Sam

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [email-masked]