Re: [aqm] ACK Suppression

> On Oct 8, 2015, at 11:34 AM, David Lang wrote: > >> If ack reductions are so very valuable, what's the chance of doing that on >> an end to end basis instead of in the network? > > a little less than the chance of shutting off IPv4 :-) Hey, we can dream, can't we? :-) >

Re: [aqm] ACK Suppression

On Thu, 8 Oct 2015, Fred Baker (fred) wrote: requiring changes to all the software on each end to enable this is wishful thinking. The major servers could get the update pretty promtly, but updating the client side?? not for a long time. Yes, of course. That said, consider trends like

Re: [aqm] ACK Suppression

On 10/7/2015 2:12 PM, Christian Huitema wrote: > On Wednesday, October 7, 2015 2:00 PM, dpr...@reed.com wrote: > >> That's the real engineering challenge. Modularity is your friend when >> engineering >> large systems with very broad requirements. Focusing on a very narrow >> issue,

Re: [aqm] TCP ACK Suppression

CC'ing TCPM on my responses to this thread... On 10/7/2015 8:50 AM, Francini, Andrea (Andrea) wrote: > How about the effect of ACK suppression on the growth of the > congestion window, for TCP sources where the trigger for window growth > is the arrival of an ACK, not the number of bytes it

Re: [aqm] TCP ACK Suppression

On 10/8/15, 3:27 PM, "Joe Touch" wrote: >CC'ing TCPM on my responses to this thread... > >On 10/7/2015 8:50 AM, Francini, Andrea (Andrea) wrote: >> How about the effect of ACK suppression on the growth of the >> congestion window, for TCP sources where the trigger for window

Re: [aqm] TCP ACK Suppression

On Thu, Oct 8, 2015 at 2:31 PM, David Lang wrote: > On Thu, 8 Oct 2015, Joe Touch wrote: > > On 10/7/2015 12:42 AM, LAUTENSCHLAEGER, Wolfram (Wolfram) wrote: >> ... >> >>> Is this topic addressed in some RFC already? >>> >> >> It's a direct violation of RFC793, which expects one

Re: [aqm] TCP ACK Suppression

On Thu, 8 Oct 2015, Joe Touch wrote: On 10/7/2015 12:42 AM, LAUTENSCHLAEGER, Wolfram (Wolfram) wrote: ... Is this topic addressed in some RFC already? It's a direct violation of RFC793, which expects one ACK for every two segments: 4.2 Generating Acknowledgments The delayed ACK algorithm

Re: [aqm] TCP ACK Suppression

On 10/8/2015 2:31 PM, David Lang wrote: > On Thu, 8 Oct 2015, Joe Touch wrote: > >> On 10/7/2015 12:42 AM, LAUTENSCHLAEGER, Wolfram (Wolfram) wrote: >> ... >>> Is this topic addressed in some RFC already? >> >> It's a direct violation of RFC793, which expects one ACK for every two >> segments:

Re: [aqm] TCP ACK Suppression

On Fri, 9 Oct 2015, Christian Huitema wrote: All that discussion is fun, but we should be careful to stay within the respective group charters. As far as AQM is concerned, the question is whether the group wants to standardize some kind of special handling of TCP ACK as part of queue

Re: [aqm] TCP ACK Suppression

Well, the only situation we are talking about is when an AQM function finds that there are multiple acks for one TCP session in it's queue. The dispute is if these acks are can be considered 'duplicates' (since the later ones will ack data for the earlier ones) and so can be 'deduped' or if

Re: [aqm] TCP ACK Suppression

On Thu, 8 Oct 2015, Joe Touch wrote: On 10/8/2015 3:29 PM, David Lang wrote: On Thu, 8 Oct 2015, Joe Touch wrote: On 10/8/2015 2:31 PM, David Lang wrote: On Thu, 8 Oct 2015, Joe Touch wrote: On 10/7/2015 12:42 AM, LAUTENSCHLAEGER, Wolfram (Wolfram) wrote: ... Is this topic addressed in

Re: [aqm] TCP ACK Suppression

On 10/08/2015 02:52 PM, Yuchung Cheng wrote: I would like to add that GRO also cause stretched ACKs (acking up to 64KB), and GRO is crucial to reduce cycles for +10Gbps transfers on some architectures. And they go back even further than GRO (or LRO) appearing in Linux. They go all the way

Re: [aqm] [tcpm] ACK Suppression

RFC3449 pointed to some of the reasons & problems with manipulating TCP ACKs, and could provide a useful background if people needed to get up to speed on the history... Gorry > I'm not sure why this discussion is happening on aqm@ instead of tcpm@... > I have added cpm to the cc line, and would

Re: [aqm] TCP ACK Suppression

On Fri, 9 Oct 2015, Christian Huitema wrote: On Thursday, October 8, 2015 5:43 PM, David Lang wrote: ... For example, in the fq_codel/cake development, we're finding that there are some transports that bundle very large numbers of packets together to send at one time in order to maximize the

Re: [aqm] TCP ACK Suppression

I like this suggestion - but it's only needed in the case where there are dup acks. Simon On 10/8/2015 7:09 PM, David Collier-Brown wrote: One short interjection: send at least two acks, separated by a time based on available packets and/or average noise-burst durations on links with noise

Re: [aqm] [tcpm] ACK Suppression

Ok, so it turns out that what we are talking about here is talked about explicitly in section 5.2.1 of RFC3449. It warns of increased sender burst sizes, but I really question if that's a valid concern in the cases that we are talking about here. The choice in these cases isn't to send more

Re: [aqm] ACK Suppression

I'm not sure why this discussion is happening on aqm@ instead of tcpm@... I have added cpm to the cc line, and would recommend that anyone responding to this thread do the same and remove aqm@. On Oct 7, 2015, at 2:13 PM, David Lang wrote: > So things that reduce the flow of

Re: [aqm] ACK Suppression

On Thu, 8 Oct 2015, Fred Baker (fred) wrote: I'm not sure why this discussion is happening on aqm@ instead of tcpm@... I have added cpm to the cc line, and would recommend that anyone responding to this thread do the same and remove aqm@. I don't know why it started here, but not everyone on