From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp93.iad3a.emailsrvr.com (smtp93.iad3a.emailsrvr.com [173.203.187.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 550013B2A4 for ; Wed, 8 Jun 2022 14:47:07 -0400 (EDT) Received: from app46.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C8A835525 for ; Wed, 8 Jun 2022 14:47:06 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app46.wa-webapps.iad3a (Postfix) with ESMTP id B25CCC1C58 for ; Wed, 8 Jun 2022 14:47:06 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 8 Jun 2022 14:47:06 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Wed, 8 Jun 2022 14:47:06 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20220608144706000000_62703" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1654714026.72728578@apps.rackspace.com> X-Mailer: webmail/19.0.15-RC X-Classification-ID: 6e912958-0b14-4b9b-aab2-6135d19d4ca9-1-1 Subject: Re: [Starlink] =?utf-8?q?FQ=5FCodel?= X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2022 18:47:07 -0000 ------=_20220608144706000000_62703 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI'm just going to remind folks that fixing bufferbloat in Starlink won't= be possible with FQ-Codel in the CPE equipment. If that were possible, it = could be fixed entirely in a box sitting between the dishy and the user's "= home network".=0A =0AEvidence exists that the bulk of the "bloat" can exist= , not just in the dishy, but also in the central "access point" where satel= lites in a coverage region direct all the traffic from and to the public In= ternet. This connection from the region becomes bloated if the inbound link= and outbound link become "underprovisioned" for peak rates of all the serv= ed dishy terminals.=0AThat public-Internet to StarLink access point (is the= re a more distinct, precise name) can develop a very long delay queue. For= the same reason that bufferbloat always gets designed in - memory is cheap= and plentiful, so instead of dropping packets to minimize latency, the lin= k just stores packets until multiple seconds worth of traffic build up on o= ne or both ends of that link.=0A =0AThis problem can be solved only by drop= ping packets (with packet drop rate mitigated by ECN-marking) to match the = desired round-trip latency across the entire Internet. Typically, this queu= e size should max out and start dropping packets at about 2 * cross-Interne= t desired latency * bit-rate of this link.=0ACross-Internet desired latency= can be selected these days by using light-speed in fiber between one side = of the North American continent and the other - around 15 msec. is appropri= ate. (which should be the worst case end-to-end latency observed using Star= link, and is around the 20 msec. number bandied about by Musk - though he r= eally never understood what end-to-end latency means).=0A =0A =0ANow it may= be that the dishy itself also has such bloat built in, which would make FQ= -Codel in the dishy also important.=0A =0AThe problem called bufferbloat oc= curs whenever ANY router on ANY end-to-end shared path allows such queueing= delay to accumulate before shortening the queue.=0A =0AIt really frustrate= s me that memory keeps being added to router outbound buffers anywhere. And= it may be that the reason is that almost nobody who designs packet forward= ing systems understands Queueing Theory at all! It certainly doesn't help t= hat "packet drops" (even one or two per second) are considered a failure of= the equipment.=0A =0AFQ-codel is great, but why it works is that it makes = the choice of what packet to drop far better (by being fair and a little bi= t elastic). However, the lack of FQ-Codel doesn't fix system-level bufferbl= oat.=0A =0A=0A ------=_20220608144706000000_62703 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I'm just going to remi= nd folks that fixing bufferbloat in Starlink won't be possible with FQ-Code= l in the CPE equipment. If that were possible, it could be fixed entirely i= n a box sitting between the dishy and the user's "home network".

=0A

 

=0A

Evidence exists that the= bulk of the "bloat" can exist, not just in the dishy, but also in the cent= ral "access point" where satellites in a coverage region direct all the tra= ffic from and to the public Internet. This connection from the region becom= es bloated if the inbound link and outbound link become "underprovisioned" = for peak rates of all the served dishy terminals.

=0A

 

=0A

This problem can be solved only by dropping packets (with packet drop rate= mitigated by ECN-marking) to match the desired round-trip latency across t= he entire Internet. Typically, this queue size should max out and start dro= pping packets at about 2 * cross-Internet desired latency * bit-rate of thi= s link.

=0A

Cross-Internet desired latency can be se= lected these days by using light-speed in fiber between one side of the Nor= th American continent and the other - around 15 msec. is appropriate. (whic= h should be the worst case end-to-end latency observed using Starlink, and = is around the 20 msec. number bandied about by Musk - though he really neve= r understood what end-to-end latency means).

=0A

&nb= sp;

=0A

 

=0A

Now it may= be that the dishy itself also has such bloat built in, which would make FQ= -Codel in the dishy also important.

=0A

 

= =0A

The problem called bufferbloat occurs whenever ANY = router on ANY end-to-end shared path allows such queueing delay to accumula= te before shortening the queue.

=0A

 

=0A

It really frustrates me that memory keeps being added to = router outbound buffers anywhere. And it may be that the reason is that alm= ost nobody who designs packet forwarding systems understands Queueing Theor= y at all! It certainly doesn't help that "packet drops" (even one or two pe= r second) are considered a failure of the equipment.

=0A

 

=0A

FQ-codel is great, but why it works = is that it makes the choice of what packet to drop far better (by being fai= r and a little bit elastic). However, the lack of FQ-Codel doesn't fix syst= em-level bufferbloat.

=0A

 

=0A
=0A

 

=0A
 ------=_20220608144706000000_62703--