[Bloat] BBR performance on LTE

[Sebastian Moeller]

> On Jan 22, 2019, at 23:00, Dave Taht <dave.taht at gmail.com> wrote:
> 
> btw, I didn't even remember we had a bloat-devel mailing list. please
> use bloat instead

And I thought we use the bloat list to talk about bloat and how to get rid of it and use bloat-devel exclusively to talk about developing bloat. I took the radio silence as indicator, that we agree that there is sufficient "high-quality" bloat around that further development was not required yet... ;)



> 
> On Tue, Jan 22, 2019 at 1:59 PM Azin Neishaboori
> <azin.neishaboori at gmail.com> wrote:
>> 
>> Dear Dave
>> 
>> Thank you for responding. I will email you the *.flent.gz files tomorrow and share the other plots here. Thank you for the advice to run tcp_nup and down tests. I can do those and report as well tomorrow.
>> 
>> 
>> Regarding your comment on the 200ms delay, well, the bbr paper published by the google team does mention the wifi and cellular LTE links. And the LTE links do have as documented higher delays, even higher under mobility. Yet the bbr paper claims that bbr works well for them as well.  But the LTE test results I have got so far do not seem very promising.
>> 
>> Thank you again for taking time and responding to my email. Tomorrow I will send further info as mentioned above.
>> 
>> Best
>> Azin
>> 
>> On Tue, Jan 22, 2019 at 4:07 PM Dave Taht <dave.taht at gmail.com> wrote:
>>> 
>>> I am a huge believer in also seeing the baseline *.flent.gz files and other plots you can get via the flent-gui... if you could post them somewhere or send to me privately? Two examples are obtaining the baseline RTT,
>>> and it would be my hope, over time, that BBR would have found the baseline RTT later in the test (the up or down bandwidth plots) than is shown by these summary plots. Also as much as I love the rrul tests for quickly showing the characteristics of a link under load, BBR makes the assumption that flows start up one at a time, and a better string of basic tests would be to use tcp_nup or tcp_ndown.
>>> 
>>> From squinting... It looks like the *baseline* RTT in this test is ~200ms.  There really isn't much in this world that works particularly well with RTTs this large.
> 
> 
> 
> -- 
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat