From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C37E93B2A4 for ; Wed, 8 Jun 2022 15:12:30 -0400 (EDT) Received: by mail-pl1-x62c.google.com with SMTP id o17so18464633pla.6 for ; Wed, 08 Jun 2022 12:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7kH0sgbkozcVQjiOQDTpt+1bKsMftPLHBD9iRHBNJ20=; b=deJa/6bsZPFfH3RXwx0Ez7F5HxxtLjbZRCpvj74mKnGuuG7eM3enLz8iBPGFly5GZJ czeuBmE0cuuWAnR+yf8ZoyaBWlUEik2MVjhGw1/mQVKV1IrjuLU6rCdgA57wIVFnab23 UGyVy3ofhpd6pZHD1srs9HdmGZYEEVS52x+ScjvV5mBq/K9vVR6S8RNIO7fUnADI6NP2 A0xkfMJf5lXA2rXH0EP8g5iBjFAm/aZWTge4/H+quumo5d7UzV4U/OU+QmFXxmUuzqyl YzzJr3NRpqjvvPagV0hWkeGqRzjNVz+Xiqb0pij8ftI3d3EzM3oYRdkJBokQQICgKKRe kpaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7kH0sgbkozcVQjiOQDTpt+1bKsMftPLHBD9iRHBNJ20=; b=UervbBwvqAq4puYcwk8wdKadC6JmeibJgELFKdd8G0fMAZrLt+THBTAKV9Y0Wy1sl/ DaKTyhhmIUeC8F0gZnIsoBJboctJ9bF51yfs8hHwgvZGSH+oxKJaCBbp2lqx7XllPFve BXCX+k8pYOKZsPdkzhuBSJphAwpXsZmeZzUELGQWNhMP0yAunEgYcWvUyjSN//rIHB9B 2RdDRzGHfgL9ZJ+YUVBY+mEJzVQxAJlAKAcV20qjIVCVmvpoDt3OC/aujDppV5uGHuUo LB79rX2eBtdeTJD7LdtGuhRHnLKXgbSykFsfVQaqtQDQS48DC7icq6mbXpUriB2SY8Df H4dQ== X-Gm-Message-State: AOAM531pncIR0u04KYMUMsj/NvaLZcuKPR9DJvaDCjIMTtNRAsU5hD83 4yzsmaMZLhPFzjSPUMgNx8vFwO9SuUMX+TUHyKWoqEo= X-Google-Smtp-Source: ABdhPJx6obfwkoOxM+N2iLQvJKeWwNQOTOWwUPCLO+NPmp2I4NrXCGm4P/qc2Rr2x3g/2FeuRKKmbDWrSwHCCaz882Q= X-Received: by 2002:a17:90a:e7cb:b0:1e8:65fb:3cd4 with SMTP id kb11-20020a17090ae7cb00b001e865fb3cd4mr690308pjb.234.1654715549619; Wed, 08 Jun 2022 12:12:29 -0700 (PDT) MIME-Version: 1.0 References: <1654714026.72728578@apps.rackspace.com> In-Reply-To: <1654714026.72728578@apps.rackspace.com> From: warren ponder Date: Wed, 8 Jun 2022 12:12:18 -0700 Message-ID: To: "David P. Reed" Cc: starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000008a1bd705e0f47c38" Subject: Re: [Starlink] FQ_Codel 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 19:12:30 -0000 --0000000000008a1bd705e0f47c38 Content-Type: text/plain; charset="UTF-8" So this is really helpful. Is it fair to say then that end users with SQM and fq_codel on a Starlink connection should essentially not turn on SQM.and.just leave it off? On Wed, Jun 8, 2022, 11:47 AM David P. Reed wrote: > I'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". > > > > Evidence exists that the bulk of the "bloat" can exist, not just in the > dishy, but also in the central "access point" where satellites in a > coverage region direct all the traffic from and to the public Internet. > This connection from the region becomes bloated if the inbound link and > outbound link become "underprovisioned" for peak rates of all the served > dishy terminals. > > That public-Internet to StarLink access point (is there 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 link just stores > packets until multiple seconds worth of traffic build up on one or both > ends of that link. > > > > 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 > the entire Internet. Typically, this queue size should max out and start > dropping packets at about 2 * cross-Internet desired latency * bit-rate of > this link. > > Cross-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 appropriate. (which 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 never understood what > end-to-end latency means). > > > > > > Now it may be that the dishy itself also has such bloat built in, which > would make FQ-Codel in the dishy also important. > > > > The problem called bufferbloat occurs whenever ANY router on ANY > end-to-end shared path allows such queueing delay to accumulate before > shortening the queue. > > > > It really frustrates 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 forwarding systems understands Queueing Theory at all! It > certainly doesn't help that "packet drops" (even one or two per second) are > considered a failure of the equipment. > > > > FQ-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 bit elastic). > However, the lack of FQ-Codel doesn't fix system-level bufferbloat. > > > > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --0000000000008a1bd705e0f47c38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So this is really helpful. Is it fair to say then that en= d users with SQM and fq_codel on a Starlink connection should essentially n= ot turn on SQM.and.just leave it off?



On Wed, Jun 8, 2022, 11:47 AM David P. Reed <dpreed@deepplum.com> wrote:

I'm just going to= remind folks that fixing bufferbloat in Starlink won't be possible wit= h FQ-Codel in the CPE equipment. If that were possible, it could be fixed e= ntirely in a box sitting between the dishy and the user's "home ne= twork".

=C2=A0

Evidence e= xists that the bulk of the "bloat" can exist, not just in the dis= hy, but also in the central "access point" where satellites in a = coverage region direct all the traffic from and to the public Internet. Thi= s connection from the region becomes bloated if the inbound link and outbou= nd link become "underprovisioned" for peak rates of all the serve= d dishy terminals.

That publi= c-Internet to StarLink access point (is there a more distinct, precise name= ) can develop a very long delay queue.=C2=A0 For the same reason that buffe= rbloat always gets designed in - memory is cheap and plentiful, so instead = of dropping packets to minimize latency, the link just stores packets until= multiple seconds worth of traffic build up on one or both ends of that lin= k.

=C2=A0

This probl= em can be solved only by dropping packets (with packet drop rate mitigated = by ECN-marking) to match the desired round-trip latency across the entire I= nternet. Typically, this queue size should max out and start dropping packe= ts at about 2 * cross-Internet desired latency * bit-rate of this link.

Cross-Inte= rnet desired latency can be selected these days by using light-speed in fib= er between one side of the North American continent and the other - around = 15 msec. is appropriate. (which should be the worst case end-to-end latency= observed using Starlink, and is around the 20 msec. number bandied about b= y Musk - though he really never understood what end-to-end latency means).<= /p>

=C2=A0

=C2=A0

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

=C2=A0

The proble= m called bufferbloat occurs whenever ANY router on ANY end-to-end shared pa= th allows such queueing delay to accumulate before shortening the queue.

=C2=A0

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

=C2=A0

FQ-codel i= s great, but why it works is that it makes the choice of what packet to dro= p far better (by being fair and a little bit elastic). However, the lack of= FQ-Codel doesn't fix system-level bufferbloat.

=C2=A0

=C2=A0

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/sta= rlink
--0000000000008a1bd705e0f47c38--