From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 641F43CC83 for ; Tue, 7 May 2024 15:47:07 -0400 (EDT) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-41dc9f98e8dso520835e9.1 for ; Tue, 07 May 2024 12:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715111226; x=1715716026; darn=lists.bufferbloat.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8rYQEjRdkuskWBoi9xSOR6c5zIXycfd/swqjFnPHwtQ=; b=ep/W87yBBgcvVGqH0KY8fReiTTr3FE8H2enCnWicyjsdwWyeGr8pfEcEIpK9G48dEd j87lAtC+gIgrNblPK9qHdmKjJIY8aNU9t5VjUF+79x0Y4xm4XcLc9NK0uphQlhhJGHVy ADQigzJJz5BSVe9Z4uAOhz4AvM5SpDC98xSjDCDqeB/Za/VDYSwH6odJQfcVd+llHm7D XBZHF4hc/9WOazJSFCaySUGNFiAjYTXRaIrDwf5e/1NxMGwtum1Tb4mxsDrEmdJzixnw dbDXi6QKTaT0pYHwugiYs6rLxk9RKO8IKVsqDtYehpL8bzzuaEdeDLsGkfrIEQZ0ysnB zQZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715111226; x=1715716026; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8rYQEjRdkuskWBoi9xSOR6c5zIXycfd/swqjFnPHwtQ=; b=Njo4/Mg3Ld2hOJEbJ8VXblR/j2VC5H6BaC6/htOpYVryAwvNGXOo9ciHxrS0kS4JLJ ILstslLTL2TiP5Ts61Z43l+ahD21ogA6BGMgP761PsWcTsQcnwhAL96yfufyYmJ2R5y8 XTczEqjdQPcOs5sEz0jqlxb7wtbIxlx7c145CGY6MgfJ8ZWP6WePBx6rCSPDUXuHlF2E hmlBb4K3Hdm+ue2P7cgqoukwZNAVeTKD2BwBitiLJuhNRu3+M+xRvvNXG8aGOFl+ZsQo i6kfplqw/Vy6gf2c3X5D1OVLVdUM0xOzbQh2j/jx0FcbRU61HEumb0ghoIfe9EGuJOoq JoAw== X-Forwarded-Encrypted: i=1; AJvYcCXIguPZaYt7eXJY1dI64T2FqnAYHMSuyOFR3sylFhPiBVQfFc3fSgoYCu26I0aC82iVAYwBeqk+ksmxClDJMZF7VmjMdSCRSwSXy9UDWJw= X-Gm-Message-State: AOJu0YwJFSmG3hD9EJ7EqPNWjZs6gOwXYLGiuNZ8SXp+QxbnFRPRYog7 OvUdBEfwiNay3H3gmOdkdJ2aXzPqDGTOyE2RUKnIdybyCyDpwIP5FMO2A+3dR6UbTA+HwiQC8R+ uC+HXtY8ZYWGouDmhhnZtrfT4z50= X-Google-Smtp-Source: AGHT+IGnUdKZ/CVwQrv8rqwxKmYQ466AyNhYjj1PX2qFHKdCvbTvhmgpyZ9alx6tQgpKaI0Js3IKkuF1i2aR/TUjsiA= X-Received: by 2002:a05:6000:401e:b0:34d:9012:ad95 with SMTP id ffacd0b85a97d-34f81f39e70mr4067631f8f.32.1715111226208; Tue, 07 May 2024 12:47:06 -0700 (PDT) MIME-Version: 1.0 References: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com> <1779481A-0817-4F18-A0D7-A7A5AA0AF9D6@ieee.org> In-Reply-To: From: Dave Taht Date: Tue, 7 May 2024 12:46:54 -0700 Message-ID: To: Jeremy Austin Cc: Eugene Y Chang , Dave Taht via Starlink , Dave Collier-Brown Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem 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: Tue, 07 May 2024 19:47:07 -0000 Pete heist, jon morton, and rod grimes published a TON of research as to where l4s went wrong in these github repos: https://github.com/heistp The last was: https://github.com/heistp/l4s-tests?tab=3Dreadme-ov-file#key-= findings They were ignored. Me, I had taken one look at it 7+ years ago and said this cannot possibly work with the installed base of wifi properly and since 97E% of all home connections terminate in that it was a dead horse which they kept flogging. After the L4S RFCs were published they FINALLY took their brands of wishful thinking to actually exploring what happeed on real wifi networks, and... I have no idea where that stands today. Yes a custom wifi7 AP and presumably wifi8 will be able to deal with it, but everything from the backoff mechanisms in the e2e TCP Prague code and the proposed implementations on routers just plain does not work except in a testbed. Fq_codel outperforms it across the board with perhaps, some increased sensivity to RFC3168 seems needed only. L4S (all transports actually) benefits a lot from packet pacing, and... wait for it... fq) Slow start and convergence issues are problematic also with l4s. Being backward incompatible with fq_codel's deployed treatment of RFC3168 E= CN. is a huge barrier too. The best use case I can think of for l4s is on a tightly controlled docsis network, pure wires and short RTTs only. The one implementation for 5G I have heard of was laughable in that they were only aiming for 200ms of induced latency on that. If on the other hand you look at fq (and also how well starlink is performing nowadays) and ccs like bbr, well... I do honestly think there is room for this sort of signalling somewhere on the internet, and do plan to add what I think will work to cake at some point in the future. I do wish SCE had won, as it was backwards compatible. On Tue, May 7, 2024 at 12:15=E2=80=AFPM Jeremy Austin w= rote: > > > > On Tue, May 7, 2024 at 11:11=E2=80=AFAM Dave Taht via Starlink wrote: >> >> The RFC is very plausible but the methods break down in multiple ways, >> particularly with wifi. > > > Dave, can you elaborate more on the failures? Are these being researched = or addressed in the current trials, in your opinion? > > Jeremy -- https://www.youtube.com/watch?v=3DBVFWSyMp3xg&t=3D1098s Waves Podcast Dave T=C3=A4ht CSO, LibreQos