Re: [aqm] [tcpm] TCP ACK Suppression

David, On 10/11/2015 3:49 PM, David Lang wrote: >> One of the reasons we use packets is to provide more timely, >> fine-grained feedback between endpoints. Aggregating them at the source >> or in the network (rather than at the receiver) can amplify reaction to >> packet loss (when the aggregate

Re: [aqm] [tcpm] TCP ACK Suppression

On Tue, 13 Oct 2015, Joe Touch wrote: David, On 10/11/2015 3:49 PM, David Lang wrote: One of the reasons we use packets is to provide more timely, fine-grained feedback between endpoints. Aggregating them at the source or in the network (rather than at the receiver) can amplify reaction to

Re: [aqm] [tcpm] TCP ACK Suppression

On Mon, 12 Oct 2015, Greg White wrote: My contention is that since this is already happening, consolidating the ACK packets into stretched ACKs doesn't make this any worse, and it saves network bandwidth (and decreases latency to the extent that data is acked faster than waiting for the

Re: [aqm] [tcpm] TCP ACK Suppression

On Mon, 12 Oct 2015, Mikael Abrahamsson wrote: On Fri, 9 Oct 2015, Greg White wrote: On 10/9/15, 2:04 PM, "Mark Allman" wrote: 1) *you* shouldn't be using a mechanism that destroys information for others 2) *you* don't know where your mechanism will have an impact 3)

Re: [aqm] [tcpm] TCP ACK Suppression

On Fri, 9 Oct 2015, Greg White wrote: On 10/9/15, 2:04 PM, "Mark Allman" wrote: 1) *you* shouldn't be using a mechanism that destroys information for others 2) *you* don't know where your mechanism will have an impact 3) you claim this might be safe *if* AQM is widely

Re: [aqm] [tcpm] TCP ACK Suppression

The next generation of WiFi is likely to include full duplex - it's about the only physical layer thing left! Simon On 10/10/2015 4:12 PM, Jonathan Morton wrote: On 11 Oct, 2015, at 02:06, Dave Taht wrote: I would certainly have preferred a wifi world that instead of

Re: [aqm] [tcpm] TCP ACK Suppression

On Sat, 10 Oct 2015, David Lang wrote: On Fri, 9 Oct 2015, Joe Touch wrote: On 10/9/2015 10:58 PM, David Lang wrote: RFC3449 doesn't completely address the current situation, but it provides a very good place to start, and it seems to me that the solitions it explores to address the conerns

Re: [aqm] [tcpm] TCP ACK Suppression

> On 11 Oct, 2015, at 01:28, David Lang wrote: > >> So even if I could wave a magic wand and deploy this on every router, it >> would only have an effect in a few places. Endpoint links where the >> available bandwidth drastically changes are not the exclusive list of palces

Re: [aqm] [tcpm] TCP ACK Suppression

On 10/10/2015 4:06 PM, Dave Taht wrote: > I just wanted to say that I'm with dlang here... aggregated and > asymmetric transmits in wifi, cell, and cable, are here to stay. Deal > with it. Right until they're encrypted, then we'll be back to square 1. Time to deal with the case where the net

Re: [aqm] [tcpm] TCP ACK Suppression

On Sun, 11 Oct 2015, Jonathan Morton wrote: On 11 Oct, 2015, at 01:28, David Lang wrote: So even if I could wave a magic wand and deploy this on every router, it would only have an effect in a few places. Endpoint links where the available bandwidth drastically changes are

Re: [aqm] [tcpm] TCP ACK Suppression

On Sat, 10 Oct 2015, Joe Touch wrote: On 10/10/2015 4:06 PM, Dave Taht wrote: I just wanted to say that I'm with dlang here... aggregated and asymmetric transmits in wifi, cell, and cable, are here to stay. Deal with it. Right until they're encrypted, then we'll be back to square 1. Don't

Re: [aqm] [tcpm] TCP ACK Suppression

On Fri, 9 Oct 2015, Joe Touch wrote: On 10/9/2015 5:22 PM, David Lang wrote: You don't want to acknowlege it, but TCP is broken in the face of excessive buffering. Arguably, buffering was broken and failed to provide the feedback to TCP (see next paragraph) TCPM isn't fixing that,

Re: [aqm] [tcpm] TCP ACK Suppression

On Fri, 9 Oct 2015, Joe Touch wrote: If you have one person trying to watch streaming video while another person is uploading pictures to facebook, you can run into trouble at much more even ratios. Restated, you run into trouble because you sold a service you didn't provision for ;-) (or,

Re: [aqm] [tcpm] TCP ACK Suppression

accusing people of discussing in bad faith because of their business model, short sightedness, or other failing is not a good approach to take. This discussion started from AQM and the smart things that can be done on the data in the queues. If TCP is to remain purely "end to end" as you want

Re: [aqm] [tcpm] TCP ACK Suppression

On Fri, 9 Oct 2015, Joe Touch wrote: On 10/9/2015 3:02 PM, Greg White wrote: On 10/9/15, 2:04 PM, "Mark Allman" wrote: 1) *you* shouldn't be using a mechanism that destroys information for others 2) *you* don't know where your mechanism will have an impact 3) you claim

Re: [aqm] [tcpm] TCP ACK Suppression

On 10/9/2015 3:02 PM, Greg White wrote: > > > On 10/9/15, 2:04 PM, "Mark Allman" wrote: > >> >>> 1) *you* shouldn't be using a mechanism that destroys information for >>> others >>> 2) *you* don't know where your mechanism will have an impact >>> 3) you claim this might be

Re: [aqm] [tcpm] TCP ACK Suppression

On Fri, 9 Oct 2015, Joe Touch wrote: On 10/9/2015 7:14 PM, David Lang wrote: The problem with proposals like that is just like RFC3449 says, the source can't know what the network looks like to decide if there is a benefit to reducing ACKs. To understand your position, is your conclusion

Re: [aqm] [tcpm] TCP ACK Suppression

On 10/9/2015 1:04 PM, Mark Allman wrote: > >> 1) *you* shouldn't be using a mechanism that destroys information for others >> 2) *you* don't know where your mechanism will have an impact >> 3) you claim this might be safe *if* AQM is widely deployed > > tl;dr summary: myopia is why we can't