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

[Xiao Zhu <shawnzhu@umich.edu>]

[-- 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 --]