From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3C1433B29D for ; Thu, 11 Jun 2020 15:28:56 -0400 (EDT) Received: from dlang-laptop.LAN (dlang-laptop.LAN [10.2.0.162]) by mail.lang.hm (Postfix) with ESMTP id 2114DBA78B; Thu, 11 Jun 2020 12:28:55 -0700 (PDT) Date: Thu, 11 Jun 2020 12:28:55 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang-laptop To: "David P. Reed" cc: David Lang , Jonathan Morton , bloat In-Reply-To: <1591902977.45963161@apps.rackspace.com> Message-ID: References: <1591891396.41838464@apps.rackspace.com> <1591901205.85717618@apps.rackspace.com> <1591902977.45963161@apps.rackspace.com> User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Subject: Re: [Bloat] FW: [Dewayne-Net] Ajit Pai caves to SpaceX but is still skeptical of Musk's latency claims 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: Thu, 11 Jun 2020 19:28:56 -0000 On Thu, 11 Jun 2020, David P. Reed wrote: > On Thursday, June 11, 2020 2:56pm, "David Lang" said: > > > >> We will see, but since the answer to satellite-satellite communication being the >> bottleneck is to launch more satellites, this boils down to investment vs >> service quality. Since they are making a big deal about the latency, I expect >> them to work to keep it acceptable. > > > We'll see. I should have mentioned that the ATT network actually had adequate capacity. As did Comcast's network when it was bloated like cracy (as Jim Gettys will verify). > > As I have said way too often - the problem isn't throughput related, and can't be measured by achieved throughput, nor can it be controlled by adding capacity alone. > > The problem is the lack of congestion signalling that can stop the *source* from sending more than its share. > > That's all that matters. I see bufferbloat in 10-100 GigE datacenter networks quite frequently (esp. Arista switches!). Some would think that "fat pipes" solve this problem. It doesn't. Some think pirority eliminates the problem. It doesn't, unless there is congestion signalling in operation. > > Yes, using a single TCP end-to-end connection over an unloaded network you can get 100% throughput on an unloaded network. The problem isn't the hardware at all. It's the switching logic that just builds up queues till they are intolerably long, at which point the queues cannot drain, so they stay full as long as the load remains. > > In the iPhone case, when a page didn't download in a flash, what do users do? Well, they click on the link again. Underneath it all, then, all the packets that were stuffed in the pipe toward that user remain queued. And a whole lot more get shoved in. And the user keeps hitting the button. If the queue holds 2 seconds of data at the bottleneck rate, it continues to be full as long as users keep clicking on the link. > > You REALLY must think about this scenario, and get it in your mind that throughput doesn't eliminate congestion, especially when computers can do a lot of work on your behalf every time you ask them. > > One request packet - thousands of response packets, and no one telling the sources that they should slow down. > > For all of this, there is a known fix: don't queue packets more than 2xRTTx"bottleneck rate" in any switch anywhere. That's been in a best practice RFC forever, and it is ignored almost always. Cake and other algorithms do even better, by queuing less than that in any bottleneck-adjacent queue. > > But instead of the known fix (known ever since the first screwed up Frame Relay hops were set to never lose a packet) is deliberately ignored, by hardware know-it-alls. my point is that the if the satellite links are not the bottleneck, no queuing will happen there. I expect the queuing to happen at the internet-satellite gateways, which is much more conventional software and if they do something sane at the gateways it will address the problem for pretty much everyone. They don't have to implement anything special on the satellites. and if he is promising good latency, but there isn't good latency, it isn't going to be swept under the rug the way incumbant ISPs were able to. David Lang