From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2B57A3B29D; Sat, 4 Jul 2020 14:29:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1593887384; bh=sT7jMB/2u5BWPUGHlUw+uBodffEDZR7es0GKS47n3+8=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=KbKw9K0xmrdCiiZEFVtrmJvomrDFJfyt6N/jJHQg9T2H0UxJVwUgZrqxpXCJY6gNF nDXM3t1CW/YYlGhen0KWqyMPvvzk4YBbqrcaRHTKaOT0og05MqIAxcCwG3YBZbCBe+ VgFSWufmXidgXqweDg1aa3dJqSU44TKqIwbjU7+c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.3.181.129]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MC30P-1k4C3h1v5R-00CTAv; Sat, 04 Jul 2020 20:29:44 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Sebastian Moeller In-Reply-To: Date: Sat, 4 Jul 2020 20:29:43 +0200 Cc: Matt Mathis , Make-Wifi-fast , Carlo Augusto Grazia , bloat , jamshid@whatsapp.com Content-Transfer-Encoding: quoted-printable Message-Id: <5405F10B-F446-4B74-8894-33232145EB2E@gmx.de> References: To: Daniel Sterling X-Mailer: Apple Mail (2.3445.104.14) X-Provags-ID: V03:K1:2FnS1OVjoZgWxuwJ9SwJX0AzQRl0a/nh1BE9sfuZcWA5U9USZSc KcH7QpxFm4m89wyPlVvv1mtpGofakuTA8WC4NfVDaqLggQWIfbNxa7RjLdKqS9MeVq4w+kt g9LqLU+CufVTrIIzWXzeZpbw1A0vjK4NKijdl9SE+6VX/Lqh1Kv4f/TTKZxAyobSH4zTexJ 8PeEIZVd7r7g6cKVtRXeQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:IlQhi1iHe9w=:0k92GVUKTSGzK9Hx2Q5W6u 2XK2O3Q4wrOPqU/UeNgAwKTBGqa7roucX7hM30E+E/sxUsZSIME8fd06ParCrpB+as9U3YgzN TIA48iH5W4WQ0XDb+hoqoR7udetg7zKP+iRhFcJmMlpoIleMyFVfovwTRyYJCLgOXuzCEkbry 0QfqcsrCadcxES4iTahphAyZD3AloyyeUbG3B8XDvzsSNRSnZeHku78s93cQfMhSDY0PndGlS 1uRqROX8CgxsynwXghYV2fUoXHEK8NohxuaeJ8YU/SuB2uoMypR9af6IIu6vIAy8Cj9AAwggZ BWmhZ1iwLH0n0ufaYaW3aTtx6mTxTUJTeioQLHmllQBAUmaQqqPnNgZPrnqVBhs8Dmz1wdCo7 rLwzqKaHuRR3ET4IOI5J57zMhonIeZq7zLfYW37mis2zpgvk8b1u0YHM8eCYwAd2kPs+o17mW 19U28xB+OsJuMLpuGD5QQIKT9jeWKReXWNvq/7cg9LsjcfVh8nYu2kBA1VCTn8NFMhz5OPuJn azi16x3cCaDyw+Vqj9BecPzGxnjcvWzt/56rMROH7kypPRV6m9PRFO+oPx2kBughnpmyKJ37g 855khIWVseOsDPYFxMGFkXSw6soYxKYAecCv7xataqvHYkstof5j72wopF0y+fr5qfibkzSDq 45kXVlYE6dpGtxLb4FXWU2iXCLpAfY4uOBOso7ft+PabLzXmJoUr+c+LR3VvJdGpwRcT5GIXt kNIjU7sQQrXDfQx0vtOSa43BIogsemInbPbqXM4KZknWvb4x3EnVzZazmsVSnz+K4cBIhWp/x H1gcpIK8Lvd9uWDv+5RjNzfne2nGFHP5aosFK/biZTFdB5JvOS8FkKEVuASdl1WBY4yOi3V+z RtFbeyDCNP1mNTfwYseYgbyI9Lmf/zcxdX/THTiVRvRLiC/+s7zuBk9B0iRGT16Nr4JRYXYRq gntldPdGT+AHIidXOYoJu3khE4xihQNo4+pHT+r4fXX4IG9LaCt9PS6SaY3ZhCldkpWntQdEK 8lItzPzVwefOkUVj57ioftTcUl9L50lnZFUP5D3pY8Jujdidz154ubfeZopjKY3BQr/E2BawW VbRmPVBtteECdpgwttAYvPgo6SqBxLRJ0pZyvUVpkTgS+Iu3kd3ijgAI9+wgzpcPbCBWwlhwi L/gHAdg3YgPWtjffXp/XQSOvAQlLhyu4KnF8EMWo4SmWLthGqY7f+uOdJmTz7ybLTDeb8= Subject: Re: [Bloat] the future belongs to pacing X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 18:29:51 -0000 > On Jul 4, 2020, at 19:52, Daniel Sterling = wrote: >=20 > On Sat, Jul 4, 2020 at 1:29 PM Matt Mathis via Bloat > wrote: > "pacing is inevitable, because it saves large content providers money > (more efficient use of the most expensive silicon in the data center, > the switch buffer memory), however to use pacing we walk away from 30 > years of experience with TCP self clock" >=20 > at the risk of asking w/o doing any research, >=20 > could someone explain this to a lay person or point to a doc talking > about this more? >=20 > What does BBR do that's different from other algorithms? Well, it does not believe the network (blindly), that is = currently it ignores both ECN marks and (sparse) drops as signs of = congestion, instead it uses its own rate estimates to set its send rate = and cyclically will re-assess its rate estimate. Sufficiently severe = drops will be honored. IMHO a somewhat risky approach, that works = reasonably well, as often sparse drops are not real signs of congestion = but just random drops of say a wifi link (that said, these drops on wifi = typically also cause painful latency spikes as wifi often takes heroic = measures in attempting retransmitting for several 100s of milliseconds). > Why does it > break the clock? One can argue that there is no real clock to break. TCP gates = the release on new packets on the reception of ACK signals from the = receiver, this is only a clock, if one does not really care for the = equi-temporal period property of a real clock. But for better or worse = that is the term that is used. IMHO (and I really am calling this from = way out in the left-field) gating would be a better term, but changing = the nomenclature probably is not an option at this point. > Before BBR, was the clock the only way TCP did CC? No, TCP also interpreted a drop (or rather 3 duplicated ACKs) as = signal of congestion and hit the brakes, by halving the congestion = window (the amount of data that could be in flight unacknowledged, which = roughly correlates with the send rate, if averaged over long enough time = windows). BBR explicitly does not do this unless it really is convinced = that someone dropped multiple packets purposefully to signal congestion. In practice it works rather well, in theory it could do with at = least an rfc3168 compliant response to ECN marks (which an AQM uses to = explicitly signal congestion, unlike a drop an ECN mark is really = unambiguous, some hop on the way "told" the flow slow down). >=20 > Also, >=20 > I have UBNT "Amplifi" HD wifi units in my house. (HD units only; none > of the "mesh" units. Just HD units connected either via wifi or > wired.) Empirically, I've found that in order to reduce latency, I > need to set cake to about 1/4 of the total possible wifi speed; > otherwise if a large download comes down from my internet link, that > flow causes latency. >=20 > That is, if I'm using 5ghz at 20mhz channel width, I need to set > cake's bandwidth argument to 40mbits to prevent video streams / > downloads from impacting latency for any other stream. This is w/o any > categorization at all; no packet marking based on port or anything > else; cake set to "best effort". >=20 > Anything higher and when a large amount of data comes thru, something > (assumedly the buffer in the Amplifi HD units) causes 100s of > milliseconds of latency. >=20 > Can anyone speak to how BBR would react to this? My ISP is full > gigabit; but cake is going to drop a lot of packets as it throttles > that down to 40mbit before it sends the packets to the wifi AP. >=20 > Thanks, > Dan > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat