[Make-wifi-fast] 30+ sec of miserable bufferbloat in wearOS

[Make-wifi-fast] 30+ sec of miserable bufferbloat in wearOS

[Dave Taht]

"When acting as a gateway proxy for a wearable, the phone dramatically
inflates the end-to-end (server to wearable) latency to 30+ seconds
due to its incurred “bufferbloat”. We then break down the end-to-end
latency into various components, and identify the root cause to be the
phone-side TCP receive buffer, whose configuration does not take into
account the path asymmetry between the wearable-phone path and the
phone-server path... " -
https://anikravesh.github.io/files/wearos-sigmetrics19.pdf

I am of course puzzled as to why they didn't look into sch_cake[1] or
fq_codel derived solutions[2], (it is a non-open source OS) but they
did manage to eliminate 97% of the problem in their paper, so, there's
that.

[1] https://arxiv.org/abs/1804.07617
[2] https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf
-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Make-wifi-fast] 30+ sec of miserable bufferbloat in wearOS

[Xiao Zhu]

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

Dear Dave Taht,

Thank you for pointing out those two great papers and paying attention to
our recent work.

In the context of wearable networking where the bottleneck is the Bluetooth
link between the smartphone and the smartwatch, the solutions you mentioned
can conceptually help to handle bottleneck queuing at lower layers, but it
could be hard to execute them given the Bluetooth stack in Android is very
different from that of WiFi/LTE and does not speak TCP/IP.

In our future bufferbloat-related work, we will definitely discuss more
related works, especially those you mentioned.


Best,
Xiao

On Sat, Apr 6, 2019 at 8:14 PM Dave Taht <dave.taht@gmail.com> wrote:

> "When acting as a gateway proxy for a wearable, the phone dramatically
> inflates the end-to-end (server to wearable) latency to 30+ seconds
> due to its incurred “bufferbloat”. We then break down the end-to-end
> latency into various components, and identify the root cause to be the
> phone-side TCP receive buffer, whose configuration does not take into
> account the path asymmetry between the wearable-phone path and the
> phone-server path... " -
> https://anikravesh.github.io/files/wearos-sigmetrics19.pdf
>
> I am of course puzzled as to why they didn't look into sch_cake[1] or
> fq_codel derived solutions[2], (it is a non-open source OS) but they
> did manage to eliminate 97% of the problem in their paper, so, there's
> that.
>
> [1] https://arxiv.org/abs/1804.07617
> [2]
> https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
>


-- 
Xiao (Shawn) Zhu
PhD Candidate, Computer Science & Engineering
University of Michigan, Ann Arbor, MI 48105
Email: shawnzhu@umich.edu
Phone: 734-263-0338

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

Re: [Make-wifi-fast] 30+ sec of miserable bufferbloat in wearOS

[Dave Taht]

On Sun, Apr 7, 2019 at 9:11 PM Xiao Zhu <shawnzhu@umich.edu> wrote:
>
> Dear Dave Taht,
>
> Thank you for pointing out those two great papers and paying attention to our recent work.

It is my hope that the insights (and running code) in the those papers
are one day applied widely to 4g, 5g, GPON, MOCA, and homeplug
devices.

Homeplug, in particular, is oft horrific (
http://caia.swin.edu.au/reports/130121A/CAIA-TR-130121A.pdf ), and
early 5g results, also.

> In the context of wearable networking where the bottleneck is the Bluetooth link between the smartphone and the smartwatch, the solutions you mentioned can conceptually help to handle bottleneck queuing at lower layers, but it could be hard to execute them given the Bluetooth stack in Android is very different from that of WiFi/LTE and does not speak TCP/IP.

Bluetooth was not on my radar until reading your paper! I have in
general noticed a unusable amount of buffering for interactive
applications on both bluetooth and hdmi.

>
> In our future bufferbloat-related work, we will definitely discuss more related works, especially those you mentioned.
>
>
> Best,
> Xiao
>
> On Sat, Apr 6, 2019 at 8:14 PM Dave Taht <dave.taht@gmail.com> wrote:
>>
>> "When acting as a gateway proxy for a wearable, the phone dramatically
>> inflates the end-to-end (server to wearable) latency to 30+ seconds
>> due to its incurred “bufferbloat”. We then break down the end-to-end
>> latency into various components, and identify the root cause to be the
>> phone-side TCP receive buffer, whose configuration does not take into
>> account the path asymmetry between the wearable-phone path and the
>> phone-server path... " -
>> https://anikravesh.github.io/files/wearos-sigmetrics19.pdf
>>
>> I am of course puzzled as to why they didn't look into sch_cake[1] or
>> fq_codel derived solutions[2], (it is a non-open source OS) but they
>> did manage to eliminate 97% of the problem in their paper, so, there's
>> that.
>>
>> [1] https://arxiv.org/abs/1804.07617
>> [2] https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf
>> --
>>
>> Dave Täht
>> CTO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-831-205-9740
>
>
>
> --
> Xiao (Shawn) Zhu
> PhD Candidate, Computer Science & Engineering
> University of Michigan, Ann Arbor, MI 48105
> Email: shawnzhu@umich.edu
> Phone: 734-263-0338



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740