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

[Joe Touch]

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

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

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