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