From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 D364B3CB43; Wed, 8 May 2024 07:32:56 -0400 (EDT) Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-792b934de39so16453085a.3; Wed, 08 May 2024 04:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715167976; x=1715772776; darn=lists.bufferbloat.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=YDsg1MWQEqo73BmLLmLcBIIHX0hzkZfwlr+sWzTmJts=; b=LIvZVA4YXEuBsV/AEanA7D4SfpA+1PlDCdwrHmVC40oKBnPynUj2i3vANR7j+Hn4mi febt6oTZVAmXQSuwjzOVf80EFf0MgVP3f6NAtCN2i5gRnwsdBT/eA4qyxiLBAbtv6l10 jiEt5E6z2RIQPeZduujd4+pvn0HyCdRFRZDIQLtT8l6u1yMQULxaKZ4gsFswP9+lldZj YGJQn/VQZjkwwJr1S3V7BpF92D0o6YZlCDd3Q5BtU8en6O3cd4dUx1+qWp+ltwAGGkBZ Al72O7BXgvphE5/fJXJhjpN55UZ+31PIODL2PsNfAZx1aJcLdURrb7HunevRiMdX4UjB nPWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715167976; x=1715772776; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YDsg1MWQEqo73BmLLmLcBIIHX0hzkZfwlr+sWzTmJts=; b=S8Jv7ddsI1JZeSpEszs94krT3ad8vv9+WSVgG0JwD4+ej1nUTfvTqj4rwePkoQBuOh dYngrHvIFYQ7C93xZrKuweOFIvc79bUNhYeX8FIyG6itM4D6W9KZ0tzCRp9+FwZnGN7t 1ZANeS+123INWQBFtUAnQCZ1n1IgaPX/7f+elPhCZArmZ2b3AnZCA9FKikFGBov9Jco3 3sXRzIoiq9lpftGPQlODa6Eq906AhzUs71Zdi4RdnC+KxIxt/RSkmMlVh/UxMqiJP0/c xo/5JTUrJidyje4ioFqA20i2n4MG7rO5p6RzteBo2UNNVipcK+dRhNGqEkc5DZnRfxky dqfw== X-Forwarded-Encrypted: i=1; AJvYcCU1unoeYUYQq1+sAGSPcliXH/Va08ZiGBYBJeIgxggGWjyj2FM/mV33JGUufCEMH8gPRIoOykitlUPkxcHkqnOEVtIgK/L73uKuRTQ= X-Gm-Message-State: AOJu0YzUPfMwnaCIG+gIcnAXyiSQ85Y6SGuC7wmIswBWXKoj4efwfqsr cwN+AYH7sodn5Fr+ltjuaA0odTOkrAC+wYcLqB7CilgRQegl8GpMx5nBuA== X-Google-Smtp-Source: AGHT+IEoc642FgpkquVrWSY3AdyS0/7WxefYwpAlPvhndmE5jk+88dh5/eiZPg5ildAOrbLLKkFziw== X-Received: by 2002:a05:620a:5608:b0:790:a573:4fdf with SMTP id af79cd13be357-792b2786923mr219480485a.2.1715167975856; Wed, 08 May 2024 04:32:55 -0700 (PDT) Received: from smtpclient.apple ([198.55.239.44]) by smtp.gmail.com with ESMTPSA id d6-20020a05620a240600b007928d82c49fsm4018129qkn.36.2024.05.08.04.32.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 May 2024 04:32:55 -0700 (PDT) From: Rich Brown Message-Id: <5F37F8F8-F467-4FF0-B3FD-4041DA245604@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6DB701B8-19A4-455B-89C7-7A87D4609768" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Date: Wed, 8 May 2024 07:32:53 -0400 In-Reply-To: Cc: starlink , bloat To: =?utf-8?Q?David_Fern=C3=A1ndez?= References: X-Mailer: Apple Mail (2.3696.120.41.1.8) Subject: Re: [Starlink] [Bloat] L4S 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 May 2024 11:32:56 -0000 --Apple-Mail=_6DB701B8-19A4-455B-89C7-7A87D4609768 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Let's split this thread and use this message to continue the discussion = of L4S. Thanks > On May 8, 2024, at 5:31 AM, David Fern=C3=A1ndez via Starlink = wrote: >=20 > I see that L4S is not really solving everything (I read about issues = with Wi-Fi), although it seems to be a step in the right direction, to = be improved, let's hope. >=20 > At least, Nokia is implementing it in its network gear (for mobile = operators), so the bufferbloat problem is somehow acknowledged by = industry, at least initially or partially. >=20 > I have seen two consecutive RFCs to 9330: > https://www.rfc-editor.org/info/rfc9331 = > https://www.rfc-editor.org/info/rfc9332 = >=20 > I suspect that optimal results require the bufferbloat to be addressed = not only at network layer (IP), but also with some pipelining or = cross-layering at link level (Ethernet, Wi-Fi or any other link = technology, such as 5G, SATCOM, VHF...) >=20 > Regards, >=20 > David F. >=20 > Date: Tue, 7 May 2024 08:46:03 -0400 > From: Dave Collier-Brown > > To: starlink@lists.bufferbloat.net = > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem > Message-ID: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com = > > Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowed" >=20 > It has an RFC at https://datatracker.ietf.org/doc/rfc9330/ = >=20 > I read it as a way to rapidly find the available bandwidth without the = TCP "sawtooth". The paper cites fc_codel and research based on it. >=20 > I suspect My Smarter Colleagues know more (;-)) >=20 > --dave >=20 >=20 >=20 > On 2024-05-07 08:13, David Fern=C3=A1ndez via Starlink wrote: > Is L4S a solution to bufferbloat? I have read that gamers are happy = with it. >=20 > Sorry, I read it here, in Spanish: > = https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vod= afone = >=20 > Regards, >=20 > David F. > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --Apple-Mail=_6DB701B8-19A4-455B-89C7-7A87D4609768 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Let's= split this thread and use this message to continue the discussion of = L4S. Thanks

On May 8, 2024, at 5:31 AM, David Fern=C3=A1nde= z via Starlink <starlink@lists.bufferbloat.net> wrote:

I see that L4S is not really solving = everything (I read about issues with Wi-Fi), although it seems to be a = step in the right direction, to be improved, let's hope.

At least, Nokia is = implementing it in its network gear (for mobile operators), so the = bufferbloat problem is somehow acknowledged by industry, at least = initially or partially.

I have seen two consecutive RFCs to = 9330:
https://www.rfc-editor.org/info/rfc9331
https://www.rfc-editor.org/info/rfc9332

I suspect that optimal = results require the bufferbloat to be addressed not only at network = layer (IP), but also=20 with some pipelining or cross-layering at link level (Ethernet, Wi-Fi or any other link technology, such as 5G, = SATCOM, VHF...)

Regards,

David F.

Date: Tue, 7 May 2024 08:46:03 -0400
From: Dave Collier-Brown <dave.collier-Brown@indexexchange.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a = problem
Message-ID: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com><= br class=3D""> Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowed"

It has an RFC at https://datatracker.ietf.org/doc/rfc9330/

I read it as a way to rapidly find the available bandwidth without the=20= TCP "sawtooth". The paper cites fc_codel and research based on it.

I suspect My Smarter Colleagues know more (;-))

--dave



On 2024-05-07 08:13, David Fern=C3=A1ndez via Starlink wrote:
Is L4S a solution to bufferbloat? I have read that gamers are happy with = it.

Sorry, I read it here, in Spanish:
https://www.adslzone.net/noticias/operadores/retardo-videojuego= s-nokia-vodafone

Regards,

David F.
_______________________________________________
Starlink = mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

= --Apple-Mail=_6DB701B8-19A4-455B-89C7-7A87D4609768--