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

From: Vern Paxson <[email-masked]>
Date: Fri, 23 Oct 1998 11:25:04 PDT

> Lots of ACKs are a Very Bad Thing on Ethernets.

Please back this up with further analysis.  I've put a tcpdump trace in

	ftp://ftp.ee.lbl.gov/.vp-100mbps.trace

This is an rcp along a 100 Mbps fast Ether link, with sufficiently large
windows to fill it.  The receiver for the most part acks every-second,
sometimes acking every third, and there's a periodic glitch in which it
generates stretch acks (doesn't affect the throughput).  Once the connection
reaches steady-state, it sustains upwards of 11 MB/s.

		Vern

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 23 Oct 1998 11:45:34 -0700

> Please back this up with further analysis.

There's lots of variables that affect the Badness of Frequent ACKs on
Ethernets. Half-duplex or full. Shared or switched. Network load. But
generally speaking, the more frames used for ACKs, the less frames can
be used for data. If you've got plenty of slots, there's no difference.
If you're tight on slots, there's lots of difference. Lots of nodes
sending lots of ACKs will definitely cut your data delivery rate.

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

---

From: Rick Jones <[email-masked]>
Date: Fri, 23 Oct 1998 11:48:17 -0700

> Please back this up with further analysis.  I've put a tcpdump trace in

Well, these days, the cycle processing of an ACK is little different
from the cycle processing of a data packet. Systems now have
copy-avoidance mechanisms, and interface cards with checksum offload
(CKO) functionality.

This makes most if not all of the CPU costs for say a web server
per-packet costs. Reducing the number of packets (eg ACKs) then
increases the capacity of the server.

An arbitrary reduction in ACKs is probably not a good idea. However, a
receiver which is able to figure-out when things are not flowing
smoothly and so ACKs with apropriate frequency at apropriate times would
probably not be such a bad thing.

A fixed choice of an ACK for every two MSS segments is merely a very
simple, straightforward, and "cheap" heuristic to arrive at an ACK rate
apropriate for the traffic conditions. I would certainly like
implementations to be free to use other equally robust mechanisms which
might happen to be cheaper in the free and clear case (such as LANs or
unloaded links). So, if future RFC's can state requirements of behaviour
without forcing a given ACK policy that might be best.

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