From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 DB3323B29D for ; Tue, 27 Feb 2024 18:41:51 -0500 (EST) Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-dc6dcd9124bso5128400276.1 for ; Tue, 27 Feb 2024 15:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aterlo.com; s=google; t=1709077311; x=1709682111; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=f4jscd0yLHogV353ZqPzeccCkcL4fLXzd38FU8HrCPc=; b=U7Urv125+H7+W8Vq6ruNYextHs1PtV5Il1go6OQaeiaq6uTIJZNLtGkZ9G1LZ8xOk0 6RCvYra9QWDM4TitwTbM14PE6mWGxYq8iO02sEir1b6vRpIHaNtp4b6TWveaGK2QSd4L Z1xLDHe6NnHWyCjy00XHuOqapWfir2MTRsHw4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709077311; x=1709682111; h=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=f4jscd0yLHogV353ZqPzeccCkcL4fLXzd38FU8HrCPc=; b=dKBkJO083KiXsMt5uo+QuGgvUmzixK4jtD+m/Ot0bBsn1eWX7pLUYs4E/MZk0z3Qzz HpZYMbtViiHbaiR1alFcVfMy3vAWZOxQ12wiasmwSVa5R4cq2L5wmBbz8FilAB6etVji L1xcwE/c6iacwT/XGQg/UwuJ9B009Rrsx+q6EBotfGOm/6Zs5vPl3M3iHzQ9Bljw6GLI S6OJI+/zfdxgplDlqLPl++idQDjjlOH7prlf6W4U6F4UypONUGP34M5c7i7GFUFT7aKk b0HSeTR0VohKXOe9c4BWKEZoVbfpd5aF7jmOp2KXT8uoKQ8ZHyr9eRFTcy+ggi5i7Kcy S35Q== X-Gm-Message-State: AOJu0YwNjQAKAEAFQ5qqmhSNICI1aMx3vtqzQY5cHpQlgw1h6+AgceEM 9xqyExiRCDMG6yqGD4v39TNeSQSBbtzNxOHwmm4haOBns+75MEX60LDL4jSgRp39bgV991vyZll qqA9AgFJkB/gwbbQSXnKO6FGrcQ6EWf9VghOtw1weR5WRsv4fD+/HMw== X-Google-Smtp-Source: AGHT+IGIeqvmrsc+gvKk067pugCf65TPnRLhd6Sa3+dxq4ILsT87Za+E4dTZ4RCobSOrFuIG8KYCQkEaOvptuUcLSjA= X-Received: by 2002:a25:ab70:0:b0:dca:c369:face with SMTP id u103-20020a25ab70000000b00dcac369facemr1012579ybi.18.1709077311077; Tue, 27 Feb 2024 15:41:51 -0800 (PST) MIME-Version: 1.0 References: <766106EC-9F2B-4440-B7A6-5AA483EF45F0@comcast.com> <69133641c96091ed047e6bf11a2ff5d7@rjmcmahon.com> <71063fa7-ba1b-4da8-8252-73b1ff2dd29e@3kitty.org> In-Reply-To: <71063fa7-ba1b-4da8-8252-73b1ff2dd29e@3kitty.org> From: Jeremy Austin Date: Tue, 27 Feb 2024 14:41:40 -0900 Message-ID: To: =?UTF-8?Q?Network_Neutrality_is_back=21_Let=C2=B4s_make_the_technical_asp?= =?UTF-8?Q?ects_heard_this_time=21?= Content-Type: multipart/alternative; boundary="0000000000000553cc061265928f" Subject: Re: [NNagain] The FCC 2024 Section 706 Report, GN Docket No. 22-270 is out! X-BeenThere: nnagain@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: =?utf-8?q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_aspects_heard_this_time!?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2024 23:41:51 -0000 --0000000000000553cc061265928f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 27, 2024 at 2:17=E2=80=AFPM Jack Haverty via Nnagain < nnagain@lists.bufferbloat.net> wrote: > Has any ISP or regulatory body set a standard for latency necessary to > support interactive uses? > I think we can safely say no. Unfortunately, no. > > It seems to me that a 2+ second delay is way too high, and even if it > happens only occasionally, users may set up their systems to assume it ma= y > happen and compensate for it by ading their own buffering at the endpoint= s > and thereby reduce embarassing glitches. Maybe this explains those long > awkward pauses you commonly see when TV interviewers are trying to have a > conversation with someone at a remote site via Zoom, Skype, et al. > 2 second delays happen more often than you'd think on "untreated" connections. I have seen fiber connections with 15 seconds of induced latency (latency due to buffering, not end-to-end distance.) I have seen cable connections with 5 or 6 seconds of latency under *normal load*. This is in the last year alone. > > In the early Internet days we assumed there would be a need for multiple > types of service, such as a "bulk transfer" and "interactive", similar to > analogs in the non-electronic transport systems (e.g., Air Freight versus > Container Ship). The "Type Of Service" field was put in the IP header a= s > a placeholder for such mechanisms to be added to networks in the future, > In many other cases, high latency is a result of buffering at *every* change in link speed. As Preseem and LibreQoS have validated, even dynamic home and last-mile RF environments benefit significantly from flow isolation, better drops and packet pacing, no matter the ToS field. > > Of course if network capacity is truly unlimited there would be no need > now to provide different types of service. But these latency numbers > suggest that users' traffic demands are still sometimes exceeding network > capacities. Some of the network traffic is associated with interactive > uses, and other traffic is doing tasks such as backups to some cloud. > Treating them uniformly seems like bad engineering as well as bad policy. > It's not quite as simple as "traffic demands=E2=80=A6 exceeding network cap= acities" when you take into account dynamic link rates. Packets are either on the wire or they are not, and "capacity" is an emergent phenomenon rather than guaranteed end-to-end. Microbursts guarantee that packet rates will occasionally exceed link rates on even a high-capacity end-user connection fed by even faster core and interchange links. Treating types of traffic non-uniformly (when obeying other, voluntary, traffic- or offnet-generated signals) is susceptible to the tragedy of the commons. So far we have decent compromises, such as treating traffic according to its behavior. If it walks and quacks like a duck=E2=80=A6 > > I'm still not sure whether or not "network neutrality" regulations would > preclude offering different types of service, if the technical mechanisms > even implement such functionality. > > Theoretically L4S could be a "paid add-on", so to speak, but at this point, the overall market is the primary differentiator =E2=80=94 as an end user, = I will happily spend my dollars with an ISP that serves smaller plans that have better-managed latency-under-load ("Working Latency" per Stuart Cheshire, I believe), than one that gives me gigabit or multi-gigabit that falls on its face when under load. It will take a long time before everyone has an option to choose =E2=80=94 and to your original question, better standardiz= ed metrics are needed. Our customers so far have not pressed us to productize good-latency-as-a-service; they regard it as essential to customer satisfaction and retention. Jack > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain > These are largely my opinions, not necessarily my employer's. --=20 -- Jeremy Austin Sr. Product Manager Preseem | Aterlo Networks --0000000000000553cc061265928f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 27, 2024 at 2:17=E2=80=AF= PM Jack Haverty via Nnagain <nnagain@lists.bufferbloat.net> wrote:
=20 =20 =20
Has any ISP or regulatory body set a standard for latency necessary to support interactive uses?

I th= ink we can safely say no. Unfortunately, no.
=C2=A0=C2=A0
It seems to me that a 2+ second delay is way too high, and even if it happens only occasionally, users may set up their systems to assume it may happen and compensate for it by ading their own buffering at the endpoints and thereby reduce embarassing glitches.=C2= =A0 Maybe this explains those long awkward pauses you commonly see when TV interviewers are trying to have a conversation with someone at a remote site via Zoom, Skype, et al.

2 second delays happen more often than you'd think on "untr= eated" connections. I have seen fiber connections with 15 seconds of i= nduced latency (latency due to buffering, not end-to-end distance.) I have = seen cable connections with 5 or 6 seconds of latency under *normal load*. = This is in the last year alone.
=C2=A0

In the early Internet days we assumed there would be a need for multiple types of service, such as a "bulk transfer" and "interactive", similar to analogs in the non-electronic trans= port systems (e.g., Air Freight versus Container Ship).=C2=A0=C2=A0 The &quo= t;Type Of Service" field was put in the IP header as a placeholder for such mechanisms to be added to networks in the future,

In many other cases, high latency is a result of buffe= ring at *every* change in link speed. As Preseem and LibreQoS have validate= d, even dynamic home and last-mile RF environments benefit significantly fr= om flow isolation, better drops and packet pacing, no matter the ToS field.=

=C2=A0

Of course if network capacity is truly unlimited there would be no need now to provide different types of service.=C2=A0=C2=A0 But these l= atency numbers suggest that users' traffic demands are still sometimes exceeding network capacities.=C2=A0 Some of the network traffic is associated with interactive uses, and other traffic is doing tasks such as backups to some cloud.=C2=A0 Treating them uniformly seems like bad engineering as well as bad policy.

<= /div>
It's not quite as simple as "traffic demands=E2=80=A6 ex= ceeding network capacities" when you take into account dynamic link ra= tes. Packets are either on the wire or they are not, and "capacity&quo= t; is an emergent phenomenon rather than guaranteed end-to-end. Microbursts= guarantee that packet rates will occasionally exceed link rates on even a = high-capacity end-user connection fed by even faster core and interchange l= inks. Treating types of traffic non-uniformly (when obeying other, voluntar= y, traffic- or offnet-generated signals) is susceptible to the tragedy of t= he commons. So far we have decent compromises,=C2=A0such as treating traffi= c according to its behavior. If it walks and quacks like a duck=E2=80=A6
=C2=A0

I'm still not sure whether or not "network neutrality" re= gulations would preclude offering different types of service, if the technical mechanisms even implement such functionality.


Theoretically L4S could be a= "paid add-on", so to speak, but at this point, the overall marke= t is the primary differentiator =E2=80=94 as an end user, I will happily sp= end my dollars with an ISP that serves smaller plans that have better-manag= ed latency-under-load ("Working Latency" per Stuart Cheshire, I b= elieve), than one that gives me gigabit or multi-gigabit that falls on its = face when under load. It will take a long time before everyone has an optio= n to choose =E2=80=94 and to your original question, better standardized me= trics are needed.

Our customers so far have not pr= essed us to productize good-latency-as-a-service; they regard it as essenti= al to customer satisfaction and retention.

Jack
Nnagain mailing list
Nnagain@= lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain

These are largely my opinions, no= t necessarily my employer's.
--
--
Jeremy Austin
Sr. Product Manager
Pr= eseem | Aterlo Networks
--0000000000000553cc061265928f--