Re: BBR performance on LTE

[Dave Taht <dave.taht@gmail.com>]

btw, I didn't even remember we had a bloat-devel mailing list. please
use bloat instead

On Tue, Jan 22, 2019 at 1:59 PM Azin Neishaboori
<azin.neishaboori@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@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