[Bloat] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

[Bloat] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

[Rich Brown]

https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps_In_v1.pdf

Re: [Bloat] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

[Neal Cardwell]

On Thu, Oct 20, 2016 at 8:15 AM, Rich Brown <richb.hanover@gmail.com> wrote:
>
> https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps_In_v1.pdf

Regarding these passages from the slide deck:

   What do the results suggest?
   ....
   There may be a tradeoff between upload latency
   and upload throughput, and that tradeoff is
   not necessarily linear: there may be a “sweet spot”
   where latency is noticeably reduced, while the
   impact on throughput is negligible

   What happens next?
   ....
   Fixed buffer size setting impractical for scaled usage

I would agree that there is a delay/throughput "sweet spot", one that
varies across network scenarios. BBR congestion control is
specifically designed to dynamically estimate the bandwidth and delay
characteristics of the path, to estimate where that "sweet spot" is,
and operate near it.

The BBR paper ( currently on the ACM Queue site -
http://queue.acm.org/app/ ) has a diagram and discussion related to
this non-linear delay/throughput trade-off that the presentation
mentions.

neal

Re: [Bloat] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

[Mario Hock]

Hi altogether,

Am 20.10.2016 um 16:44 schrieb Neal Cardwell:
> On Thu, Oct 20, 2016 at 8:15 AM, Rich Brown <richb.hanover@gmail.com> wrote:
>>
>> https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps_In_v1.pdf
>
> Regarding these passages from the slide deck:
>
>    What do the results suggest?
>    ....
>    There may be a tradeoff between upload latency
>    and upload throughput, and that tradeoff is
>    not necessarily linear: there may be a “sweet spot”
>    where latency is noticeably reduced, while the
>    impact on throughput is negligible
>
>    What happens next?
>    ....
>    Fixed buffer size setting impractical for scaled usage

Opinions may vary in what one considers as "sweet spot", but if it is 
the minimal buffer size that results in full throughput for a single TCP 
flow, the buffer size must be:

1.0 * Bandwidth-Delay-Product for TCP Reno and
0.43  * Bandwidth-Delay-Product for Cubic TCP

with Bandwidth-Delay-Product as base RTT (i.e., RTT without queuing 
delay) * bottleneck capacity.

This means that the required buffer strongly depends on your base RTT to 
the server (resp. the other end-point).

For a formula and a proof see:

W. Lautenschlaeger and A. Francini, "Global synchronization protection 
for bandwidth sharing TCP flows in high-speed links," 2015 IEEE 16th 
International Conference on High Performance Switching and Routing 
(HPSR), Budapest, 2015, pp. 1-8.
doi: 10.1109/HPSR.2015.7483103

Best Regards,

Mario Hock

Re: [Bloat] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

[Mikael Abrahamsson]

On Thu, 20 Oct 2016, Rich Brown wrote:

> https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps_In_v1.pdf

Does anyone understand what access speeds these customers had during these 
tests?

96 kilobyte buffer on 1 megabit/s upstream or 50 megabit/s upstream makes 
a big difference.

(I have 250/50 on my DOCSIS3.0 connection, but perhaps it's common 
knowledge what speeds Comcast customers typically has, that I don't know?)

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Bloat] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

[Klatsky, Carl]

On Thu, 20 Oct 2016, Rich Brown wrote:

> https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps
> _In_v1.pdf

Does anyone understand what access speeds these customers had during these tests?
[Carl Klatsky] For this trial, the customers were provisioned with 110 Mbps down / 10 Mbps up.

96 kilobyte buffer on 1 megabit/s upstream or 50 megabit/s upstream makes a big difference.

(I have 250/50 on my DOCSIS3.0 connection, but perhaps it's common knowledge what speeds Comcast customers typically has, that I don't know?)

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

I need to box my test unit up and return it, but my area has 160/12 service
if you get the upgraded rates (which I do)

-Aaron
On Thu, Oct 20, 2016 at 11:48 Klatsky, Carl <Carl_Klatsky@comcast.com>
wrote:

> On Thu, 20 Oct 2016, Rich Brown wrote:
>
> > https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps
> > _In_v1.pdf
>
> Does anyone understand what access speeds these customers had during these
> tests?
> [Carl Klatsky] For this trial, the customers were provisioned with 110
> Mbps down / 10 Mbps up.
>
> 96 kilobyte buffer on 1 megabit/s upstream or 50 megabit/s upstream makes
> a big difference.
>
> (I have 250/50 on my DOCSIS3.0 connection, but perhaps it's common
> knowledge what speeds Comcast customers typically has, that I don't know?)
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 2424 bytes --]

Re: [Bloat] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

[Dave Taht]

On Thu, Oct 20, 2016 at 11:12 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Thu, 20 Oct 2016, Rich Brown wrote:
>
>>
>> https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps_In_v1.pdf
>
>
> Does anyone understand what access speeds these customers had during these
> tests?

What that work showed was that basically all cablemodems had a fixed
upstream buffersize that is too large by factors of 25% to a factor of
10, and that 48Kbytes was a pretty good basic sweet spot... and if
they could just fix that across what's deployed life would get better
for everybody without fancy schmancy aqms... But we knew that
already....

http://www.dslreports.com/speedtest/results/bufferbloat?up=1

I note that I was called into consult a bit on this project and don't
feel at liberty at the moment to disclose their up/down parameters or
the direction of future work. Carl's nanog talk was filmed and there
were some interesting discussion afterwards about things like BBR.

https://www.youtube.com/watch?v=cA8FPHr8h7U&list=PLO8DR5ZGla8hcpeEDSBNPE5OrZf70iXZg&index=16

I was delighted that they used flent to exercise the connection(s).

> 96 kilobyte buffer on 1 megabit/s upstream or 50 megabit/s upstream makes a
> big difference.
>
> (I have 250/50 on my DOCSIS3.0 connection, but perhaps it's common knowledge
> what speeds Comcast customers typically has, that I don't know?)
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org