From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3988E3B2A4 for ; Tue, 24 Apr 2018 04:43:28 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1524559407; bh=IiYdDvu+PZHYWXI2LhfifG5xIcOy0FlihrFE+ziTw/I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=v2iW8OTxTGs++ZBsij6P05GI0u7qj0O6EIAVmi8VrF2m8TzK58aeGwECvJAJKQyyu 62HsZ7BEIdAyBFWv8lGe+ti0vHetj/kZPFFUrQN6DGvr3UFsZhWpallrS8YVRcziab pARPTrg/2wVxpGDk4UNHQxg1nOC3bcie6iT0ycldV7JrBiKB3FkfkMA7TwI9Rk3LRt tOEfavT55fmfSygoGPUtpYFW7N1Q+lj/zORLU/OZwZ6ch8+Zv1RF1Kb6EedglqYhzP we/X2fpeCc0kbDpxBVPLRjlakDllPBfgNGkMyiErDMHpujcc/sxz7V5oA/bNAP8Smd AIcJN8KtlsLXQ== To: Pete Heist Cc: cake@lists.bufferbloat.net In-Reply-To: References: <871sf6xqne.fsf@toke.dk> Date: Tue, 24 Apr 2018 10:43:26 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87tvs1805t.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Pre-print of Cake paper available X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 08:43:28 -0000 Pete Heist writes: >> On Apr 23, 2018, at 10:39 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Last week we submitted an academic paper describing Cake. A pre-print is >> now available on arXiv: https://arxiv.org/abs/1804.07617 >>=20 >> Comments welcome, of course :) > > > Nice work overall=E2=80=A6 :) Below is some feedback on content, and atta= ched > is a marked up PDF with some feedback on grammar and wording. Click > the vanilla squares to show the notes. Thanks! A lot of those should have been fixed before submission; boy, did I make a mess of verb tenses... Ah well, I'll incorporate your fixes, so they will be fixed for the camera ready (assuming it gets accepted) :) > Content: > > - I wish there were some reference on how widespread of a problem > bufferbloat actually is on the current Internet. That would bolster > the initial assertion in the introduction. Hmm, I do actually have a paper of my own that I could cite for this ;) The trouble is that we have a pretty tight page limit, and adding another reference takes us over that, meaning we would have to cut something else. And I think we can do without in an academic paper context at least... > - Thank you, I finally =E2=80=9Cget" triple-isolate. :) But I find it eas= ier > to understand the behavior of dual-srchost and dual-dsthost, and I > think most would prefer its behavior, despite the fact that it needs > to be configured manually. Just a thought, knowing that cake currently > targets home gateways, and that there are now the egress and ingress > keywords, could host isolation default to dual-srchost for egress mode > and dual-dsthost for ingress mode? Or since using the keywords would > be fragile, is there a better way to know the proper sense for > dual-srchost and dual-dsthost? > > - If =E2=80=98nat=E2=80=99 is not the default, won=E2=80=99t host isolati= on not work by > default for most home gateways, almost all of which do nat? (Untested > assumption.) I think these questions are actually better handled as userspace policy issues. For instance, in sqm-scripts we could reasonably default to dual-srchost on egress and dual-dsthost on ingress, as we know which is which. > - Not in the paper, but is the =E2=80=98wash=E2=80=99 keyword really need= ed? Is anything really *needed*? ;) It's useful in settings where you want to clear diffserv markings, and not in other places... > - Is it worth mentioning that when the home gateway=E2=80=99s uplink is W= iFi, > shaping is hard to do reliably, overhead and framing compensation > can=E2=80=99t even be implemented, and that this is all more properly han= dled > in the WiFi specific work? > > - One of the biggest deployment challenges (not unique to cake) is > that most people have to use shaping, since deploying cake on their > gateway=E2=80=99s external interface isn=E2=80=99t practical. But setting= the rate > properly for shaping isn=E2=80=99t always straightforward. This is sheer > speculation, but could observed latency (obtained by passively > measuring TCP RTT, for instance) be used as a signal to control the > rate? I can only imagine this might be difficult to get right (though > I would=E2=80=99ve thought what BBR does is also), so just take this as f= ood > for thought... I'd categorise these as relevant issues that we don't have space to discuss in the paper ;) -Toke