Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Xiao Zhu <shawnzhu@umich.edu>
Cc: Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
	"Z. Morley Mao" <zmao@umich.edu>
Subject: Re: [Make-wifi-fast] 30+ sec of miserable bufferbloat in wearOS
Date: Mon, 8 Apr 2019 05:44:05 +0200	[thread overview]
Message-ID: <CAA93jw7hG23A0QtFgytdFhMHNZt+DZrHboTSNZkarPNfaXsL9Q@mail.gmail.com> (raw)
In-Reply-To: <CACpU-ZBEXQGeNaza3F6JAWW8=XgxZA1+1=YHWmodVgYVnMAkVw@mail.gmail.com>

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

      reply	other threads:[~2019-04-08  3:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-07  0:13 Dave Taht
2019-04-07 19:11 ` Xiao Zhu
2019-04-08  3:44   ` Dave Taht [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw7hG23A0QtFgytdFhMHNZt+DZrHboTSNZkarPNfaXsL9Q@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=shawnzhu@umich.edu \
    --cc=zmao@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox