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

From: Joe Touch <[email-masked]>
Date: Thu, 22 Oct 1998 13:59:24 -0700 (PDT)

> From [email-masked] Thu Oct 22 13:53:24 1998
> Date: Thu, 22 Oct 1998 13:48:37 -0700
> From: "Eric A. Hall" <[email-masked]>
> X-Accept-Language: en
> To: [email-masked]
> Subject: Re: 'Slow-Start Restart after Idle' draft
> 
> 
> [Ignorant mode on.]
> 
> > In 2001.bis (draft-ietf-tcpimpl-cong-control-00.txt) we unambiguously
> > say that you SHOULD implement delayed ACKs and if you do, you MUST
> > ACK every second full-sized segment
> 
> My Caldera 1.3 system here sends one ACK for every seven segments, with
> no apparent loss in performance.
> 
> I take it the benefit of frequent ACKs is most pronounced when timing is
> a problem. What is the benefit to increasing the ACK frequency if the
> timing is solid?

ACK clocking is a pacing-like side-effect of producing ACKs
on a consistent basis.

Sending reduced numbers of ACKs can generate line-rate bursts,
for the same reason as losing them, or allowing the window
to accumulate 'rights to send' without using it.

Joe

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Oct 1998 14:04:25 -0700

> Sending reduced numbers of ACKs can generate line-rate bursts,

"Can" is the operative word here. This assumes that throughput or other
factors will cause the processing cycles to get out-of-synch. But what
if the network is running great? It seems that if the recipient can ACK
every six or seven segments without the two end-points getting out of
synch, it should be allowed to do so.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Oct 1998 14:33:17 -0700

> It seems that if the recipient can ACK every six or seven segments
> without the two end-points getting out of synch, it should be allowed
> to do so.

It seems like the need for ACKs is a function of the RTT and the size of
the receive buffer. ACKs should only be required if (a) the receive
buffer is half it's normal capacity or (b) if the time required to
deliver the ACK would cause the sender to stop transmitting before the
ACK was received.

Fixing the value to two seems kind of arbitrary.

[Ignorant mode is still on, btw].

---

From: [email-masked] (Sam Manthorpe)
Date: Thu, 22 Oct 1998 16:00:31 -0700 (PDT)

> Fixing the value to two seems kind of arbitrary.

I beleive the reason for the value two is to avoid the situation where
the rate at which the congestion window increase during slow-start and 
congestion avoidance is limited to one increment every 200ms (i.e. when 
the delayed-ack timer expires).  If we don't force acks and simply rely
on the delayed-ack timer then we can see very serious performance
degradation during slow-start.

-- Sam

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

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Oct 1998 16:18:11 -0700

> the rate at which the congestion window increase during slow-start

My comments are in regard to post-start. IE, once slow-start has brought
the two end-points up to full throttle.