From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AADEC3CB37 for ; Sun, 7 Apr 2019 23:44:18 -0400 (EDT) Received: by mail-qk1-x72a.google.com with SMTP id a71so7143918qkg.2 for ; Sun, 07 Apr 2019 20:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=neU7dJth9KTTitBST/w2fmGzdSWT52p8UCWelU2CI0U=; b=eOPB1H2azNIQ3yOm0dfZBeADzvlAWKse3q739QyDeESVNYjXVN4lqV99sMWDJrF1pc 1mbakgMwRnITkBVf87mmXbNpth+vXiKuFS8RSBEWhX1zvziuLIcWTgsKlvS48iUttDw9 Hb4ZutES7QqNtZL4BM7sVjbckrKeBOVvtvsWRuzBe71U+f/7DzS7jkHrafAUWn7RGh2d JfeNzrsarA/l7QbcKz99CSsS2HQODneLc+Pca463WroUuJBQSfrxVPpTnFYAdNUbz7DO u29Qapz2ej4O0qBXMz9ZAKnNScyXErlMCPnONRrPdxaRxWE4nCM124lJfH8O5BsRHkSD 8qWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=neU7dJth9KTTitBST/w2fmGzdSWT52p8UCWelU2CI0U=; b=BAcJN+Yb0hYGWt5Rr8bjFtK6gMOsdbtNNhas8KJ+6VP94aMbMG5QA5ArJKLrxi/xvc COZFF85IqPac1W4JtVCyRMqYzfipZCOebynkxUff5Hi/ku8MqGZh50MuGM5diRIzbjiD MYlIziXJhhTvRiLRLK0MJm0VTZl2NBU5Ms6KO5Aml6JsKthz+MvNVelQcnQKAWuzkmgM GszafbiPNeg+t2RoZBNIvJJwnkzMe/GQvCCBGKGDCV79WPiEz94P4clHnGFTvZ75OBHp TJwt+3MZ9rwJJZg7P6EJGH4iL9Tkr5jUb7fAt6KbgzC1tjJzutMKB0mSd30Cv13pJbRB Upvw== X-Gm-Message-State: APjAAAWg1R/IKI+gqbMmCb8Pc6PWpzj9ygh8vMgoHmoj2rqkXi3SLEMp /swIwlAS2R19OD/0AELv7KeMeETuuPoiqkR8Cfw= X-Google-Smtp-Source: APXvYqz7ysArGq2fB1z48Okf3TcjE6kr3Z/dUtbOTTnTV3yRyW0mAtCXBMFT1Dlt9no2JQjcQZF5UIDSwQLX8eWOWeQ= X-Received: by 2002:a37:99c7:: with SMTP id b190mr20495735qke.2.1554695058087; Sun, 07 Apr 2019 20:44:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Mon, 8 Apr 2019 05:44:05 +0200 Message-ID: To: Xiao Zhu Cc: Make-Wifi-fast , "Z. Morley Mao" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] 30+ sec of miserable bufferbloat in wearOS X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 03:44:18 -0000 On Sun, Apr 7, 2019 at 9:11 PM Xiao Zhu 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 Bluetoo= th link between the smartphone and the smartwatch, the solutions you mentio= ned 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 v= ery 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 r= elated works, especially those you mentioned. > > > Best, > Xiao > > On Sat, Apr 6, 2019 at 8:14 PM Dave Taht 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 =E2=80=9Cbufferbloat=E2=80=9D. We then break down th= e 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-j= orgensen.pdf >> -- >> >> Dave T=C3=A4ht >> 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 --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740