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

[Yuchung Cheng <[e-mail]>]

On Sun, Oct 11, 2015 at 7:41 AM, Scharf, Michael (Michael)
<[e-mail]> wrote:
> 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.)
I am not sure what your concern is: are you concerned Minshall's
revision to Nagle's algorithm on the sender would interact badly with
Mr. Nagle's idea to improve delayed-ACKs at the receiver?

>
>
>
> 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]> 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]] On Behalf Of Richard Scheffenegger
> Sent: Friday, October 9, 2015 3:53 PM
> To: Scharf, Michael (Michael) <[e-mail]>; Wesley
> Eddy <[e-mail]>; Joe Touch <[e-mail]>
> Cc: LAUTENSCHLAEGER, Wolfram (Wolfram)
> <[e-mail]>; [e-mail]; David Lang
> <[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]>
> To: "Wesley Eddy" <[e-mail]>; "Joe Touch" <[e-mail]>
> Cc: "LAUTENSCHLAEGER, Wolfram (Wolfram)"
> <[e-mail]>; "Greg White"
> <[e-mail]>; <[e-mail]>; "David Lang" <[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]]
>> Sent: Friday, October 09, 2015 3:45 PM
>> To: Scharf, Michael (Michael); Joe Touch
>> Cc: LAUTENSCHLAEGER, Wolfram (Wolfram); Greg White; [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]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>