From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp78.iad3a.emailsrvr.com (smtp78.iad3a.emailsrvr.com [173.203.187.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8A5D23B29E for ; Wed, 1 Dec 2021 15:26:31 -0500 (EST) Received: from app67.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2AA475DAA; Wed, 1 Dec 2021 15:26:31 -0500 (EST) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app67.wa-webapps.iad3a (Postfix) with ESMTP id 16EF9600DD; Wed, 1 Dec 2021 15:26:31 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 1 Dec 2021 15:26:31 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Wed, 1 Dec 2021 15:26:31 -0500 (EST) From: "David P. Reed" To: "Dave Taht" Cc: "bloat" , "cerowrt-devel" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20211201152631000000_61875" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1638390391.091227727@apps.rackspace.com> X-Mailer: webmail/19.0.13-RC X-Classification-ID: a5cf1517-d787-405d-bd8b-8723263295b5-1-1 Subject: Re: [Bloat] [Cerowrt-devel] uplink bufferbloat and scheduling problems 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: Wed, 01 Dec 2021 20:26:31 -0000 ------=_20211201152631000000_61875 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AWhat's the difference between uplink and downlink? In DOCSIS the rate a= symmetry was the issue. But in WiFi, the air interface is completely symmet= ric (802.11ax, though, maybe not because of centrally polling).=0A =0AIn an= y CSMA link (WiFi), there is no "up" or "down". There is only sender and re= ceiver, and each station and the AP are always doing both.=0A =0AThe proble= m 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.=0A =0AThis is why a lot (maybe all) of the silicon vend= ors are making really bad choices w.r.t. bufferbloat by adding buffering in= the transmitter chip itself, and not discarding or marking when queues bui= ld up. It's the same thing that constantly leads hardware guys to think tha= t more memory for buffers improves throughput, and only advertising through= put.=0A =0ATo say it again: More memory *doesn't* improve throughput when t= he 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 laten= cy. (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 i= t again, while leaving packets clogging the queues.=0A =0ASo, if you want g= ood performance on a shared radio medium, you need to squish each flow's qu= eue depth down from sender to receiver to "average < 1 in queue", and also = drop packets when there are too many simultaneous flows competing for airti= me. And if your source process can't schedule itself frequently enough, don= 't expect the network to replace buffering at the TCP source and destinatio= n - it is not intended to be a storage system.=0A =0A =0A =0AOn Tuesday, No= vember 30, 2021 7:13pm, "Dave Taht" said:=0A=0A=0A=0A= > Money quote: "Figure 2a is a good argument to focus latency=0A> research = work on downlink bufferbloat."=0A> =0A> It peaked at 1.6s in their test:=0A= > https://hal.archives-ouvertes.fr/hal-03420681/document=0A> =0A> --=0A> I = tried to build a better future, a few times:=0A> https://wayforward.archive= .org/?site=3Dhttps%3A%2F%2Fwww.icei.org=0A> =0A> Dave T=C3=A4ht CEO, TekLib= re, LLC=0A> _______________________________________________=0A> Cerowrt-dev= el mailing list=0A> Cerowrt-devel@lists.bufferbloat.net=0A> https://lists.b= ufferbloat.net/listinfo/cerowrt-devel=0A> ------=_20211201152631000000_61875 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

What's the difference = between uplink and downlink?  In DOCSIS the rate asymmetry w= as the issue. But in WiFi, the air interface is completely symmetric (802.1= 1ax, though, maybe not because of centrally polling).

=0A

 

=0A

In any CSMA link (WiFi), there is n= o "up" or "down". There is only sender and receiver, and each station and t= he AP are always doing both.

=0A

 

=0A

The problem with shared media links is that the "waiting que= ue" is distributed, so to manage queue depth, ALL of the potential senders = must respond aggressively to excess packets.

=0A

&nb= sp;

=0A

This is why a lot (maybe all) of the silicon= vendors are making really bad choices w.r.t. bufferbloat by adding bufferi= ng in the transmitter chip itself, and not discarding or marking when queue= s build up. It's the same thing that constantly leads hardware guys to thin= k that more memory for buffers improves throughput, and only advertising th= roughput.

=0A

 

=0A

To s= ay it again: More memory *doesn't* improve throughput when the queue depths= exceed one packet on average, and it degrades "goodput" at higher levels b= y causing the ultimate sender to "give up" due to long latency. (at the ext= reme, 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.

=0A

 

= =0A

So, if you want good performance on a shared radio = medium, you need to squish each flow's queue depth down from sender to rece= iver 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 replac= e buffering at the TCP source and destination - it is not intended to be a = storage system.

=0A

 

=0A

 

=0A

On Tu= esday, November 30, 2021 7:13pm, "Dave Taht" <dave.taht@gmail.com> sa= id:

=0A
=0A

> Money quote: "Figure 2a is a good argument to focus latency
&= gt; research work on downlink bufferbloat."
>
> It peaked = at 1.6s in their test:
> https://hal.archives-ouvertes.fr/hal-03420= 681/document
>
> --
> I tried to build a better fu= ture, a few times:
> https://wayforward.archive.org/?site=3Dhttps%3= A%2F%2Fwww.icei.org
>
> Dave T=C3=A4ht CEO, TekLibre, LLC<= br />> _______________________________________________
> Cerowrt= -devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
>= https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

=0A ------=_20211201152631000000_61875--