[tcpm] Delayed ACKs vs. Nagle (was: RE: [aqm] TCP ACK Suppression)

["Scharf, Michael (Michael)" <[e-mail]>]

As far as I recall (Wes can correct me if I am wrong) we have an open issue in 793bis regarding that issue.

See draft-ietf-tcpm-rfc793bis-01 Section 4:

   11.  look at possible mention of draft-minshall-nagle (e.g. as in
        Linux)

The challenge is that for 793bis we would need a Proposed Standard RFC specifying how to sort out this interaction, unless we extend the scope of 793bis beyond what we agreed upon (i.e., only clarification, no protocol changes).

I have personally never looked at how that logic is actually implemented in different stacks, and I actually don’t know if there has ever been community consensus on how the exact solution to that interaction should look like.

But if we have a gap to what is widely implemented, and if it was realistic to publish a PS RFC before completing 793bis (I guess it could be a 2-page RFC), I’d argue in favor of a “fast track” PS publication. (Well, with ‘fast’ being relative to our normal PS publication speed.)

Michael


From: Yuchung Cheng [mailto:[e-mail]]
Sent: Saturday, October 10, 2015 2:19 AM
To: Praveen Balasubramanian
Cc: Richard Scheffenegger; Scharf, Michael (Michael); Wesley Eddy; Joe Touch; LAUTENSCHLAEGER, Wolfram (Wolfram); David Lang; [e-mail]
Subject: Re: [tcpm] [aqm] TCP ACK Suppression



On Fri, Oct 9, 2015 at 4:25 PM, Praveen Balasubramanian <[e-mail]<mailto:[e-mail]>> wrote:
Agreed that delayed ACK timeout should be a function of RTT than a hardcoded value. Windows 8 onwards this is the behavior for high latency connections. Windows Server uses a 1 msec delayed ACK timeout for low latency (datacenter) connections.

And while we are on the topic of delayed ACKs, the bad interaction between Nagling and delayed ACKs is well known. John Nagle's comment in HN which suggests a per connection logic to throttle delayed ACKs:
"If you're going to do that, it's a good time to fix delayed ACK as well. As is well known, the interaction between delayed ACKs and the Nagle algorithm is awful. This is a historical accident; I implemented one, the Berkeley guys implemented the other, and by the time I found out I was out of networking and involved with a small startup called Autodesk. So that never got fixed. Here's how to think about that. A delayed ACK is a bet. You're betting that there will be a reply, upon with an ACK can be piggybacked, before the fixed timer runs out. If the fixed timer runs out, and you have to send an ACK as a separate message, you lost the bet. Current TCP implementations will happily lose that bet forever without turning off the ACK delay. That's just wrong. The right answer is to track wins and losses on delayed and non-delayed ACKs. Don't turn on ACK delay unless you're sending a lot of non-delayed ACKs closely followed by packets on which the ACK could have been piggybacked. Turn it off when a delayed ACK has to be sent."
Well .. Mr. Nagle will be glad to learn that Linux has implemented his (or similar) idea for years. It's called QUICK_ACK. The decision window is a bit short and can use some tuning. But it is not "never" fixed.

Agree on that 500ms is ridiculous.


-----Original Message-----
From: tcpm [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Richard Scheffenegger
Sent: Friday, October 9, 2015 3:53 PM
To: Scharf, Michael (Michael) <[e-mail]<mailto:[e-mail]>>; Wesley Eddy <[e-mail]<mailto:[e-mail]>>; Joe Touch <[e-mail]<mailto:[e-mail]>>
Cc: LAUTENSCHLAEGER, Wolfram (Wolfram) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; David Lang <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tcpm] [aqm] TCP ACK Suppression

This might also be an opportunity to go more into the reasoning for the 500ms maximum...

Many implementations interpret  "the delay MUST be less than 0.5 seconds" to trigger the delayed ACK timer at 500ms (with this time a fixed, compile-time
value) - while it has been shown, that making that dynamic (or a based on RTT and pps might be a more efficient approach (especially during loss at end-of-stream), depending on the environment [1].

[I thought to have read a recent paper on tuning the delayed ACK timer down to 1ms in datacenter environments, but cann't find that now].

Best regards,
  Richard




[1] Altman, Eitan, and Tania Jiménez. "Novel delayed ACK techniques for improving TCP performance in multihop wireless networks." Personal Wireless Communications. Springer Berlin Heidelberg, 2003.


----- Original Message -----
From: "Scharf, Michael (Michael)" <[e-mail]<mailto:[e-mail]>>
To: "Wesley Eddy" <[e-mail]<mailto:[e-mail]>>; "Joe Touch" <[e-mail]<mailto:[e-mail]>>
Cc: "LAUTENSCHLAEGER, Wolfram (Wolfram)"
<[e-mail]<mailto:[e-mail]>>; "Greg White"
<[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>; "David Lang" <[e-mail]<mailto:[e-mail]>>
Sent: Friday, October 09, 2015 5:21 PM
Subject: Re: [tcpm] [aqm] TCP ACK Suppression


> Yes, I have realized today myself that 793bis lacks that section. I agree
> that ACK generation belongs into 793bis.
>
> 793bis actually may open an opportunity to rethink the exact wording that
> explains this SHOULD. Personally, I believe replacing this SHOULD is not
> an option for a bis document.
>
> But if deviations from that SHOULD are widely deployed in the meantime,
> 793bis could possibly comment on that. Also, having some informational
> reference could perhaps be an option.
>
> Michael
>
>
> -----Original Message-----
> From: Wesley Eddy [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Friday, October 09, 2015 3:45 PM
> To: Scharf, Michael (Michael); Joe Touch
> Cc: LAUTENSCHLAEGER, Wolfram (Wolfram); Greg White; [e-mail]<mailto:[e-mail]>; David
> Lang
> Subject: Re: [tcpm] [aqm] TCP ACK Suppression
>
> On 10/9/2015 5:21 AM, Scharf, Michael (Michael) wrote:
>> [Removing AQM, adding TCPM]
>>
>>
>>
>> Hi Joe,
>>
>>
>>
>> I don't find this text in RFC 793, but it is contained in RFC 2581,
>> which is obsolete by RFC 5681.
>>
>>
>
>
> To confuse matters further, there's also 1122 text with requirements
> language:
>
>            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.
>
> This probably belongs in 793bis.  In my view, normative acknowledgement
> behavior belongs in the base spec rather than particular congestion
> control descriptions, since there may be more than CC that depends upon it
> or makes assumptions about it.
>
>
> --
> Wes Eddy
> MTI Systems
>
> _______________________________________________
> tcpm mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tcpm