Re: [Bloat] [Cerowrt-devel] DC behaviors today

2017-12-12 Thread Jonathan Morton
This is also true in the consumer space, and is the reason why ISPs can save money by taking advantage of statistical multiplexing. On average, I personally could be satisfied with a megabit, but it's a real pain to download gigabyte-class software updates at that speed. If it takes me literally

Re: [Bloat] [Cerowrt-devel] DC behaviors today

2017-12-12 Thread dpreed
Luca's point tends to be correct - variable latency destroys the stability of flow control loops, which destroys throughput, even when there is sufficient capacity to handle the load. This is an indirect result of Little's Lemma (which is strictly true only for Poisson arrival, but almost

Re: [Bloat] benefits of ack filtering

2017-12-12 Thread Jonathan Morton
Actually, the cost argument goes the other way. You need heavy DSP to *receive* high bandwidths; sending it is much easier computationally. Also, in aggregate a hundred cheap CPE boxes probably have more DSP horsepower than the one head-end box serving them. What the centralised head-end has an

Re: [Bloat] benefits of ack filtering

2017-12-12 Thread David Lang
On Wed, 13 Dec 2017, Jonathan Morton wrote: The one "correct" argument against ack-filtering I've seen is that it encourages (or rather validates) the use of extreme asymmetry ratios. I would sure rather have a extremely asymmetric ration than a 'proper' ratio with the same upstream

Re: [Bloat] benefits of ack filtering

2017-12-12 Thread Jonathan Morton
The one "correct" argument against ack-filtering I've seen is that it encourages (or rather validates) the use of extreme asymmetry ratios. However, these extreme ratios are already in widespread use without the aid of ack-filtering. Even ADSL2 Annex A has, as its "ideal" sync rate, a 16:1

Re: [Bloat] benefits of ack filtering

2017-12-12 Thread Jonathan Morton
Taking into account a variety of scenarios, I have difficulty identifying a case where an ack deleted by a reasonably conservative algorithm would have given any practical benefit had it remained, *including* considerations of smoothness of ack-clocking. If the uplink isn't congested then no

Re: [Bloat] benefits of ack filtering

2017-12-12 Thread David Lang
On Tue, 12 Dec 2017, Benjamin Cronce wrote: I do not feel that thinning ACKs gains much for any healthy ratio of down:up. The overhead of those "wasteful" ACKs are on par with the overhead of IP+TCP headers. assuming that there was no traffic going the other way to compete with the acks.

[Bloat] quic's spin bit proposal

2017-12-12 Thread Dave Taht
in reading this https://blog.apnic.net/2017/12/12/internet-protocols-changing/ I stumbled across the "spin bit" idea being discussed in the ietf. https://tools.ietf.org/html/draft-trammell-quic-spin-00 In a world where quic is 7% of all traffic presently (wow, I didn't know)... -- Dave Täht

Re: [Bloat] benefits of ack filtering

2017-12-12 Thread Benjamin Cronce
On Wed, Nov 29, 2017 at 10:50 AM, Sebastian Moeller wrote: > Hi Mikael, > > > > On Nov 29, 2017, at 13:49, Mikael Abrahamsson wrote: > > > > On Wed, 29 Nov 2017, Sebastian Moeller wrote: > > > >> Well, ACK filtering/thinning is a simple trade-off: redundancy

Re: [Bloat] [Cerowrt-devel] DC behaviors today

2017-12-12 Thread Dave Taht
Luca Muscariello writes: > I think everything is about response time, even throughput. > > If we compare the time to transmit a single packet from A to B, including > propagation delay, transmission delay and queuing delay, > to the time to move a much larger amount

Re: [Bloat] [Cerowrt-devel] DC behaviors today

2017-12-12 Thread Luca Muscariello
I think everything is about response time, even throughput. If we compare the time to transmit a single packet from A to B, including propagation delay, transmission delay and queuing delay, to the time to move a much larger amount of data from A to B we use throughput in this second case because