From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 18BB43B29E; Thu, 2 Dec 2021 03:45:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1638434714; bh=njpJY0ktEi92Sz5EujrkdKDz2V0IuPddmgtDEkShUFc=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=lrdIY9/jzoVRFuMwlRVaoG4oEjZrQHSenmF8mxcXqWjG3gs/tytnsjluNlz5MgObH r/FdNLRanq7dzhAgQAJ/93ZUbJHvLWiGtW9XIyIiRkWXKbjOnL54wfsSX3gHy0Tmuu jYh5u6SFNqRVqpSzs8nynHMwnT2V02N3f8bN1kik= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N95e9-1mYbbJ12f9-0166eo; Thu, 02 Dec 2021 09:45:14 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sebastian Moeller X-Priority: 3 (Normal) In-Reply-To: <1638390391.091227727@apps.rackspace.com> Date: Thu, 2 Dec 2021 09:45:13 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , cerowrt-devel , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <1638390391.091227727@apps.rackspace.com> To: "David P. Reed" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Provags-ID: V03:K1:KUgS1IcVMJv9SpttVwo6uOQhzkCkJEMvpG7GzoYQPl3Kz9hiGQN OJE2ELUzY8tJb4WZLx11EcdG8dU5wMrXGasHPFCDUWyrpcTXvfjpPklydDEy9vdfTL3wh60 qxMgH6zceHVM5vRhYozN3XiRD5T+GmblX/tonNq4p2wJyr8gOExneXvtMcOXFOvtN1tQ+SX i5YsilQNe72wPaowNN7Jw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:GTm1k94eQCY=:d9tSoyRYEFgI6UEQZVQd4O qqja5ePOkaj6OKYE5zPaECKILvholT47y1/9dkAg68c/me+A3uKCpgHxFnkVvJELyY/IseesE j6vc6BfpoL8joOjp4xlpgmLd9crCqXzxGdE7w70U/Dtv4D7q0sSCTQHJtjOGGA2SxeupyUL1F bWt+Mh0dX/H5Ax17hgdxuGrEeP+KSk1111+QVlI1TyK/4xuc8BcAYpo+fg8P74MTEAwBYZu4m MqdrLBXzDnprIVonXBYvdMOLI51dc36rTmiBJAQNzWkrhiSi91VVkGkSVLqYPHOFQNa9HDmSd swk4ooIFB/9/gNL247rpmeQDJBSBx96oWKVpAVFSkuNdvfTu3URvTGNDszP7arzx0sPQlZU1k pbs7KL5bWxF+qSVUHhfTc1WDJeGu1yUZwm3Ek5GXsURBrmZPhzf7UUUyDQnJJjPnNtQD2a6H5 R51AhBlifqbk2HN396xPLdhldu+vYIkHYGAIifPBWHJU3Sb4uoIxquVk+nDedhADvi5yTHBpm iu7ZCzwuGo4+C4rxxaiFWQeZnFuAG557xRuyJWtyNvVE7TbuIJko1bdvl3FXoNUv3AnAsoEnb w1EF1uF3IVrE662nyZolu1DgAnNL0r++TWLPPBpqX5vMuVgKBNowlGjfpFobnFBMYl8IvvfPQ Yo70YoJoODJKHF8N1osWKQ7+wp+8BM+iUSU+fJN0FDFYO9hFWqXHVbfINIsmSzrl436yZLeew 6IolM+fcP42WrhsoxYrAIihx12icnE//gd50zx3yMqohPoMB12VJCJma8bYNtR+41m9sVinpA lFiFbBlANCJ9DrP34D1d8l6/BcZHMD2iRn7oP3DLGqeiZqRGjphl8Sw5Yo7Yjw6NvkzABUwwM 78t/K41dMNDFvUz6qgfOLwJWuX87N1l1r8YR9qhss2txQZlK9bDtx5JxjELxnMzafbew8s/jv W7fI9s1YRe4jL5d5KnlxttmB/2elrVbG/5Iu33uJ2jlhYwJF2WZcvpBf+OMKyiMd+juAZdGwG ke9ns3HCAybsAHc4Zkxso8Af6wBeuSkIqmJWdM4Wys73LR0UpE3xQb6QLrATLr9ocDDDO+/QF ddXK93XzJ8PrCY= Subject: Re: [Cerowrt-devel] uplink bufferbloat and scheduling problems X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 08:45:18 -0000 Hi David, you probably had noticed that the cited paper was about LTE/(5G) where = the base station operates the scheduler that arbitrates both up- and = downstream transmissions. And according to the paper that ends up in = bursting on the upstream (I wonder how L4S with its increases burst = sensitivity is going to deal with that*)... I found that paper really nice, short and concise with a simple overview = of the used grant request system.... *) My bet is that they are going to claim LTE/5G will have to change = their ways.... > On Dec 1, 2021, at 21:26, David P. Reed wrote: >=20 > What's the difference between uplink and downlink? In DOCSIS the rate = asymmetry was the issue. But in WiFi, the air interface is completely = symmetric (802.11ax, though, maybe not because of centrally polling). > =20 > In any CSMA link (WiFi), there is no "up" or "down". There is only = sender and receiver, and each station and the AP are always doing both. > =20 > The problem with shared media links is that the "waiting queue" is = distributed, so to manage queue depth, ALL of the potential senders must = respond aggressively to excess packets. > =20 > This is why a lot (maybe all) of the silicon vendors are making really = bad choices w.r.t. bufferbloat by adding buffering in the transmitter = chip itself, and not discarding or marking when queues build up. It's = the same thing that constantly leads hardware guys to think that more = memory for buffers improves throughput, and only advertising throughput. > =20 > To say it again: More memory *doesn't* improve throughput when the = queue depths exceed one packet on average, and it degrades "goodput" at = higher levels by causing the ultimate sender to "give up" due to long = latency. (at the extreme, users will just click again on a slow URL, = causing all the throughput to be "badput", because they force the system = to transmit it again, while leaving packets clogging the queues. > =20 > So, if you want good performance on a shared radio medium, you need to = squish each flow's queue depth down from sender to receiver to "average = < 1 in queue", and also drop packets when there are too many = simultaneous flows competing for airtime. And if your source process = can't schedule itself frequently enough, don't expect the network to = replace buffering at the TCP source and destination - it is not intended = to be a storage system. With a variable rate link like LTE or WiFi some buffering above = 1 in queue seems unavoidable, e.g. even if steady state traffic at X = Mbps converged to 1-in-queue if the rate the drops to say x/10 Mbps all = th packets in flight will hit the buffers at the upstream end of the = bottleneck link, no? If rate changes happen rarely, I guess the = "average" will still be meaningful, but what if rate changes happen = often? Regards Sebastian > =20 > =20 > =20 > On Tuesday, November 30, 2021 7:13pm, "Dave Taht" = said: >=20 > > Money quote: "Figure 2a is a good argument to focus latency > > research work on downlink bufferbloat." > >=20 > > It peaked at 1.6s in their test: > > https://hal.archives-ouvertes.fr/hal-03420681/document > >=20 > > -- > > I tried to build a better future, a few times: > > https://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org > >=20 > > Dave T=C3=A4ht CEO, TekLibre, LLC > > _______________________________________________ > > Cerowrt-devel mailing list > > Cerowrt-devel@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel