[e2e] Are we doing sliding window in the Internet?

Joe Touch touch at ISI.EDU
Wed Jan 3 14:08:32 PST 2007

Wesley Eddy wrote:
> On Tue, Jan 02, 2007 at 10:07:48PM -0800, Joe Touch wrote:
>> Lachlan Andrew wrote:
>>> Greetings,
>>> This is probably not related to the original thread (on what happens
>>> in real networks, as distinct from what *should* happen), but the word
>>> "bug" bugged me...
>>> On 02/01/07, Joe Touch <touch at isi.edu> wrote:
>> ...
>>>>> delayed ACKs (as Linux receivers don't when the window is small),
>>>> Delayed ACKs are strongly encouraged.
>>>> Both good reasons to fix these bugs in Linux.
>>> I don't follow the logic of that at all.
>> Please review RFC2581.
> The exact wording in RFC 2581 says that ACKs should be sent "at least" for
> every 2 packets, which allows for an ACK to be sent for every packet, as
> Linux does when it assumes the other side is in slow start.  I believe the
> Linux behavior is perfectly allowable under the letter of RFC 2581.  I do
> not consider this behavior buggy whatsoever.

The exact wording from 2581:

   The delayed ACK algorithm specified in [Bra89] SHOULD be used by a
   TCP receiver.  When used, a TCP receiver MUST NOT excessively delay
   acknowledgments.  Specifically, an ACK SHOULD be generated for at
   least every second full-sized segment, and MUST be generated within
   500 ms of the arrival of the first unacknowledged packet.

The first sentence regards the use of delayed ACKs, which Bra89 defines as:
            A host that is receiving a stream of TCP data segments can
            increase efficiency in both the Internet and the hosts by
            sending fewer than one ACK (acknowledgment) segment per data
            segment received; this is known as a "delayed ACK" [TCP:5].

I.e., "delayed ACK" *means* sending fewer than one ACK per received

The second sentence from 2581 says not to excessively delay ACKs just do
do delays; the subsequent sentences refer situations that arise due to
holding back on ACKs.

The paragraph in its entirety means that
	- when there are no losses or substantial delays, TCP SHOULD
	ACK *exactly* every other packet

	- when there are losses or delays, more ACKs can be sent to
	avoid withholding feedback

Granted, 'every two' is a SHOULD not a MUST, but that's the only place
for Linux's behavior to be considered compliant. I don't see sufficient
reason in "well, it makes *us* go faster" to warrant overriding SHOULD.

> One separate thing to note with regards to ABC is that the RFC2581bis
> document in TCPM right now RECOMMENDS to increase CWND by the number of
> bytes ACKed during slow-start - i.e. ABC is RECOMMENDED by that document
> intended as an update to RFC 2581.

*When* that doc comes out, then the status of ABC may need to be
updated. Until then, widespread default use of ABC is not appropriate.


Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/2a55e617/signature-0001.bin

More information about the end2end-interest mailing list