Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
@ 2024-06-05 15:16 David Fernández
  2024-06-05 15:21 ` Bless, Roland (TM)
  2024-06-05 16:23 ` Sebastian Moeller
  0 siblings, 2 replies; 59+ messages in thread
From: David Fernández @ 2024-06-05 15:16 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]

Hi Sebastian,

" Our local regulator thinks that 150 ms access network OWD (so 300msRTT)
is acceptable"

Your local regulator is following ITU-T advice in Recommendation G.114,
where it is said that up to 150 ms one-way delay is acceptable for
telephony.

Regards,

David F.

Date: Wed, 5 Jun 2024 17:10:26 +0200
From: Sebastian Moeller <moeller0@gmx.de>
To: David Lang <david@lang.hm>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Dave Taht via
        Starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de>
Content-Type: text/plain;       charset=utf-8

Hi David,


> On 5. Jun 2024, at 16:16, David Lang via Starlink <
starlink@lists.bufferbloat.net> wrote:
>
> Alexandre Petrescu wrote:
>
>> Le 05/06/2024 à 15:40, Gert Doering a écrit :
>>> Hi,
>>>
>>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via
Starlink
>> wrote:
>>>> well, ok.  One day the satcom latency will be so low that we will not
have
>>>> enough requirements for its use :-)
>>> Your disbelief in physics keeps amazing me :-)
>>
>> sorry :-)  Rather than simply 'satcom' I should have said
satcom-haps-planes-drones.  I dont have a name for that.
>
> you would be better off with plans that don't require beating the speed
of light. Yes, quantum entanglement may be a path to beat the speed of
light, but you still need the electronics to handle it, and have the speed
of sound at temperatures and pressures that humans can live at as a
restriction.
>
> by comparison to your 1ms latency goals, extensive AT&T phone testing
decades ago showed that 100ms was the threshold where people could start to
detect a delay.

Would you have any pointer for that study/those studies? Our local
regulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable
and I am trying to find studies that can shed a light on what acceptable
delay is for different kind of interactive tasks. (Spoiler alert, I am not
convinced that 300ms RTT is a great idea, I forced my self to remote
desktop with artificial 300ms delay and it was not fun, but not totaly
unusable either, but then human can adapt and steer high inertia vehicles
like loaded container ships...)

Sorry for the tangent...

Regards
        Sebastian

P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of
sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343
m/millisecond that is even at a distance of 1 meter delay will be at a 3
ms... and when talking to folks 10m away it is not the delay that is
annoying, but the fact that you have to raise your voice considerably...

>
> David Lang_______________________________________________

[-- Attachment #2: Type: text/html, Size: 3753 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 15:16 [Starlink] The "reasons" that bufferbloat isn't a problem David Fernández
@ 2024-06-05 15:21 ` Bless, Roland (TM)
  2024-06-05 15:32   ` David Fernández
  2024-06-05 16:24   ` Sebastian Moeller
  2024-06-05 16:23 ` Sebastian Moeller
  1 sibling, 2 replies; 59+ messages in thread
From: Bless, Roland (TM) @ 2024-06-05 15:21 UTC (permalink / raw)
  To: David Fernández, starlink

Hi,

On 05.06.24 at 17:16 David Fernández via Starlink wrote:
> " Our local regulator thinks that 150 ms access network OWD (so 
> 300msRTT) is acceptable"
> 
> Your local regulator is following ITU-T advice in Recommendation G.114, 
> where it is said that up to 150 ms one-way delay is acceptable for 
> telephony.

That is actually mouth-to-ear delay IIRC, so network delay is only a 
part of it. One has to consider play-buffering delay and codec delay
as well. Interactive gaming usually requires smaller delays for a good
QoE.

Regards,
  Roland

> Date: Wed, 5 Jun 2024 17:10:26 +0200
> From: Sebastian Moeller <moeller0@gmx.de <mailto:moeller0@gmx.de>>
> To: David Lang <david@lang.hm <mailto:david@lang.hm>>
> Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com 
> <mailto:alexandre.petrescu@gmail.com>>, Dave Taht via
>          Starlink <starlink@lists.bufferbloat.net 
> <mailto:starlink@lists.bufferbloat.net>>
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de 
> <mailto:C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de>>
> Content-Type: text/plain;       charset=utf-8
> 
> Hi David,
> 
> 
>  > On 5. Jun 2024, at 16:16, David Lang via Starlink 
> <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> 
> wrote:
>  >
>  > Alexandre Petrescu wrote:
>  >
>  >> Le 05/06/2024 à 15:40, Gert Doering a écrit :
>  >>> Hi,
>  >>>
>  >>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via 
> Starlink
>  >> wrote:
>  >>>> well, ok.  One day the satcom latency will be so low that we will 
> not have
>  >>>> enough requirements for its use :-)
>  >>> Your disbelief in physics keeps amazing me :-)
>  >>
>  >> sorry :-)  Rather than simply 'satcom' I should have said 
> satcom-haps-planes-drones.  I dont have a name for that.
>  >
>  > you would be better off with plans that don't require beating the 
> speed of light. Yes, quantum entanglement may be a path to beat the 
> speed of light, but you still need the electronics to handle it, and 
> have the speed of sound at temperatures and pressures that humans can 
> live at as a restriction.
>  >
>  > by comparison to your 1ms latency goals, extensive AT&T phone testing 
> decades ago showed that 100ms was the threshold where people could start 
> to detect a delay.
> 
> Would you have any pointer for that study/those studies? Our local 
> regulator thinks that 150 ms access network OWD (so 300msRTT) is 
> acceptable and I am trying to find studies that can shed a light on what 
> acceptable delay is for different kind of interactive tasks. (Spoiler 
> alert, I am not convinced that 300ms RTT is a great idea, I forced my 
> self to remote desktop with artificial 300ms delay and it was not fun, 
> but not totaly unusable either, but then human can adapt and steer high 
> inertia vehicles like loaded container ships...)
> 
> Sorry for the tangent...
> 
> Regards
>          Sebastian
> 
> P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of 
> sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343 
> m/millisecond that is even at a distance of 1 meter delay will be at a 3 
> ms... and when talking to folks 10m away it is not the delay that is 
> annoying, but the fact that you have to raise your voice considerably...
> 
>  >
>  > David Lang_______________________________________________


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 15:21 ` Bless, Roland (TM)
@ 2024-06-05 15:32   ` David Fernández
  2024-06-05 16:24   ` Sebastian Moeller
  1 sibling, 0 replies; 59+ messages in thread
From: David Fernández @ 2024-06-05 15:32 UTC (permalink / raw)
  To: Bless, Roland (TM); +Cc: starlink

[-- Attachment #1: Type: text/plain, Size: 3924 bytes --]

Hi Roland,

You remember well. That's right. In video is called glass-to-glass latency
and it can be measured with this, for example:
https://hamtv.com/latencytest.html

Regards,

David F.

On Wed, 5 Jun 2024 at 17:21, Bless, Roland (TM) <roland.bless@kit.edu>
wrote:

> Hi,
>
> On 05.06.24 at 17:16 David Fernández via Starlink wrote:
> > " Our local regulator thinks that 150 ms access network OWD (so
> > 300msRTT) is acceptable"
> >
> > Your local regulator is following ITU-T advice in Recommendation G.114,
> > where it is said that up to 150 ms one-way delay is acceptable for
> > telephony.
>
> That is actually mouth-to-ear delay IIRC, so network delay is only a
> part of it. One has to consider play-buffering delay and codec delay
> as well. Interactive gaming usually requires smaller delays for a good
> QoE.
>
> Regards,
>   Roland
>
> > Date: Wed, 5 Jun 2024 17:10:26 +0200
> > From: Sebastian Moeller <moeller0@gmx.de <mailto:moeller0@gmx.de>>
> > To: David Lang <david@lang.hm <mailto:david@lang.hm>>
> > Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com
> > <mailto:alexandre.petrescu@gmail.com>>, Dave Taht via
> >          Starlink <starlink@lists.bufferbloat.net
> > <mailto:starlink@lists.bufferbloat.net>>
> > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> > Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de
> > <mailto:C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de>>
> > Content-Type: text/plain;       charset=utf-8
> >
> > Hi David,
> >
> >
> >  > On 5. Jun 2024, at 16:16, David Lang via Starlink
> > <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>
> > wrote:
> >  >
> >  > Alexandre Petrescu wrote:
> >  >
> >  >> Le 05/06/2024 à 15:40, Gert Doering a écrit :
> >  >>> Hi,
> >  >>>
> >  >>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via
> > Starlink
> >  >> wrote:
> >  >>>> well, ok.  One day the satcom latency will be so low that we will
> > not have
> >  >>>> enough requirements for its use :-)
> >  >>> Your disbelief in physics keeps amazing me :-)
> >  >>
> >  >> sorry :-)  Rather than simply 'satcom' I should have said
> > satcom-haps-planes-drones.  I dont have a name for that.
> >  >
> >  > you would be better off with plans that don't require beating the
> > speed of light. Yes, quantum entanglement may be a path to beat the
> > speed of light, but you still need the electronics to handle it, and
> > have the speed of sound at temperatures and pressures that humans can
> > live at as a restriction.
> >  >
> >  > by comparison to your 1ms latency goals, extensive AT&T phone testing
> > decades ago showed that 100ms was the threshold where people could start
> > to detect a delay.
> >
> > Would you have any pointer for that study/those studies? Our local
> > regulator thinks that 150 ms access network OWD (so 300msRTT) is
> > acceptable and I am trying to find studies that can shed a light on what
> > acceptable delay is for different kind of interactive tasks. (Spoiler
> > alert, I am not convinced that 300ms RTT is a great idea, I forced my
> > self to remote desktop with artificial 300ms delay and it was not fun,
> > but not totaly unusable either, but then human can adapt and steer high
> > inertia vehicles like loaded container ships...)
> >
> > Sorry for the tangent...
> >
> > Regards
> >          Sebastian
> >
> > P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of
> > sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343
> > m/millisecond that is even at a distance of 1 meter delay will be at a 3
> > ms... and when talking to folks 10m away it is not the delay that is
> > annoying, but the fact that you have to raise your voice considerably...
> >
> >  >
> >  > David Lang_______________________________________________
>
>

[-- Attachment #2: Type: text/html, Size: 5815 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 15:16 [Starlink] The "reasons" that bufferbloat isn't a problem David Fernández
  2024-06-05 15:21 ` Bless, Roland (TM)
@ 2024-06-05 16:23 ` Sebastian Moeller
  2024-06-06  7:07   ` David Fernández
  1 sibling, 1 reply; 59+ messages in thread
From: Sebastian Moeller @ 2024-06-05 16:23 UTC (permalink / raw)
  To: David Fernández; +Cc: starlink

Hi David,

Thanks!

> On 5. Jun 2024, at 17:16, David Fernández via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Hi Sebastian,
> 
> " Our local regulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable"
> 
> Your local regulator is following ITU-T advice in Recommendation G.114, where it is said that up to 150 ms one-way delay is acceptable for telephony.

[SM] Yes that is one of their sources for VoIP, and I already started to find the original studies as I am not convinced the interpretation in 114 is the only possible or even best, after all Telcos had a clear use-case transatlantic phone calls that they did want to survive as possible in good quality...

But the regulator also argues the same 300ms RTT for remote desktop applications... any data showing what latency is acceptable for specific use cases is appreciated. (And I am open for the option that my hunch that 300ms is too much might be wrong).

Regards
	Sebastian

> 
> Regards,
> 
> David F.
> 
> Date: Wed, 5 Jun 2024 17:10:26 +0200
> From: Sebastian Moeller <moeller0@gmx.de>
> To: David Lang <david@lang.hm>
> Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Dave Taht via
>         Starlink <starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de>
> Content-Type: text/plain;       charset=utf-8
> 
> Hi David,
> 
> 
> > On 5. Jun 2024, at 16:16, David Lang via Starlink <starlink@lists.bufferbloat.net> wrote:
> > 
> > Alexandre Petrescu wrote:
> > 
> >> Le 05/06/2024 à 15:40, Gert Doering a écrit :
> >>> Hi,
> >>> 
> >>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via Starlink
> >> wrote:
> >>>> well, ok.  One day the satcom latency will be so low that we will not have
> >>>> enough requirements for its use :-)
> >>> Your disbelief in physics keeps amazing me :-)
> >> 
> >> sorry :-)  Rather than simply 'satcom' I should have said satcom-haps-planes-drones.  I dont have a name for that.
> > 
> > you would be better off with plans that don't require beating the speed of light. Yes, quantum entanglement may be a path to beat the speed of light, but you still need the electronics to handle it, and have the speed of sound at temperatures and pressures that humans can live at as a restriction.
> > 
> > by comparison to your 1ms latency goals, extensive AT&T phone testing decades ago showed that 100ms was the threshold where people could start to detect a delay.
> 
> Would you have any pointer for that study/those studies? Our local regulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable and I am trying to find studies that can shed a light on what acceptable delay is for different kind of interactive tasks. (Spoiler alert, I am not convinced that 300ms RTT is a great idea, I forced my self to remote desktop with artificial 300ms delay and it was not fun, but not totaly unusable either, but then human can adapt and steer high inertia vehicles like loaded container ships...)
> 
> Sorry for the tangent...
> 
> Regards
>         Sebastian
> 
> P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343 m/millisecond that is even at a distance of 1 meter delay will be at a 3 ms... and when talking to folks 10m away it is not the delay that is annoying, but the fact that you have to raise your voice considerably...
> 
> > 
> > David Lang_______________________________________________
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 15:21 ` Bless, Roland (TM)
  2024-06-05 15:32   ` David Fernández
@ 2024-06-05 16:24   ` Sebastian Moeller
  2024-06-06 23:10     ` Michael Richardson
  1 sibling, 1 reply; 59+ messages in thread
From: Sebastian Moeller @ 2024-06-05 16:24 UTC (permalink / raw)
  To: Bless, Roland (TM); +Cc: David Fernández, starlink

Hi Roland,

Thanks!

> On 5. Jun 2024, at 17:21, Bless, Roland (TM) via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Hi,
> 
> On 05.06.24 at 17:16 David Fernández via Starlink wrote:
>> " Our local regulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable"
>> Your local regulator is following ITU-T advice in Recommendation G.114, where it is said that up to 150 ms one-way delay is acceptable for telephony.
> 
> That is actually mouth-to-ear delay IIRC, so network delay is only a part of it. One has to consider play-buffering delay and codec delay
> as well. Interactive gaming usually requires smaller delays for a good
> QoE.

[SM] Yes, however Gaming is not in the enumerated list of use-cases the regulator cares about (in the context of the minimal internet quality end users are guaranteed).

> 
> Regards,
> Roland
> 
>> Date: Wed, 5 Jun 2024 17:10:26 +0200
>> From: Sebastian Moeller <moeller0@gmx.de <mailto:moeller0@gmx.de>>
>> To: David Lang <david@lang.hm <mailto:david@lang.hm>>
>> Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>, Dave Taht via
>>         Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
>> Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de <mailto:C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de>>
>> Content-Type: text/plain;       charset=utf-8
>> Hi David,
>> > On 5. Jun 2024, at 16:16, David Lang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> >
>> > Alexandre Petrescu wrote:
>> >
>> >> Le 05/06/2024 à 15:40, Gert Doering a écrit :
>> >>> Hi,
>> >>>
>> >>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via Starlink
>> >> wrote:
>> >>>> well, ok.  One day the satcom latency will be so low that we will not have
>> >>>> enough requirements for its use :-)
>> >>> Your disbelief in physics keeps amazing me :-)
>> >>
>> >> sorry :-)  Rather than simply 'satcom' I should have said satcom-haps-planes-drones.  I dont have a name for that.
>> >
>> > you would be better off with plans that don't require beating the speed of light. Yes, quantum entanglement may be a path to beat the speed of light, but you still need the electronics to handle it, and have the speed of sound at temperatures and pressures that humans can live at as a restriction.
>> >
>> > by comparison to your 1ms latency goals, extensive AT&T phone testing decades ago showed that 100ms was the threshold where people could start to detect a delay.
>> Would you have any pointer for that study/those studies? Our local regulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable and I am trying to find studies that can shed a light on what acceptable delay is for different kind of interactive tasks. (Spoiler alert, I am not convinced that 300ms RTT is a great idea, I forced my self to remote desktop with artificial 300ms delay and it was not fun, but not totaly unusable either, but then human can adapt and steer high inertia vehicles like loaded container ships...)
>> Sorry for the tangent...
>> Regards
>>         Sebastian
>> P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343 m/millisecond that is even at a distance of 1 meter delay will be at a 3 ms... and when talking to folks 10m away it is not the delay that is annoying, but the fact that you have to raise your voice considerably...
>> >
>> > David Lang_______________________________________________
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 16:23 ` Sebastian Moeller
@ 2024-06-06  7:07   ` David Fernández
  2024-06-06  7:41     ` Sebastian Moeller
  0 siblings, 1 reply; 59+ messages in thread
From: David Fernández @ 2024-06-06  7:07 UTC (permalink / raw)
  To: Sebastian Moeller; +Cc: starlink

[-- Attachment #1: Type: text/plain, Size: 4850 bytes --]

Hi Sebastian,

You are welcome! Your ISP seems to take the maximum limit also for RTT for
RDP recommended by Microsoft users (300 ms RTT):
https://learn.microsoft.com/en-us/archive/msdn-technet-forums/165af0fb-b3f0-469f-bc67-548fa26da266
The good quality threshold for Remote Desktop could be 150 ms RTT.

I find it risky to work so much close to the threshold of quality becoming
bad for services, but they may have money based reasons to do that.
There is also no point on going better than the threshold of it being good,
as mentioned here (it is wasteful):
https://www.rohde-schwarz.com/fi/solutions/test-and-measurement/mobile-network-testing/network-performance-score/network-performance-score_250678.html#video-rs-636544

Regards,

David F.

On Wed, 5 Jun 2024 at 18:23, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi David,
>
> Thanks!
>
> > On 5. Jun 2024, at 17:16, David Fernández via Starlink <
> starlink@lists.bufferbloat.net> wrote:
> >
> > Hi Sebastian,
> >
> > " Our local regulator thinks that 150 ms access network OWD (so
> 300msRTT) is acceptable"
> >
> > Your local regulator is following ITU-T advice in Recommendation G.114,
> where it is said that up to 150 ms one-way delay is acceptable for
> telephony.
>
> [SM] Yes that is one of their sources for VoIP, and I already started to
> find the original studies as I am not convinced the interpretation in 114
> is the only possible or even best, after all Telcos had a clear use-case
> transatlantic phone calls that they did want to survive as possible in good
> quality...
>
> But the regulator also argues the same 300ms RTT for remote desktop
> applications... any data showing what latency is acceptable for specific
> use cases is appreciated. (And I am open for the option that my hunch that
> 300ms is too much might be wrong).
>
> Regards
>         Sebastian
>
> >
> > Regards,
> >
> > David F.
> >
> > Date: Wed, 5 Jun 2024 17:10:26 +0200
> > From: Sebastian Moeller <moeller0@gmx.de>
> > To: David Lang <david@lang.hm>
> > Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Dave Taht via
> >         Starlink <starlink@lists.bufferbloat.net>
> > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> > Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de>
> > Content-Type: text/plain;       charset=utf-8
> >
> > Hi David,
> >
> >
> > > On 5. Jun 2024, at 16:16, David Lang via Starlink <
> starlink@lists.bufferbloat.net> wrote:
> > >
> > > Alexandre Petrescu wrote:
> > >
> > >> Le 05/06/2024 à 15:40, Gert Doering a écrit :
> > >>> Hi,
> > >>>
> > >>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via
> Starlink
> > >> wrote:
> > >>>> well, ok.  One day the satcom latency will be so low that we will
> not have
> > >>>> enough requirements for its use :-)
> > >>> Your disbelief in physics keeps amazing me :-)
> > >>
> > >> sorry :-)  Rather than simply 'satcom' I should have said
> satcom-haps-planes-drones.  I dont have a name for that.
> > >
> > > you would be better off with plans that don't require beating the
> speed of light. Yes, quantum entanglement may be a path to beat the speed
> of light, but you still need the electronics to handle it, and have the
> speed of sound at temperatures and pressures that humans can live at as a
> restriction.
> > >
> > > by comparison to your 1ms latency goals, extensive AT&T phone testing
> decades ago showed that 100ms was the threshold where people could start to
> detect a delay.
> >
> > Would you have any pointer for that study/those studies? Our local
> regulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable
> and I am trying to find studies that can shed a light on what acceptable
> delay is for different kind of interactive tasks. (Spoiler alert, I am not
> convinced that 300ms RTT is a great idea, I forced my self to remote
> desktop with artificial 300ms delay and it was not fun, but not totaly
> unusable either, but then human can adapt and steer high inertia vehicles
> like loaded container ships...)
> >
> > Sorry for the tangent...
> >
> > Regards
> >         Sebastian
> >
> > P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of
> sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343
> m/millisecond that is even at a distance of 1 meter delay will be at a 3
> ms... and when talking to folks 10m away it is not the delay that is
> annoying, but the fact that you have to raise your voice considerably...
> >
> > >
> > > David Lang_______________________________________________
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>
>
>

[-- Attachment #2: Type: text/html, Size: 6679 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-06  7:07   ` David Fernández
@ 2024-06-06  7:41     ` Sebastian Moeller
  0 siblings, 0 replies; 59+ messages in thread
From: Sebastian Moeller @ 2024-06-06  7:41 UTC (permalink / raw)
  To: David Fernández; +Cc: starlink

Hi David,


> On 6. Jun 2024, at 09:07, David Fernández <davidfdzp@gmail.com> wrote:
> 
> Hi Sebastian,
> 
> You are welcome! Your ISP seems to take the maximum limit also for RTT for RDP recommended by Microsoft users (300 ms RTT):
> https://learn.microsoft.com/en-us/archive/msdn-technet-forums/165af0fb-b3f0-469f-bc67-548fa26da266
> The good quality threshold for Remote Desktop could be 150 ms RTT.

[SM] Honestly the numbers from AWS/Azure are pretty useless as IMHO it is maximally unclear when/if the mean delay as in RTT and when as in OWD, and reading through this I am convinced that they are not talking exclusively about one or the other... And with all respect to the boffins at the cloud providers, for an interactive thing like remote desktop OWD makes very little sense... as a user expects to see reactions to all actions he/she initiates. But I am not looking to address this by saying "you (or rather the paid consultants writing the assessments) interpret the data wrong" I would rather like to present a "have you had a look at recent and pertinent study", so giving everybody a way of not loosing face...


> I find it risky to work so much close to the threshold of quality becoming bad for services, but they may have money based reasons to do that. 

[SM] They do, the minimal internet guarantees define the internet service each inhabitant of Germany is entitled to receive (currently >= 10/1.7 Mbps Down/UP, with <=150ms OWDs, or <= 300ms RTT). ISPs will be forced to supply that at a 'reasonable price' (essentially the average price of the service class in Germany). BUT if the ISP can show that this results in losses the ISP will be 'made whole' out of state funds. So yes there is a cost component to this, and the official plan is (still) to reach 100% availability of gigabit plans by 2030, so it is expected these minimal guarantees to be rare in actual use. 

> There is also no point on going better than the threshold of it being good, as mentioned here (it is wasteful):
> https://www.rohde-schwarz.com/fi/solutions/test-and-measurement/mobile-network-testing/network-performance-score/network-performance-score_250678.html#video-rs-636544

[SM] I guess that makes a ton of sense, as does not making the guaranteed minimus a gold-plated extravaganza... still remote desktop with 300ms RTT is decidedly little fun, and I would hope to be able to push this number down a peg... (150ms RTT IMHO wold be considerably less terrible even for a guaranteed minimum).
As is the 300ms RTT limit at least rules out geo stationary satellite as suitable providers.

And the cycle back the the topic of this list, LEO are well within that limit and starlink especially with the recent push for lower latency, pretty comfortably. Which is a good thing, as the regulator just tasked Starlink to supply one such case in which traditional ISPs could not deliver the minimal guarantees. The situation is a bit complicated in that the affected households are likely to receive FTTH by 2030 and none of the two fixed net ISP operating there prepared to deploy FTTH right now and made the argument that extending the copper network now only to switch to FTTH by 2030 would be a massive waste of resources...
Anyway, for the affected households starlink will be a decent solution allowing to comfortably wait for FTTH deployment...

Regards
	Sebastian


> 
> Regards,
> 
> David F.
> 
> On Wed, 5 Jun 2024 at 18:23, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi David,
> 
> Thanks!
> 
> > On 5. Jun 2024, at 17:16, David Fernández via Starlink <starlink@lists.bufferbloat.net> wrote:
> > 
> > Hi Sebastian,
> > 
> > " Our local regulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable"
> > 
> > Your local regulator is following ITU-T advice in Recommendation G.114, where it is said that up to 150 ms one-way delay is acceptable for telephony.
> 
> [SM] Yes that is one of their sources for VoIP, and I already started to find the original studies as I am not convinced the interpretation in 114 is the only possible or even best, after all Telcos had a clear use-case transatlantic phone calls that they did want to survive as possible in good quality...
> 
> But the regulator also argues the same 300ms RTT for remote desktop applications... any data showing what latency is acceptable for specific use cases is appreciated. (And I am open for the option that my hunch that 300ms is too much might be wrong).
> 
> Regards
>         Sebastian
> 
> > 
> > Regards,
> > 
> > David F.
> > 
> > Date: Wed, 5 Jun 2024 17:10:26 +0200
> > From: Sebastian Moeller <moeller0@gmx.de>
> > To: David Lang <david@lang.hm>
> > Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Dave Taht via
> >         Starlink <starlink@lists.bufferbloat.net>
> > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> > Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de>
> > Content-Type: text/plain;       charset=utf-8
> > 
> > Hi David,
> > 
> > 
> > > On 5. Jun 2024, at 16:16, David Lang via Starlink <starlink@lists.bufferbloat.net> wrote:
> > > 
> > > Alexandre Petrescu wrote:
> > > 
> > >> Le 05/06/2024 à 15:40, Gert Doering a écrit :
> > >>> Hi,
> > >>> 
> > >>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via Starlink
> > >> wrote:
> > >>>> well, ok.  One day the satcom latency will be so low that we will not have
> > >>>> enough requirements for its use :-)
> > >>> Your disbelief in physics keeps amazing me :-)
> > >> 
> > >> sorry :-)  Rather than simply 'satcom' I should have said satcom-haps-planes-drones.  I dont have a name for that.
> > > 
> > > you would be better off with plans that don't require beating the speed of light. Yes, quantum entanglement may be a path to beat the speed of light, but you still need the electronics to handle it, and have the speed of sound at temperatures and pressures that humans can live at as a restriction.
> > > 
> > > by comparison to your 1ms latency goals, extensive AT&T phone testing decades ago showed that 100ms was the threshold where people could start to detect a delay.
> > 
> > Would you have any pointer for that study/those studies? Our local regulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable and I am trying to find studies that can shed a light on what acceptable delay is for different kind of interactive tasks. (Spoiler alert, I am not convinced that 300ms RTT is a great idea, I forced my self to remote desktop with artificial 300ms delay and it was not fun, but not totaly unusable either, but then human can adapt and steer high inertia vehicles like loaded container ships...)
> > 
> > Sorry for the tangent...
> > 
> > Regards
> >         Sebastian
> > 
> > P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343 m/millisecond that is even at a distance of 1 meter delay will be at a 3 ms... and when talking to folks 10m away it is not the delay that is annoying, but the fact that you have to raise your voice considerably...
> > 
> > > 
> > > David Lang_______________________________________________
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> 
> 


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 16:24   ` Sebastian Moeller
@ 2024-06-06 23:10     ` Michael Richardson
  2024-06-07  1:39       ` David Lang
  2024-06-07  6:20       ` Sebastian Moeller
  0 siblings, 2 replies; 59+ messages in thread
From: Michael Richardson @ 2024-06-06 23:10 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]


Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
    > [SM] Yes, however Gaming is not in the enumerated list of use-cases the
    > regulator cares about (in the context of the minimal internet quality
    > end users are guaranteed).

That's too bad, because online work/school are effectively a technology
subset of gaming :-)
And gamers seem to know good quality, it's somewhat easy to test and gamers
aren't afraid to demand it, changing ISPs if they have to.





[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-06 23:10     ` Michael Richardson
@ 2024-06-07  1:39       ` David Lang
  2024-06-07  6:20       ` Sebastian Moeller
  1 sibling, 0 replies; 59+ messages in thread
From: David Lang @ 2024-06-07  1:39 UTC (permalink / raw)
  To: Michael Richardson; +Cc: starlink

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

Michael Richardson wrote:

> And gamers seem to know good quality, it's somewhat easy to test and gamers
> aren't afraid to demand it, changing ISPs if they have to.

If they have the option to you mean.

David Lang

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-06 23:10     ` Michael Richardson
  2024-06-07  1:39       ` David Lang
@ 2024-06-07  6:20       ` Sebastian Moeller
  2024-06-07 17:41         ` Eugene Y Chang
  1 sibling, 1 reply; 59+ messages in thread
From: Sebastian Moeller @ 2024-06-07  6:20 UTC (permalink / raw)
  To: Michael Richardson; +Cc: starlink

Hi MIchael,


> On 7. Jun 2024, at 01:10, Michael Richardson via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> 
> Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
>> [SM] Yes, however Gaming is not in the enumerated list of use-cases the
>> regulator cares about (in the context of the minimal internet quality
>> end users are guaranteed).
> 
> That's too bad, because online work/school are effectively a technology
> subset of gaming :-)

[SM] I tend to agree that gamers can be seen as canaries in the coal mine regarding latency, but in this specific case my opion on what should or should not be taken into account is irrelevant, because the list of use-cases is explicitly mentioned in the text of the law...  First by referencing DIRECTIVE (EU) 2018/1972 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 December 2018 establishing the European Electronic Communications Code
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018L1972#d1e32-196-1
ANNEX V
MINIMUM SET OF SERVICES WHICH THE ADEQUATE BROADBAND INTERNET ACCESS SERVICE IN ACCORDANCE WITH ARTICLE 84(3) SHALL BE CAPABLE OF SUPPORTING
(1) E-mail
(2) search engines enabling search and finding of all type of information(
3) basic training and education online tools
(4) online newspapers or news
(5) buying or ordering goods or services online
(6) job searching and job searching tools
(7) professional networking
(8) internet banking
(9) eGovernment service use
(10) social media and instant messaging
(11) calls and video calls (standard quality)

and then by adding
"Teleheimarbeit einschließlich Verschlüsselungsverfahren im üblichen Umfang und eine für Verbraucher marktübliche Nutzung von Online-Inhaltediensten ermöglichen."

in the text iof the law, which roughly translates to:
home office/remote desktop including common encryption methods as well as a the capability to per-use on-line content services on a level appropriate for consumers.

Note how gaming is not enumerated and at best could be read into the 'in-line content' clause... or maybe the "(5) buying or ordering goods or services online". I see an uphill battle arguing for loiw latency if all I can bring, is 'gamers desire/require' lower latencies... (not that this argument is wrong, but it ewill give me little leverage as gaming, for all the revenue it brings (bigger than Hollywood) is not held in high regard).

> And gamers seem to know good quality, it's somewhat easy to test and gamers
> aren't afraid to demand it, changing ISPs if they have to.

[SM] The context here is a right to getting internet access with specific minimum guarantees at an affordable price, people who will need to use this law likely have no real options... otherwise no need to pound on that law... 

Regards
	Sebastian

> 
> 
> 
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-07  6:20       ` Sebastian Moeller
@ 2024-06-07 17:41         ` Eugene Y Chang
  2024-06-07 17:51           ` David Lang
  0 siblings, 1 reply; 59+ messages in thread
From: Eugene Y Chang @ 2024-06-07 17:41 UTC (permalink / raw)
  To: Sebastian Moeller
  Cc: Eugene Y Chang, Michael Richardson, Dave Taht via Starlink


[-- Attachment #1.1: Type: text/plain, Size: 3978 bytes --]

Very interesting to see this enumeration of use cases.

A lot of business processes use a web portal, e.g. SalesForce. Their productivity is highly sensitive to latency. The closes categorization that legislators/regulators might relate to is telemarketing. A lot of business solutions use the similar technology but not for telemarketing. Any ideas on a better name for this group of business solutions. Having a named use case that is sensitive to latency would help.

Gene
----------------------------------------------
Eugene Chang
eugene.chang@ieee.org
o 781-799-0233




> On Jun 6, 2024, at 8:20 PM, Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Hi MIchael,
> 
> 
>> On 7. Jun 2024, at 01:10, Michael Richardson via Starlink <starlink@lists.bufferbloat.net> wrote:
>> 
>> 
>> Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
>>> [SM] Yes, however Gaming is not in the enumerated list of use-cases the
>>> regulator cares about (in the context of the minimal internet quality
>>> end users are guaranteed).
>> 
>> That's too bad, because online work/school are effectively a technology
>> subset of gaming :-)
> 
> [SM] I tend to agree that gamers can be seen as canaries in the coal mine regarding latency, but in this specific case my opion on what should or should not be taken into account is irrelevant, because the list of use-cases is explicitly mentioned in the text of the law...  First by referencing DIRECTIVE (EU) 2018/1972 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 December 2018 establishing the European Electronic Communications Code
> https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018L1972#d1e32-196-1
> ANNEX V
> MINIMUM SET OF SERVICES WHICH THE ADEQUATE BROADBAND INTERNET ACCESS SERVICE IN ACCORDANCE WITH ARTICLE 84(3) SHALL BE CAPABLE OF SUPPORTING
> (1) E-mail
> (2) search engines enabling search and finding of all type of information(
> 3) basic training and education online tools
> (4) online newspapers or news
> (5) buying or ordering goods or services online
> (6) job searching and job searching tools
> (7) professional networking
> (8) internet banking
> (9) eGovernment service use
> (10) social media and instant messaging
> (11) calls and video calls (standard quality)
> 
> and then by adding
> "Teleheimarbeit einschließlich Verschlüsselungsverfahren im üblichen Umfang und eine für Verbraucher marktübliche Nutzung von Online-Inhaltediensten ermöglichen."
> 
> in the text iof the law, which roughly translates to:
> home office/remote desktop including common encryption methods as well as a the capability to per-use on-line content services on a level appropriate for consumers.
> 
> Note how gaming is not enumerated and at best could be read into the 'in-line content' clause... or maybe the "(5) buying or ordering goods or services online". I see an uphill battle arguing for loiw latency if all I can bring, is 'gamers desire/require' lower latencies... (not that this argument is wrong, but it ewill give me little leverage as gaming, for all the revenue it brings (bigger than Hollywood) is not held in high regard).
> 
>> And gamers seem to know good quality, it's somewhat easy to test and gamers
>> aren't afraid to demand it, changing ISPs if they have to.
> 
> [SM] The context here is a right to getting internet access with specific minimum guarantees at an affordable price, people who will need to use this law likely have no real options... otherwise no need to pound on that law...
> 
> Regards
> 	Sebastian
> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


[-- Attachment #1.2: Type: text/html, Size: 11538 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-07 17:41         ` Eugene Y Chang
@ 2024-06-07 17:51           ` David Lang
  2024-06-07 20:09             ` Eugene Y Chang
  0 siblings, 1 reply; 59+ messages in thread
From: David Lang @ 2024-06-07 17:51 UTC (permalink / raw)
  To: Eugene Y Chang; +Cc: Sebastian Moeller, Dave Taht via Starlink

[-- Attachment #1: Type: text/plain, Size: 3600 bytes --]

On Fri, 7 Jun 2024, Eugene Y Chang via Starlink wrote:

> A lot of business processes use a web portal, e.g. SalesForce. Their productivity is highly sensitive to latency. The closes categorization that legislators/regulators might relate to is telemarketing. A lot of business solutions use the similar technology but not for telemarketing. Any ideas on a better name for this group of business solutions. Having a named use case that is sensitive to latency would help.

I would expect that any ISP tht does well for 5-10 would work for that use case. 
Does it really need a separate category listed?

David Lang

>> On Jun 6, 2024, at 8:20 PM, Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
>>
>> Hi MIchael,
>>
>>
>>> On 7. Jun 2024, at 01:10, Michael Richardson via Starlink <starlink@lists.bufferbloat.net> wrote:
>>>
>>>
>>> Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
>>>> [SM] Yes, however Gaming is not in the enumerated list of use-cases the
>>>> regulator cares about (in the context of the minimal internet quality
>>>> end users are guaranteed).
>>>
>>> That's too bad, because online work/school are effectively a technology
>>> subset of gaming :-)
>>
>> [SM] I tend to agree that gamers can be seen as canaries in the coal mine regarding latency, but in this specific case my opion on what should or should not be taken into account is irrelevant, because the list of use-cases is explicitly mentioned in the text of the law...  First by referencing DIRECTIVE (EU) 2018/1972 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 December 2018 establishing the European Electronic Communications Code
>> https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018L1972#d1e32-196-1
>> ANNEX V
>> MINIMUM SET OF SERVICES WHICH THE ADEQUATE BROADBAND INTERNET ACCESS SERVICE IN ACCORDANCE WITH ARTICLE 84(3) SHALL BE CAPABLE OF SUPPORTING
>> (1) E-mail
>> (2) search engines enabling search and finding of all type of information(
>> 3) basic training and education online tools
>> (4) online newspapers or news
>> (5) buying or ordering goods or services online
>> (6) job searching and job searching tools
>> (7) professional networking
>> (8) internet banking
>> (9) eGovernment service use
>> (10) social media and instant messaging
>> (11) calls and video calls (standard quality)
>>
>> and then by adding
>> "Teleheimarbeit einschließlich Verschlüsselungsverfahren im üblichen Umfang und eine für Verbraucher marktübliche Nutzung von Online-Inhaltediensten ermöglichen."
>>
>> in the text iof the law, which roughly translates to:
>> home office/remote desktop including common encryption methods as well as a the capability to per-use on-line content services on a level appropriate for consumers.
>>
>> Note how gaming is not enumerated and at best could be read into the 'in-line content' clause... or maybe the "(5) buying or ordering goods or services online". I see an uphill battle arguing for loiw latency if all I can bring, is 'gamers desire/require' lower latencies... (not that this argument is wrong, but it ewill give me little leverage as gaming, for all the revenue it brings (bigger than Hollywood) is not held in high regard).
>>
>>> And gamers seem to know good quality, it's somewhat easy to test and gamers
>>> aren't afraid to demand it, changing ISPs if they have to.
>>
>> [SM] The context here is a right to getting internet access with specific minimum guarantees at an affordable price, people who will need to use this law likely have no real options... otherwise no need to pound on that law...

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-07 17:51           ` David Lang
@ 2024-06-07 20:09             ` Eugene Y Chang
  2024-06-08  1:53               ` David Lang
  0 siblings, 1 reply; 59+ messages in thread
From: Eugene Y Chang @ 2024-06-07 20:09 UTC (permalink / raw)
  To: David Lang; +Cc: Eugene Y Chang, Sebastian Moeller, Dave Taht via Starlink


[-- Attachment #1.1: Type: text/plain, Size: 4276 bytes --]



> On Jun 7, 2024, at 7:51 AM, David Lang <david@lang.hm> wrote:
> 
> On Fri, 7 Jun 2024, Eugene Y Chang via Starlink wrote:
> 
>> A lot of business processes use a web portal, e.g. SalesForce. Their productivity is highly sensitive to latency. The closes categorization that legislators/regulators might relate to is telemarketing. A lot of business solutions use the similar technology but not for telemarketing. Any ideas on a better name for this group of business solutions. Having a named use case that is sensitive to latency would help.
> 
> I would expect that any ISP tht does well for 5-10 would work for that use case. Does it really need a separate category listed?
> 

5-10? Units?

The existing list of use cases can be delivered with terrible latency.
I am asking if we need a use case where it is obvious that latency has an impact.

Our challenge is ordinary people don’t understand why they should care about latency. The need latency to become personal.

Gene

> David Lang
> 
>>> On Jun 6, 2024, at 8:20 PM, Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
>>> 
>>> Hi MIchael,
>>> 
>>> 
>>>> On 7. Jun 2024, at 01:10, Michael Richardson via Starlink <starlink@lists.bufferbloat.net> wrote:
>>>> 
>>>> 
>>>> Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
>>>>> [SM] Yes, however Gaming is not in the enumerated list of use-cases the
>>>>> regulator cares about (in the context of the minimal internet quality
>>>>> end users are guaranteed).
>>>> 
>>>> That's too bad, because online work/school are effectively a technology
>>>> subset of gaming :-)
>>> 
>>> [SM] I tend to agree that gamers can be seen as canaries in the coal mine regarding latency, but in this specific case my opion on what should or should not be taken into account is irrelevant, because the list of use-cases is explicitly mentioned in the text of the law...  First by referencing DIRECTIVE (EU) 2018/1972 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 December 2018 establishing the European Electronic Communications Code
>>> https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018L1972#d1e32-196-1
>>> ANNEX V
>>> MINIMUM SET OF SERVICES WHICH THE ADEQUATE BROADBAND INTERNET ACCESS SERVICE IN ACCORDANCE WITH ARTICLE 84(3) SHALL BE CAPABLE OF SUPPORTING
>>> (1) E-mail
>>> (2) search engines enabling search and finding of all type of information(
>>> 3) basic training and education online tools
>>> (4) online newspapers or news
>>> (5) buying or ordering goods or services online
>>> (6) job searching and job searching tools
>>> (7) professional networking
>>> (8) internet banking
>>> (9) eGovernment service use
>>> (10) social media and instant messaging
>>> (11) calls and video calls (standard quality)
>>> 
>>> and then by adding
>>> "Teleheimarbeit einschließlich Verschlüsselungsverfahren im üblichen Umfang und eine für Verbraucher marktübliche Nutzung von Online-Inhaltediensten ermöglichen."
>>> 
>>> in the text iof the law, which roughly translates to:
>>> home office/remote desktop including common encryption methods as well as a the capability to per-use on-line content services on a level appropriate for consumers.
>>> 
>>> Note how gaming is not enumerated and at best could be read into the 'in-line content' clause... or maybe the "(5) buying or ordering goods or services online". I see an uphill battle arguing for loiw latency if all I can bring, is 'gamers desire/require' lower latencies... (not that this argument is wrong, but it ewill give me little leverage as gaming, for all the revenue it brings (bigger than Hollywood) is not held in high regard).
>>> 
>>>> And gamers seem to know good quality, it's somewhat easy to test and gamers
>>>> aren't afraid to demand it, changing ISPs if they have to.
>>> 
>>> [SM] The context here is a right to getting internet access with specific minimum guarantees at an affordable price, people who will need to use this law likely have no real options... otherwise no need to pound on that law...
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


[-- Attachment #1.2: Type: text/html, Size: 9124 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-07 20:09             ` Eugene Y Chang
@ 2024-06-08  1:53               ` David Lang
  0 siblings, 0 replies; 59+ messages in thread
From: David Lang @ 2024-06-08  1:53 UTC (permalink / raw)
  To: Eugene Y Chang; +Cc: David Lang, Sebastian Moeller, Dave Taht via Starlink

[-- Attachment #1: Type: text/plain, Size: 4393 bytes --]

On Fri, 7 Jun 2024, Eugene Y Chang wrote:

>> On Jun 7, 2024, at 7:51 AM, David Lang <david@lang.hm> wrote:
>>
>> On Fri, 7 Jun 2024, Eugene Y Chang via Starlink wrote:
>>
>>> A lot of business processes use a web portal, e.g. SalesForce. Their productivity is highly sensitive to latency. The closes categorization that legislators/regulators might relate to is telemarketing. A lot of business solutions use the similar technology but not for telemarketing. Any ideas on a better name for this group of business solutions. Having a named use case that is sensitive to latency would help.
>>
>> I would expect that any ISP tht does well for 5-10 would work for that use case. Does it really need a separate category listed?
>>
>
> 5-10? Units?

items 5 through 10 on the list that;s currently written into the law (below)

David Lang

> The existing list of use cases can be delivered with terrible latency.
> I am asking if we need a use case where it is obvious that latency has an impact.
>
> Our challenge is ordinary people don’t understand why they should care about latency. The need latency to become personal.
>
> Gene
>
>> David Lang
>>
>>>> On Jun 6, 2024, at 8:20 PM, Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
>>>>
>>>> Hi MIchael,
>>>>
>>>>
>>>>> On 7. Jun 2024, at 01:10, Michael Richardson via Starlink <starlink@lists.bufferbloat.net> wrote:
>>>>>
>>>>>
>>>>> Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
>>>>>> [SM] Yes, however Gaming is not in the enumerated list of use-cases the
>>>>>> regulator cares about (in the context of the minimal internet quality
>>>>>> end users are guaranteed).
>>>>>
>>>>> That's too bad, because online work/school are effectively a technology
>>>>> subset of gaming :-)
>>>>
>>>> [SM] I tend to agree that gamers can be seen as canaries in the coal mine regarding latency, but in this specific case my opion on what should or should not be taken into account is irrelevant, because the list of use-cases is explicitly mentioned in the text of the law...  First by referencing DIRECTIVE (EU) 2018/1972 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 December 2018 establishing the European Electronic Communications Code
>>>> https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018L1972#d1e32-196-1
>>>> ANNEX V
>>>> MINIMUM SET OF SERVICES WHICH THE ADEQUATE BROADBAND INTERNET ACCESS SERVICE IN ACCORDANCE WITH ARTICLE 84(3) SHALL BE CAPABLE OF SUPPORTING
>>>> (1) E-mail
>>>> (2) search engines enabling search and finding of all type of information(
>>>> 3) basic training and education online tools
>>>> (4) online newspapers or news
>>>> (5) buying or ordering goods or services online
>>>> (6) job searching and job searching tools
>>>> (7) professional networking
>>>> (8) internet banking
>>>> (9) eGovernment service use
>>>> (10) social media and instant messaging
>>>> (11) calls and video calls (standard quality)
>>>>
>>>> and then by adding
>>>> "Teleheimarbeit einschließlich Verschlüsselungsverfahren im üblichen Umfang und eine für Verbraucher marktübliche Nutzung von Online-Inhaltediensten ermöglichen."
>>>>
>>>> in the text iof the law, which roughly translates to:
>>>> home office/remote desktop including common encryption methods as well as a the capability to per-use on-line content services on a level appropriate for consumers.
>>>>
>>>> Note how gaming is not enumerated and at best could be read into the 'in-line content' clause... or maybe the "(5) buying or ordering goods or services online". I see an uphill battle arguing for loiw latency if all I can bring, is 'gamers desire/require' lower latencies... (not that this argument is wrong, but it ewill give me little leverage as gaming, for all the revenue it brings (bigger than Hollywood) is not held in high regard).
>>>>
>>>>> And gamers seem to know good quality, it's somewhat easy to test and gamers
>>>>> aren't afraid to demand it, changing ISPs if they have to.
>>>>
>>>> [SM] The context here is a right to getting internet access with specific minimum guarantees at an affordable price, people who will need to use this law likely have no real options... otherwise no need to pound on that law...
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-07  5:36                                     ` Sebastian Moeller
@ 2024-06-07  7:51                                       ` Gert Doering
  0 siblings, 0 replies; 59+ messages in thread
From: Gert Doering @ 2024-06-07  7:51 UTC (permalink / raw)
  To: Sebastian Moeller
  Cc: Dave Taht, Dave Taht via Starlink, Stuart Cheshire, Colin_Higbie

Hi,

On Fri, Jun 07, 2024 at 07:36:36AM +0200, Sebastian Moeller via Starlink wrote:
> it might show that big iron silicon is just inferior to general purpose CPUs

Well, different criteria for "inferior", I'd say.  A general purpose
CPU won't be able to feed something with 24x 100Gbit - and a switch
network processor won't be good for running a database...

For queueing/shaping, the network chips have become surprisingly good -
not sure about libreqos & friends, but "doing proper shaping to sub-
linerate to avoid policing drops in a carrier network further downstream"
was something switches just couldn't do, and recent gear (Jericho 2+)
does this quite well.  With proper burst size configured, no bufferbloat
there either :)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Ingo Lalla,
                                           Karin Schuler, Sebastian Cler
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
@ 2024-06-07  7:36 David Fernández
  0 siblings, 0 replies; 59+ messages in thread
From: David Fernández @ 2024-06-07  7:36 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

ADSL is a technology that is disappearing, but I have just remembered that
some ISPs were allowing gamers to disable the interleaving, to reduce the
measured RTT, despite having more packet losses, then.

I remember getting that option years ago by Jazztel ISP in Spain (now
Orange). You could just go to the web interface of the ADSL router and
enable/disable the interleaving, depending on whether you want to play a
game online (or make a videoconference) or you are watching a movie or a
football match...

Date: Thu, 6 Jun 2024 18:39:54 -0700 (PDT)
From: David Lang <david@lang.hm>
To: Michael Richardson <mcr@sandelman.ca>
Cc: starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Message-ID: <600nn7nn-27os-r792-r2r5-6sp7565p2617@ynat.uz>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Michael Richardson wrote:

> And gamers seem to know good quality, it's somewhat easy to test and
gamers
> aren't afraid to demand it, changing ISPs if they have to.

If they have the option to you mean.

David Lang

[-- Attachment #2: Type: text/html, Size: 1581 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-07  2:28                                   ` Dave Taht
@ 2024-06-07  5:36                                     ` Sebastian Moeller
  2024-06-07  7:51                                       ` Gert Doering
  0 siblings, 1 reply; 59+ messages in thread
From: Sebastian Moeller @ 2024-06-07  5:36 UTC (permalink / raw)
  To: Dave Taht, Dave Taht via Starlink, Stuart Cheshire; +Cc: Starlink, Colin_Higbie

[-- Attachment #1: Type: text/plain, Size: 3047 bytes --]

This is pretty impressive... and also is a decent counter against the common argument that at BNG/backbone information rates flow queuing would be completely infeasible... or it might show that big iron silicon is just inferior to general purpose CPUs

On 7 June 2024 04:28:18 CEST, Dave Taht via Starlink <starlink@lists.bufferbloat.net> wrote:
>I occasionally am happy to point out the 150+ isps now running libreqos and
>cake... the several hundred running preseem and paraqum and bequant...
>
>As a rule of thumb about 10k wisp subscribers eat around 25gbit. This we
>(libreqos anyway) can do easily on a 1500 dollar whitebox (and we have
>pushed it past 60gbit in the v1.5 release entering beta shortly). This is
>usually way more capability than any given isp network segment needs...
>
>The wisps have got fq codel available native in much of their gear too, and
>of course starlink on their wifi...
>
>There are probably 60k isps left to go though. There are isps still on
>docsis 3.0.  I tend to regard these issues nowadays as being demand side as
>these solutions are so widely available now...
>
>But with billions being spent to just upgrade to fiber... a dark cloud
>ahead is above 50mbit most of the bloat moves to the wifi... and despite
>eero, openwrt, Google fiber etc that have been getting it right... sigh.
>
>A bright light at the moment there is all the wifi products coming out with
>a mt79 chip.
>
>On Thu, Jun 6, 2024, 10:51 AM Stuart Cheshire <cheshire@apple.com> wrote:
>
>> On Jun 4, 2024, at 16:03, Rich Brown <richb.hanover@gmail.com> wrote:
>>
>> > Yeah... I didn't write that as carefully as I could have. I was
>> switching between "user voice" (who'll say 'speed') and "expert" voice (I
>> know the difference). Check it now:
>> https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/
>>
>> Thanks for doing that.
>>
>> How about also changing “new faster ISP plan” to “new bigger ISP plan”? I
>> know that may sound like a slightly weird phrase, but getting people’s
>> attention by surprising them a little can be beneficial. If it looks weird
>> to them and that makes them pause and think, then that’s good.
>>
>> If the hypothetical ISP imagined here were actually willing to offer a
>> plan that truly provided consistently *faster* connectivity instead of just
>> more of the same, we’d be very happy. The truth today is that most IPs
>> offer *bigger*, not *better*. They are selling quantity, not quality.
>>
>> (I am intentionally not lumping *all* ISPs into the same bucket here.
>> Some, like Comcast, are actually making big efforts to improve quality as
>> well as quantity. Comcast dramatically reduced the working latency of my
>> cable modem during the work-from-home pandemic, and they continue to work
>> on improving that even more. I want to be sure to give credit where it is
>> deserved.)
>>
>> Stuart Cheshire
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 4023 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-06 17:51                                 ` Stuart Cheshire
@ 2024-06-07  2:28                                   ` Dave Taht
  2024-06-07  5:36                                     ` Sebastian Moeller
  0 siblings, 1 reply; 59+ messages in thread
From: Dave Taht @ 2024-06-07  2:28 UTC (permalink / raw)
  To: Stuart Cheshire; +Cc: Rich Brown, Starlink, Colin_Higbie

[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]

I occasionally am happy to point out the 150+ isps now running libreqos and
cake... the several hundred running preseem and paraqum and bequant...

As a rule of thumb about 10k wisp subscribers eat around 25gbit. This we
(libreqos anyway) can do easily on a 1500 dollar whitebox (and we have
pushed it past 60gbit in the v1.5 release entering beta shortly). This is
usually way more capability than any given isp network segment needs...

The wisps have got fq codel available native in much of their gear too, and
of course starlink on their wifi...

There are probably 60k isps left to go though. There are isps still on
docsis 3.0.  I tend to regard these issues nowadays as being demand side as
these solutions are so widely available now...

But with billions being spent to just upgrade to fiber... a dark cloud
ahead is above 50mbit most of the bloat moves to the wifi... and despite
eero, openwrt, Google fiber etc that have been getting it right... sigh.

A bright light at the moment there is all the wifi products coming out with
a mt79 chip.

On Thu, Jun 6, 2024, 10:51 AM Stuart Cheshire <cheshire@apple.com> wrote:

> On Jun 4, 2024, at 16:03, Rich Brown <richb.hanover@gmail.com> wrote:
>
> > Yeah... I didn't write that as carefully as I could have. I was
> switching between "user voice" (who'll say 'speed') and "expert" voice (I
> know the difference). Check it now:
> https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/
>
> Thanks for doing that.
>
> How about also changing “new faster ISP plan” to “new bigger ISP plan”? I
> know that may sound like a slightly weird phrase, but getting people’s
> attention by surprising them a little can be beneficial. If it looks weird
> to them and that makes them pause and think, then that’s good.
>
> If the hypothetical ISP imagined here were actually willing to offer a
> plan that truly provided consistently *faster* connectivity instead of just
> more of the same, we’d be very happy. The truth today is that most IPs
> offer *bigger*, not *better*. They are selling quantity, not quality.
>
> (I am intentionally not lumping *all* ISPs into the same bucket here.
> Some, like Comcast, are actually making big efforts to improve quality as
> well as quantity. Comcast dramatically reduced the working latency of my
> cable modem during the work-from-home pandemic, and they continue to work
> on improving that even more. I want to be sure to give credit where it is
> deserved.)
>
> Stuart Cheshire
>
>

[-- Attachment #2: Type: text/html, Size: 3295 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-04 23:03                               ` Rich Brown
@ 2024-06-06 17:51                                 ` Stuart Cheshire
  2024-06-07  2:28                                   ` Dave Taht
  0 siblings, 1 reply; 59+ messages in thread
From: Stuart Cheshire @ 2024-06-06 17:51 UTC (permalink / raw)
  To: Rich Brown, Dave Täht, Starlink, Colin_Higbie

On Jun 4, 2024, at 16:03, Rich Brown <richb.hanover@gmail.com> wrote:

> Yeah... I didn't write that as carefully as I could have. I was switching between "user voice" (who'll say 'speed') and "expert" voice (I know the difference). Check it now: https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/

Thanks for doing that.

How about also changing “new faster ISP plan” to “new bigger ISP plan”? I know that may sound like a slightly weird phrase, but getting people’s attention by surprising them a little can be beneficial. If it looks weird to them and that makes them pause and think, then that’s good.

If the hypothetical ISP imagined here were actually willing to offer a plan that truly provided consistently *faster* connectivity instead of just more of the same, we’d be very happy. The truth today is that most IPs offer *bigger*, not *better*. They are selling quantity, not quality.

(I am intentionally not lumping *all* ISPs into the same bucket here. Some, like Comcast, are actually making big efforts to improve quality as well as quantity. Comcast dramatically reduced the working latency of my cable modem during the work-from-home pandemic, and they continue to work on improving that even more. I want to be sure to give credit where it is deserved.)

Stuart Cheshire


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 14:57 ` Vint Cerf
@ 2024-06-06 17:12   ` Michael Richardson
  0 siblings, 0 replies; 59+ messages in thread
From: Michael Richardson @ 2024-06-06 17:12 UTC (permalink / raw)
  To: =?UTF-8?Q?David_Fern=C3=A1ndez?=, Vint Cerf; +Cc: starlink

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]


Vint Cerf via Starlink <starlink@lists.bufferbloat.net> wrote:
    > I hope you all realize that quantum entanglement does NOT facilitate
    > FTL communication.

I got a book last month for my birthday:
https://app.thestorygraph.com/books/99c04ecc-8cda-44ea-addf-1b19cd934ab8
Black Holes, by Brian Cox, Jeff Forshaw.  It's very good.

The style reminds me greatly of a book a read as a pre-teen:
   Dancing Wu Li Masters: An Overview of the New Physics, Gary Zukav
which eventually led me to a degree in physics.

I didn't know about Penrose Diagram's
https://en.wikipedia.org/wiki/Penrose_diagram
until this book.   The book explains quite clearly why entanglement can't be
used for communication.

At one point, when we were trying to mix DNSSEC and IPsec in FreeS/SWAN's
opportunistic encryption, we realized that DNS record (changes) propogate with a kind
of maximum speed, akin to a speed of TTL.  But, IPsec IKE connections are a
bit like workholes, and if they beat the DNS change across the Internet, then
things can fail.  Alas, my wormhole explanation fell flat.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-06 10:18 ` Alexandre Petrescu
@ 2024-06-06 10:37   ` Aidan Van Dyk
  0 siblings, 0 replies; 59+ messages in thread
From: Aidan Van Dyk @ 2024-06-06 10:37 UTC (permalink / raw)
  To: Alexandre Petrescu; +Cc: starlink

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Thu, Jun 6, 2024 at 6:18 AM Alexandre Petrescu via Starlink <
starlink@lists.bufferbloat.net> wrote:


> In a sense,  one would be happy to have all the communication standards
> frozen so all is settled and universal interoperability is ensured for
> years.   A little bit like bridges are there for hundreds of years,
> except some, of course.
>

I'm actually glad we aren't forcing our DOTs and cities to still build
bridges as they were 100 years ago, never mind how they were 200 (or 300)
years ago!  There are some old bridges still around, but they are
certainly performing the duty (carrying the load) of our modern bridges!

[-- Attachment #2: Type: text/html, Size: 966 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 14:46 David Fernández
  2024-06-05 14:57 ` Vint Cerf
  2024-06-06 10:18 ` Alexandre Petrescu
@ 2024-06-06 10:33 ` Alexandre Petrescu
  2 siblings, 0 replies; 59+ messages in thread
From: Alexandre Petrescu @ 2024-06-06 10:33 UTC (permalink / raw)
  To: starlink


Le 05/06/2024 à 16:46, David Fernández via Starlink a écrit :
> "quantum entanglement may be a path to beat the speed of light"
>
> It seems that is not going anywhere. Maybe better warp drives.
>
> Faster than light comms as a target for 7G mentioned here:
> https://imageio.forbes.com/specials-images/imageserve/653fee7b042dc92df0919930/MnM-Trends-Wheel/960x0.jpg?format=jpg&width=1440 
> <https://imageio.forbes.com/specials-images/imageserve/653fee7b042dc92df0919930/MnM-Trends-Wheel/960x0.jpg?format=jpg&width=1440>

That is a physics limitations - faster than light comms.

But it does not mean that because some people claim breaking physics 
barriers that the same effects can not be achieved differently.

It is possible to achieve ever lower latencies and higher bandwidths 
with talking about faster-than-light.

>
> https://www.forbes.com/sites/sarwantsingh/2023/10/30/the-mega-trends-that-will-shape-our-future-world

Thanks for the paper.

It claims that in year 2040 people use 6G, but I doubt so.  6G will be 
nearing to disappear (as 3G is today), 7G largely deployed and research 
happening on 8G and 9G.

6G will be deployed before year 2030 for all.

A G has a typical lifetime of less than 10 years, from research to 
deployment.  The initial Gs had a longer lifetime and recent Gs have a 
shorter lifetime.

Alex

>
> So, maybe that means that 6G will be the last G, after all, as faster 
> than light comms seem to be impossible, because paradoxes could be 
> created.
>
> The end of comms engineering could be in the horizon of our lifetime.
>
>
> Date: Wed, 5 Jun 2024 07:16:16 -0700 (PDT)
> From: David Lang <david@lang.hm>
> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> Cc: Gert Doering <gert@space.net>, starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <1r928s39-s5o3-q44n-804n-11ro432210s8@ynat.uz>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Alexandre Petrescu wrote:
>
> > Le 05/06/2024 à 15:40, Gert Doering a écrit :
> >> Hi,
> >>
> >> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via 
> Starlink
> > wrote:
> >>> well, ok.  One day the satcom latency will be so low that we will 
> not have
> >>> enough requirements for its use :-)
> >> Your disbelief in physics keeps amazing me :-)
> >
> > sorry :-)  Rather than simply 'satcom' I should have said
> > satcom-haps-planes-drones.  I dont have a name for that.
>
> you would be better off with plans that don't require beating the 
> speed of
> light. Yes, quantum entanglement may be a path to beat the speed of 
> light, but
> you still need the electronics to handle it, and have the speed of 
> sound at
> temperatures and pressures that humans can live at as a restriction.
>
> by comparison to your 1ms latency goals, extensive AT&T phone testing 
> decades
> ago showed that 100ms was the threshold where people could start to 
> detect a
> delay.
>
> David Lang
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 14:46 David Fernández
  2024-06-05 14:57 ` Vint Cerf
@ 2024-06-06 10:18 ` Alexandre Petrescu
  2024-06-06 10:37   ` Aidan Van Dyk
  2024-06-06 10:33 ` Alexandre Petrescu
  2 siblings, 1 reply; 59+ messages in thread
From: Alexandre Petrescu @ 2024-06-06 10:18 UTC (permalink / raw)
  To: starlink


Le 05/06/2024 à 16:46, David Fernández via Starlink a écrit :
> "quantum entanglement may be a path to beat the speed of light"
>
> It seems that is not going anywhere. Maybe better warp drives.
>
> Faster than light comms as a target for 7G mentioned here:
> https://imageio.forbes.com/specials-images/imageserve/653fee7b042dc92df0919930/MnM-Trends-Wheel/960x0.jpg?format=jpg&width=1440 
> <https://imageio.forbes.com/specials-images/imageserve/653fee7b042dc92df0919930/MnM-Trends-Wheel/960x0.jpg?format=jpg&width=1440>
>
> https://www.forbes.com/sites/sarwantsingh/2023/10/30/the-mega-trends-that-will-shape-our-future-world
>
> So, maybe that means that 6G will be the last G, after all, as faster 
> than light comms seem to be impossible, because paradoxes could be 
> created.

It can be an interesting discussion whether or not 6G, and 5G for that 
matter, is the last G, as we know these Gs.

Some take a prudent stance and talk about a _next_ G, as it might always 
be possible to plan about a next version.

The latency decrease in these Gs (mobile comm generations) will 
continue, forever chasing the Ethernet latencies, maybe in a nano-second 
class today.  At the current speed of latency decrease (500ms 2.5G, 
100ms 3G, 50ms 4G, 10ms 5G)  one can safely assume a 250micro-second 9G 
in year 2040 or so.

The decrease of latency in Gs is not a matter of physics limitations 
such as distance or energy.   The typical G latency happens mostly 
between a 'tower' and a smartphone on the 'air interface'.  The way the 
bits are stuffed in there is what makes that latency higher or lower.  
There can be very much additional simultaneity beyond what MIMO does, 
smarter error correction, interference avoidance and so on.   In theory, 
one might even reach an almost infinitely low (epsilon) latency, i.e. a 
latency that is that low that goes beyond the imediateness that we feel 
when sensing the nature.

The breaks in the G sequence  might arise from voluntary decrease in 
energy consumption to reduce climate change, human-generated but hard to 
understand catastrophic events, or personal inability to settle on 
standards because of beliefs or ideology.    But there is no physics 
limitation in the G increase.

>
> The end of comms engineering could be in the horizon of our lifetime.

In a sense,  one would be happy to have all the communication standards 
frozen so all is settled and universal interoperability is ensured for 
years.   A little bit like bridges are there for hundreds of years, 
except some, of course.

Alex

>
>
> Date: Wed, 5 Jun 2024 07:16:16 -0700 (PDT)
> From: David Lang <david@lang.hm>
> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> Cc: Gert Doering <gert@space.net>, starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <1r928s39-s5o3-q44n-804n-11ro432210s8@ynat.uz>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Alexandre Petrescu wrote:
>
> > Le 05/06/2024 à 15:40, Gert Doering a écrit :
> >> Hi,
> >>
> >> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via 
> Starlink
> > wrote:
> >>> well, ok.  One day the satcom latency will be so low that we will 
> not have
> >>> enough requirements for its use :-)
> >> Your disbelief in physics keeps amazing me :-)
> >
> > sorry :-)  Rather than simply 'satcom' I should have said
> > satcom-haps-planes-drones.  I dont have a name for that.
>
> you would be better off with plans that don't require beating the 
> speed of
> light. Yes, quantum entanglement may be a path to beat the speed of 
> light, but
> you still need the electronics to handle it, and have the speed of 
> sound at
> temperatures and pressures that humans can live at as a restriction.
>
> by comparison to your 1ms latency goals, extensive AT&T phone testing 
> decades
> ago showed that 100ms was the threshold where people could start to 
> detect a
> delay.
>
> David Lang
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 11:36                                   ` Alexandre Petrescu
  2024-06-05 13:08                                     ` Aidan Van Dyk
@ 2024-06-05 19:17                                     ` Eugene Y Chang
  1 sibling, 0 replies; 59+ messages in thread
From: Eugene Y Chang @ 2024-06-05 19:17 UTC (permalink / raw)
  To: Alexandre Petrescu; +Cc: Eugene Y Chang, Dave Taht via Starlink


[-- Attachment #1.1: Type: text/plain, Size: 9460 bytes --]

Alex,
Thanks for the reminder about telepresence and conversation (telephone) over a network. Even non-technical users can appreciate this. Has anyone tried to establish a quantitive measure for this as a benchmark? If we have this benchmark, we can relate our other measures (e.g., latency, buffering, etc.) to these “common sense” human measures.

While the measures and technical issues make sense to us (the networking engineers), they are too abstract to win support from non-technical users. We need to show how the technical issues manifest in human observable behavior.

I wish for a way for normal people to relate to issues that drive us.

Gene
----------------------------------------------
Eugene Chang
eugene.chang@ieee.org
o 781-799-0233




> On Jun 5, 2024, at 1:36 AM, Alexandre Petrescu via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> 
> Le 04/06/2024 à 22:58, Eugene Y Chang via Starlink a écrit :
>> For automobiles, the sensation of speed comes from engine noise and the G-force at the seat-of-your-pants.
>> 
>> I think of it as mostly the second derivative of the motion (aka acceleration).
>> 
>> For snappiness of a network action, it is the time interval from activation to completion. This perception can be enhanced by giving quick feedback (response) while many things are still in motion (still incomplete).
>> 
>> We do need to agree on what makes a network snappy and how that is measured.
> I think a part of qualifying a communications network as 'snappy' is to hold a 1-to-1 long-range audio conversation that acts as much as possible as an in-person conversation to a person nearby.  Landline phones still excel at that and should be the benchmark.
> 
> A 'tele-presence' over satcom linking several persons each speaking in high density bursts might need a 1ms RTT latency.
> 
> Alex
> 
>> 
>> 
>> 
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Jun 4, 2024, at 10:06 AM, Sauli Kiviranta via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>> 
>>> Good examples Stuart, it is quite interesting that as humanity we have not come up with aggregate term what would fairly collapse the dimensions to one single metric that would describe the snappy feeling we intuitively seek for but can not quite verbalize. Vehicles have the same issues, we have top speed (F1 at 360mph feels fast compared to Starship at 16000mph), we have acceleration (Hot-rod going 0 to 60 mph in 5 seconds feels high but pales in comparison to Tesla going 0 to 60 mph in 2 sec), we have horse powers (tractor plowing field with 300hp feels great but seems small compared to 1000hp of Hot-rod) then also there is torque (tractor with 1450 Nm of torque wins a Tesla having 900Nm on wheel while at completely different torque curve).
>>> 
>>> Capacity has the same issue as literally the truck from your example shipping magnetic tapes for "raw carry capacity" but it does not feel responsive, snappy, good to handle in the "traffic" of Internet. We have jitter, that could be compared to how a vehicle does in repeatability of track laps? We have packet loss on how the car handles on curves and does it slip off the track or on accelerations spin the wheels? Download is speed forward, upload is almost like speed at reverse gear usually far worse. Latency is like a lap track as such, depends on the track, use-case specific tests "What time did it do on Nürburgring?" or "How fast does it go from 0 to 60Mbps? Less than 200ms?". Horse power feels much like raw capacity of the HW / radio channel and techniques available beam forming, frequencies etc. what was discussed here related to Starlink and even collectively across different technologies. Speed is then instead of how much specific combination of modem and base-station combo can achieve at certain configuration? Torque feels like ability to maintain that performance, closest we get is loaded performance in context of bufferbloat?
>>> 
>>> Watching videos on Netflix require different performance characteristics than downloading a big update to Fortnite. One has certain acceleration need to have snappy user experience but focus is more on connection stability at certain bitrate. On the other hand Fortnite update you want to be delivered at brute force speeds without ruining others user experience.
>>> 
>>> Maybe we can not find that aggregate property or metric, but just need to be rigorous on making sure we accurately characterize each dimension and standardize them so the confusion and play with words, specially with marketing, get stabilized. Each needs to have standardized benchmarks much like 3D rendering benchmarks and PC perf tests are done? All that said, as I failed to come up with a perfect term, "varying performance ISP links" feels like the right thing to say? Now we have obfuscated to be able to throw any of the dimensions underneath. Only thing left for us to do is then to provide those dimensions like a nutrient labels. We are getting there? Nothing new under the sun also to some extend.
>>> 
>>> Just as a funny side note on the tractor marketing:
>>> 
>>> ”Torque gives you the feeling of responsiveness and that the machine does the right things,” Tapani Katila encapsulates his view. “The torque is directly linked to the feeling of having power available in the entire range of the power curve, resulting in more meaningful work.” from https://www.agcopower.com/power-is-important-but-torque-is-crucial/ <https://www.agcopower.com/power-is-important-but-torque-is-crucial/>
>>> 
>>> Seems like some other people are also trying to figure out what dimensions to showcase to customers?
>>> 
>>> Thank you for the thought provoking examples!
>>> 
>>> Is bufferbloat property of a vehicle or characteristic of the road design? Is it a question of ICE vs EV -or- roundabout vs crossing with traffic lights? Feels more like a roundabout, no? Is this the problem behind the objections?
>>> 
>>> - Sauli
>>> 
>>> On Tue, Jun 4, 2024 at 9:19 PM Stuart Cheshire via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>> On May 7, 2024, at 18:48, Dave Taht via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>> 
>>> > This was a wonderful post, rich!
>>> 
>>> <https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/ <https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/>>
>>> 
>>> I agree. Thanks for writing this Rich.
>>> 
>>> One minor change I will request. Any time you write words like “speed” or “fast”, pause and consider whether it would be more accurate to use some other term like “capacity”, “bandwidth”, or “throughput”. Part of what keeps us in this mess is that people equate network capacity with “speed”, as if those terms were synonyms. We can’t change how people think overnight, but at least we can avoid further reinforcing that wrong thinking.
>>> 
>>> If someone has 200 Mb/s Internet service and it feels slow, then they might upgrade to 400 Mb/s Internet service and expect everything to be uniformly twice as fast. We here know that doubling the network capacity may make large downloads faster, but everything else is most likely unchanged, and can be even worse.
>>> 
>>> People never make this mistake in other contexts. If someone commutes to work in their 20-foot RV feels that it’s too slow, then upgrading to a 40-foot RV will not get them to work faster. A 40-foot RV is *bigger* than a 20-foot RV, but it’s probably not *faster*. If you are moving a vast amount of cargo that requires multiple trips, then a larger truck will let you complete that task in fewer trips. But for most daily driving, a bigger truck will not get to your destination any quicker.
>>> 
>>> Some simple edits:
>>> 
>>> Instead of “varying speed ISP links” how about “varying capacity ISP links”?
>>> 
>>> Instead of “they profit if you decide your network is too slow and you upgrade to a faster device/plan” how about “they profit if you decide your network is too slow and you upgrade to a higher throughput device/plan”?
>>> 
>>> Stuart Cheshire
>>> 
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> 
>> 
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>

[-- Attachment #1.2: Type: text/html, Size: 26396 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 13:40                                         ` Gert Doering
  2024-06-05 13:43                                           ` Alexandre Petrescu
@ 2024-06-05 16:21                                           ` Alexandre Petrescu
  1 sibling, 0 replies; 59+ messages in thread
From: Alexandre Petrescu @ 2024-06-05 16:21 UTC (permalink / raw)
  To: Gert Doering; +Cc: Aidan Van Dyk, starlink

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

Sorry, I wanted to say something else about 'disbelief in physics'.

Of course I do hold in high esteem physics in particular, and science in 
general.

I might not know all the physics of doppler effects and EM propagation; 
I might be wrong about expecting 1ms latencies from satcom.  But I am 
sure that where one is wrong today another one might be right tomorrow. 
Imagine for example the entire Internet stored in just one drone above 
the person's head, at 100m.  A big cache so to speak.  The latency that 
person will see might be even below 1ms.  Such examples, 
counter-examples and exceptions like this can be easily imagined.

About skepticism related to physics in particular, I can not abstain 
telling that, as with all observation-experiment-equation crafts 
(physics is just one, but there are others), the next big E=mc2 equation 
might very well be generated by AI, rather than by a human.  What makes 
me think so?  There is a paper published in Nature recently, whose first 
author is a relative of Mr. Bohr (Niels) (if I am not wrong about names; 
the point about a name being famous is not important here).   The first 
introductory paragraph is generated by AI, as reported by the gptzero 
tool.  I think that from there, there are only a few small steps to have 
the 'meat' of an article also generated by AI, i.e. some equation that 
our children, not grand children, will learn as being fundamental. E=mc2 
is just one example; it is very remote and very theoretical, but there 
are many other equation examples that are touching us in a more direct 
and immediate way.  Observing the nature and making equations out of it 
so that to forecast the future is very easy for AI.

That might be a point about disbelief in physics.  But I am not 
distrusting the existing physics corpus, that I might just simply not 
know it :-)

Alex

Le 05/06/2024 à 15:40, Gert Doering a écrit :
> Hi,
>
> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via Starlink wrote:
>> well, ok.  One day the satcom latency will be so low that we will not have
>> enough requirements for its use :-)
> Your disbelief in physics keeps amazing me :-)
>
> Gert Doering
>          -- NetMaster

[-- Attachment #2: Type: text/html, Size: 3218 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 14:16                                             ` David Lang
@ 2024-06-05 15:10                                               ` Sebastian Moeller
  0 siblings, 0 replies; 59+ messages in thread
From: Sebastian Moeller @ 2024-06-05 15:10 UTC (permalink / raw)
  To: David Lang; +Cc: Alexandre Petrescu, Dave Taht via Starlink

Hi David,


> On 5. Jun 2024, at 16:16, David Lang via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Alexandre Petrescu wrote:
> 
>> Le 05/06/2024 à 15:40, Gert Doering a écrit :
>>> Hi,
>>> 
>>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via Starlink
>> wrote:
>>>> well, ok.  One day the satcom latency will be so low that we will not have
>>>> enough requirements for its use :-)
>>> Your disbelief in physics keeps amazing me :-)
>> 
>> sorry :-)  Rather than simply 'satcom' I should have said satcom-haps-planes-drones.  I dont have a name for that.
> 
> you would be better off with plans that don't require beating the speed of light. Yes, quantum entanglement may be a path to beat the speed of light, but you still need the electronics to handle it, and have the speed of sound at temperatures and pressures that humans can live at as a restriction.
> 
> by comparison to your 1ms latency goals, extensive AT&T phone testing decades ago showed that 100ms was the threshold where people could start to detect a delay.

Would you have any pointer for that study/those studies? Our local regulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable and I am trying to find studies that can shed a light on what acceptable delay is for different kind of interactive tasks. (Spoiler alert, I am not convinced that 300ms RTT is a great idea, I forced my self to remote desktop with artificial 300ms delay and it was not fun, but not totaly unusable either, but then human can adapt and steer high inertia vehicles like loaded container ships...)

Sorry for the tangent...

Regards
	Sebastian

P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343 m/millisecond that is even at a distance of 1 meter delay will be at a 3 ms... and when talking to folks 10m away it is not the delay that is annoying, but the fact that you have to raise your voice considerably...

> 
> David Lang_______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 14:46 David Fernández
@ 2024-06-05 14:57 ` Vint Cerf
  2024-06-06 17:12   ` Michael Richardson
  2024-06-06 10:18 ` Alexandre Petrescu
  2024-06-06 10:33 ` Alexandre Petrescu
  2 siblings, 1 reply; 59+ messages in thread
From: Vint Cerf @ 2024-06-05 14:57 UTC (permalink / raw)
  To: David Fernández; +Cc: starlink


[-- Attachment #1.1: Type: text/plain, Size: 2671 bytes --]

I hope you all realize that quantum entanglement does NOT facilitate  FTL
communication.

v


On Wed, Jun 5, 2024 at 10:46 AM David Fernández via Starlink <
starlink@lists.bufferbloat.net> wrote:

> "quantum entanglement may be a path to beat the speed of light"
>
> It seems that is not going anywhere. Maybe better warp drives.
>
> Faster than light comms as a target for 7G mentioned here:
>
> https://imageio.forbes.com/specials-images/imageserve/653fee7b042dc92df0919930/MnM-Trends-Wheel/960x0.jpg?format=jpg&width=1440
>
>
> https://www.forbes.com/sites/sarwantsingh/2023/10/30/the-mega-trends-that-will-shape-our-future-world
>
> So, maybe that means that 6G will be the last G, after all, as faster than
> light comms seem to be impossible, because paradoxes could be created.
>
> The end of comms engineering could be in the horizon of our lifetime.
>
>
> Date: Wed, 5 Jun 2024 07:16:16 -0700 (PDT)
> From: David Lang <david@lang.hm>
> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> Cc: Gert Doering <gert@space.net>, starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <1r928s39-s5o3-q44n-804n-11ro432210s8@ynat.uz>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Alexandre Petrescu wrote:
>
> > Le 05/06/2024 à 15:40, Gert Doering a écrit :
> >> Hi,
> >>
> >> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via
> Starlink
> > wrote:
> >>> well, ok.  One day the satcom latency will be so low that we will not
> have
> >>> enough requirements for its use :-)
> >> Your disbelief in physics keeps amazing me :-)
> >
> > sorry :-)  Rather than simply 'satcom' I should have said
> > satcom-haps-planes-drones.  I dont have a name for that.
>
> you would be better off with plans that don't require beating the speed of
> light. Yes, quantum entanglement may be a path to beat the speed of light,
> but
> you still need the electronics to handle it, and have the speed of sound
> at
> temperatures and pressures that humans can live at as a restriction.
>
> by comparison to your 1ms latency goals, extensive AT&T phone testing
> decades
> ago showed that 100ms was the threshold where people could start to detect
> a
> delay.
>
> David Lang
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice

[-- Attachment #1.2: Type: text/html, Size: 4465 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4006 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
@ 2024-06-05 14:46 David Fernández
  2024-06-05 14:57 ` Vint Cerf
                   ` (2 more replies)
  0 siblings, 3 replies; 59+ messages in thread
From: David Fernández @ 2024-06-05 14:46 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

"quantum entanglement may be a path to beat the speed of light"

It seems that is not going anywhere. Maybe better warp drives.

Faster than light comms as a target for 7G mentioned here:
https://imageio.forbes.com/specials-images/imageserve/653fee7b042dc92df0919930/MnM-Trends-Wheel/960x0.jpg?format=jpg&width=1440

https://www.forbes.com/sites/sarwantsingh/2023/10/30/the-mega-trends-that-will-shape-our-future-world

So, maybe that means that 6G will be the last G, after all, as faster than
light comms seem to be impossible, because paradoxes could be created.

The end of comms engineering could be in the horizon of our lifetime.


Date: Wed, 5 Jun 2024 07:16:16 -0700 (PDT)
From: David Lang <david@lang.hm>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Gert Doering <gert@space.net>, starlink@lists.bufferbloat.net
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Message-ID: <1r928s39-s5o3-q44n-804n-11ro432210s8@ynat.uz>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Alexandre Petrescu wrote:

> Le 05/06/2024 à 15:40, Gert Doering a écrit :
>> Hi,
>>
>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via
Starlink
> wrote:
>>> well, ok.  One day the satcom latency will be so low that we will not
have
>>> enough requirements for its use :-)
>> Your disbelief in physics keeps amazing me :-)
>
> sorry :-)  Rather than simply 'satcom' I should have said
> satcom-haps-planes-drones.  I dont have a name for that.

you would be better off with plans that don't require beating the speed of
light. Yes, quantum entanglement may be a path to beat the speed of light,
but
you still need the electronics to handle it, and have the speed of sound at
temperatures and pressures that humans can live at as a restriction.

by comparison to your 1ms latency goals, extensive AT&T phone testing
decades
ago showed that 100ms was the threshold where people could start to detect
a
delay.

David Lang

[-- Attachment #2: Type: text/html, Size: 3075 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 13:43                                           ` Alexandre Petrescu
@ 2024-06-05 14:16                                             ` David Lang
  2024-06-05 15:10                                               ` Sebastian Moeller
  0 siblings, 1 reply; 59+ messages in thread
From: David Lang @ 2024-06-05 14:16 UTC (permalink / raw)
  To: Alexandre Petrescu; +Cc: Gert Doering, starlink

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

Alexandre Petrescu wrote:

> Le 05/06/2024 à 15:40, Gert Doering a écrit :
>> Hi,
>>
>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via Starlink 
> wrote:
>>> well, ok.  One day the satcom latency will be so low that we will not have
>>> enough requirements for its use :-)
>> Your disbelief in physics keeps amazing me :-)
>
> sorry :-)  Rather than simply 'satcom' I should have said 
> satcom-haps-planes-drones.  I dont have a name for that.

you would be better off with plans that don't require beating the speed of 
light. Yes, quantum entanglement may be a path to beat the speed of light, but 
you still need the electronics to handle it, and have the speed of sound at 
temperatures and pressures that humans can live at as a restriction.

by comparison to your 1ms latency goals, extensive AT&T phone testing decades 
ago showed that 100ms was the threshold where people could start to detect a 
delay.

David Lang

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 13:40                                         ` Gert Doering
@ 2024-06-05 13:43                                           ` Alexandre Petrescu
  2024-06-05 14:16                                             ` David Lang
  2024-06-05 16:21                                           ` Alexandre Petrescu
  1 sibling, 1 reply; 59+ messages in thread
From: Alexandre Petrescu @ 2024-06-05 13:43 UTC (permalink / raw)
  To: Gert Doering; +Cc: Aidan Van Dyk, starlink


Le 05/06/2024 à 15:40, Gert Doering a écrit :
> Hi,
>
> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via Starlink wrote:
>> well, ok.  One day the satcom latency will be so low that we will not have
>> enough requirements for its use :-)
> Your disbelief in physics keeps amazing me :-)

sorry :-)  Rather than simply 'satcom' I should have said 
satcom-haps-planes-drones.  I dont have a name for that.

Alex

>
> Gert Doering
>          -- NetMaster

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 13:28                                       ` Alexandre Petrescu
@ 2024-06-05 13:40                                         ` Gert Doering
  2024-06-05 13:43                                           ` Alexandre Petrescu
  2024-06-05 16:21                                           ` Alexandre Petrescu
  0 siblings, 2 replies; 59+ messages in thread
From: Gert Doering @ 2024-06-05 13:40 UTC (permalink / raw)
  To: Alexandre Petrescu; +Cc: Aidan Van Dyk, starlink

Hi,

On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via Starlink wrote:
> well, ok.  One day the satcom latency will be so low that we will not have
> enough requirements for its use :-)

Your disbelief in physics keeps amazing me :-)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Ingo Lalla,
                                           Karin Schuler, Sebastian Cler
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 13:08                                     ` Aidan Van Dyk
@ 2024-06-05 13:28                                       ` Alexandre Petrescu
  2024-06-05 13:40                                         ` Gert Doering
  0 siblings, 1 reply; 59+ messages in thread
From: Alexandre Petrescu @ 2024-06-05 13:28 UTC (permalink / raw)
  To: Aidan Van Dyk; +Cc: starlink

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]


Le 05/06/2024 à 15:08, Aidan Van Dyk a écrit :
> On Wed, Jun 5, 2024 at 7:36 AM Alexandre Petrescu via Starlink 
> <starlink@lists.bufferbloat.net> wrote:
>
>     A 'tele-presence' over satcom linking several persons each
>     speaking in high density bursts might need a 1ms RTT latency.
>
>
> I've never been in a discussion with several people where we all 
> needed to be within 6 inches of each other's mouths/ears...

:-) :-)

well, ok.  One day the satcom latency will be so low that we will not 
have enough requirements for its use :-)

Alex

>
> a.

[-- Attachment #2: Type: text/html, Size: 1895 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-05 11:36                                   ` Alexandre Petrescu
@ 2024-06-05 13:08                                     ` Aidan Van Dyk
  2024-06-05 13:28                                       ` Alexandre Petrescu
  2024-06-05 19:17                                     ` Eugene Y Chang
  1 sibling, 1 reply; 59+ messages in thread
From: Aidan Van Dyk @ 2024-06-05 13:08 UTC (permalink / raw)
  To: Alexandre Petrescu; +Cc: starlink

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Wed, Jun 5, 2024 at 7:36 AM Alexandre Petrescu via Starlink <
starlink@lists.bufferbloat.net> wrote:

> A 'tele-presence' over satcom linking several persons each speaking in
> high density bursts might need a 1ms RTT latency.
>

I've never been in a discussion with several people where we all needed to
be within 6 inches of each other's mouths/ears...

a.

[-- Attachment #2: Type: text/html, Size: 751 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-04 20:58                                 ` Eugene Y Chang
@ 2024-06-05 11:36                                   ` Alexandre Petrescu
  2024-06-05 13:08                                     ` Aidan Van Dyk
  2024-06-05 19:17                                     ` Eugene Y Chang
  0 siblings, 2 replies; 59+ messages in thread
From: Alexandre Petrescu @ 2024-06-05 11:36 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 7988 bytes --]


Le 04/06/2024 à 22:58, Eugene Y Chang via Starlink a écrit :
> For automobiles, the sensation of speed comes from engine noise and 
> the G-force at the seat-of-your-pants.
>
> I think of it as mostly the second derivative of the motion (aka 
> acceleration).
>
> For snappiness of a network action, it is the time interval from 
> activation to completion. This perception can be enhanced by giving 
> quick feedback (response) while many things are still in motion (still 
> incomplete).
>
> We do need to agree on what makes a network snappy and how that is 
> measured.

I think a part of qualifying a communications network as 'snappy' is to 
hold a 1-to-1 long-range audio conversation that acts as much as 
possible as an in-person conversation to a person nearby. Landline 
phones still excel at that and should be the benchmark.

A 'tele-presence' over satcom linking several persons each speaking in 
high density bursts might need a 1ms RTT latency.

Alex

>
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
> eugene.chang@ieee.org
>
>
>
>
>
>
>> On Jun 4, 2024, at 10:06 AM, Sauli Kiviranta via Starlink 
>> <starlink@lists.bufferbloat.net> wrote:
>>
>> Good examples Stuart, it is quite interesting that as humanity we 
>> have not come up with aggregate term what would fairly collapse the 
>> dimensions to one single metric that would describe the snappy 
>> feeling we intuitively seek for but can not quite verbalize. Vehicles 
>> have the same issues, we have top speed (F1 at 360mph feels fast 
>> compared to Starship at 16000mph), we have acceleration (Hot-rod 
>> going 0 to 60 mph in 5 seconds feels high but pales in comparison to 
>> Tesla going 0 to 60 mph in 2 sec), we have horse powers (tractor 
>> plowing field with 300hp feels great but seems small compared to 
>> 1000hp of Hot-rod) then also there is torque (tractor with 1450 Nm of 
>> torque wins a Tesla having 900Nm on wheel while at completely 
>> different torque curve).
>>
>> Capacity has the same issue as literally the truck from your example 
>> shipping magnetic tapes for "raw carry capacity" but it does not feel 
>> responsive, snappy, good to handle in the "traffic" of Internet. We 
>> have jitter, that could be compared to how a vehicle does in 
>> repeatability of track laps? We have packet loss on how the car 
>> handles on curves and does it slip off the track or on accelerations 
>> spin the wheels? Download is speed forward, upload is almost like 
>> speed at reverse gear usually far worse. Latency is like a lap track 
>> as such, depends on the track, use-case specific tests "What time did 
>> it do on Nürburgring?" or "How fast does it go from 0 to 60Mbps? Less 
>> than 200ms?". Horse power feels much like raw capacity of the HW / 
>> radio channel and techniques available beam forming, frequencies etc. 
>> what was discussed here related to Starlink and even collectively 
>> across different technologies. Speed is then instead of how much 
>> specific combination of modem and base-station combo can achieve at 
>> certain configuration? Torque feels like ability to maintain that 
>> performance, closest we get is loaded performance in context of 
>> bufferbloat?
>>
>> Watching videos on Netflix require different performance 
>> characteristics than downloading a big update to Fortnite. One has 
>> certain acceleration need to have snappy user experience but focus is 
>> more on connection stability at certain bitrate. On the other hand 
>> Fortnite update you want to be delivered at brute force speeds 
>> without ruining others user experience.
>>
>> Maybe we can not find that aggregate property or metric, but just 
>> need to be rigorous on making sure we accurately characterize each 
>> dimension and standardize them so the confusion and play with words, 
>> specially with marketing, get stabilized. Each needs to have 
>> standardized benchmarks much like 3D rendering benchmarks and PC perf 
>> tests are done? All that said, as I failed to come up with a perfect 
>> term, "varying performance ISP links" feels like the right thing to 
>> say? Now we have obfuscated to be able to throw any of the dimensions 
>> underneath. Only thing left for us to do is then to provide those 
>> dimensions like a nutrient labels. We are getting there? Nothing new 
>> under the sun also to some extend.
>>
>> Just as a funny side note on the tractor marketing:
>>
>> ”Torque gives you the feeling of responsiveness and that the machine 
>> does the right things,” Tapani Katila encapsulates his view. “The 
>> torque is directly linked to the feeling of having power available in 
>> the entire range of the power curve, resulting in more meaningful 
>> work.” from 
>> https://www.agcopower.com/power-is-important-but-torque-is-crucial/
>>
>> Seems like some other people are also trying to figure out what 
>> dimensions to showcase to customers?
>>
>> Thank you for the thought provoking examples!
>>
>> Is bufferbloat property of a vehicle or characteristic of the road 
>> design? Is it a question of ICE vs EV -or- roundabout vs crossing 
>> with traffic lights? Feels more like a roundabout, no? Is this the 
>> problem behind the objections?
>>
>> - Sauli
>>
>> On Tue, Jun 4, 2024 at 9:19 PM Stuart Cheshire via Starlink 
>> <starlink@lists.bufferbloat.net> wrote:
>>
>>     On May 7, 2024, at 18:48, Dave Taht via Starlink
>>     <starlink@lists.bufferbloat.net> wrote:
>>
>>     > This was a wonderful post, rich!
>>
>>     <https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/>
>>
>>     I agree. Thanks for writing this Rich.
>>
>>     One minor change I will request. Any time you write words like
>>     “speed” or “fast”, pause and consider whether it would be more
>>     accurate to use some other term like “capacity”, “bandwidth”, or
>>     “throughput”. Part of what keeps us in this mess is that people
>>     equate network capacity with “speed”, as if those terms were
>>     synonyms. We can’t change how people think overnight, but at
>>     least we can avoid further reinforcing that wrong thinking.
>>
>>     If someone has 200 Mb/s Internet service and it feels slow, then
>>     they might upgrade to 400 Mb/s Internet service and expect
>>     everything to be uniformly twice as fast. We here know that
>>     doubling the network capacity may make large downloads faster,
>>     but everything else is most likely unchanged, and can be even worse.
>>
>>     People never make this mistake in other contexts. If someone
>>     commutes to work in their 20-foot RV feels that it’s too slow,
>>     then upgrading to a 40-foot RV will not get them to work faster.
>>     A 40-foot RV is *bigger* than a 20-foot RV, but it’s probably not
>>     *faster*. If you are moving a vast amount of cargo that requires
>>     multiple trips, then a larger truck will let you complete that
>>     task in fewer trips. But for most daily driving, a bigger truck
>>     will not get to your destination any quicker.
>>
>>     Some simple edits:
>>
>>     Instead of “varying speed ISP links” how about “varying capacity
>>     ISP links”?
>>
>>     Instead of “they profit if you decide your network is too slow
>>     and you upgrade to a faster device/plan” how about “they profit
>>     if you decide your network is too slow and you upgrade to a
>>     higher throughput device/plan”?
>>
>>     Stuart Cheshire
>>
>>     _______________________________________________
>>     Starlink mailing list
>>     Starlink@lists.bufferbloat.net
>>     https://lists.bufferbloat.net/listinfo/starlink
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 18689 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-04 18:19                             ` Stuart Cheshire
  2024-06-04 20:06                               ` Sauli Kiviranta
@ 2024-06-04 23:03                               ` Rich Brown
  2024-06-06 17:51                                 ` Stuart Cheshire
  1 sibling, 1 reply; 59+ messages in thread
From: Rich Brown @ 2024-06-04 23:03 UTC (permalink / raw)
  To: Stuart Cheshire; +Cc: Dave Täht, Dave Taht via Starlink, Colin_Higbie

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

Stewart Cheshire wrote:

One minor change I will request. Any time you write words like “speed” or
> “fast”, pause and consider...


Yeah... I didn't write that as carefully as I could have. I was switching
between "user voice" (who'll say 'speed') and "expert" voice (I know the
difference). Check it now:
https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/

Thanks.

Rich

[-- Attachment #2: Type: text/html, Size: 916 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-04 20:06                               ` Sauli Kiviranta
@ 2024-06-04 20:58                                 ` Eugene Y Chang
  2024-06-05 11:36                                   ` Alexandre Petrescu
  0 siblings, 1 reply; 59+ messages in thread
From: Eugene Y Chang @ 2024-06-04 20:58 UTC (permalink / raw)
  To: Sauli Kiviranta
  Cc: Eugene Y Chang, Stuart Cheshire, Dave Taht via Starlink, Colin_Higbie


[-- Attachment #1.1: Type: text/plain, Size: 7253 bytes --]

For automobiles, the sensation of speed comes from engine noise and the G-force at the seat-of-your-pants.

I think of it as mostly the second derivative of the motion (aka acceleration).

For snappiness of a network action, it is the time interval from activation to completion. This perception can be enhanced by giving quick feedback (response) while many things are still in motion (still incomplete).

We do need to agree on what makes a network snappy and how that is measured.



Gene
----------------------------------------------
Eugene Chang
eugene.chang@ieee.org






> On Jun 4, 2024, at 10:06 AM, Sauli Kiviranta via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Good examples Stuart, it is quite interesting that as humanity we have not come up with aggregate term what would fairly collapse the dimensions to one single metric that would describe the snappy feeling we intuitively seek for but can not quite verbalize. Vehicles have the same issues, we have top speed (F1 at 360mph feels fast compared to Starship at 16000mph), we have acceleration (Hot-rod going 0 to 60 mph in 5 seconds feels high but pales in comparison to Tesla going 0 to 60 mph in 2 sec), we have horse powers (tractor plowing field with 300hp feels great but seems small compared to 1000hp of Hot-rod) then also there is torque (tractor with 1450 Nm of torque wins a Tesla having 900Nm on wheel while at completely different torque curve).
> 
> Capacity has the same issue as literally the truck from your example shipping magnetic tapes for "raw carry capacity" but it does not feel responsive, snappy, good to handle in the "traffic" of Internet. We have jitter, that could be compared to how a vehicle does in repeatability of track laps? We have packet loss on how the car handles on curves and does it slip off the track or on accelerations spin the wheels? Download is speed forward, upload is almost like speed at reverse gear usually far worse. Latency is like a lap track as such, depends on the track, use-case specific tests "What time did it do on Nürburgring?" or "How fast does it go from 0 to 60Mbps? Less than 200ms?". Horse power feels much like raw capacity of the HW / radio channel and techniques available beam forming, frequencies etc. what was discussed here related to Starlink and even collectively across different technologies. Speed is then instead of how much specific combination of modem and base-station combo can achieve at certain configuration? Torque feels like ability to maintain that performance, closest we get is loaded performance in context of bufferbloat?
> 
> Watching videos on Netflix require different performance characteristics than downloading a big update to Fortnite. One has certain acceleration need to have snappy user experience but focus is more on connection stability at certain bitrate. On the other hand Fortnite update you want to be delivered at brute force speeds without ruining others user experience.
> 
> Maybe we can not find that aggregate property or metric, but just need to be rigorous on making sure we accurately characterize each dimension and standardize them so the confusion and play with words, specially with marketing, get stabilized. Each needs to have standardized benchmarks much like 3D rendering benchmarks and PC perf tests are done? All that said, as I failed to come up with a perfect term, "varying performance ISP links" feels like the right thing to say? Now we have obfuscated to be able to throw any of the dimensions underneath. Only thing left for us to do is then to provide those dimensions like a nutrient labels. We are getting there? Nothing new under the sun also to some extend.
> 
> Just as a funny side note on the tractor marketing:
> 
> ”Torque gives you the feeling of responsiveness and that the machine does the right things,” Tapani Katila encapsulates his view. “The torque is directly linked to the feeling of having power available in the entire range of the power curve, resulting in more meaningful work.” from https://www.agcopower.com/power-is-important-but-torque-is-crucial/ <https://www.agcopower.com/power-is-important-but-torque-is-crucial/>
> 
> Seems like some other people are also trying to figure out what dimensions to showcase to customers?
> 
> Thank you for the thought provoking examples!
> 
> Is bufferbloat property of a vehicle or characteristic of the road design? Is it a question of ICE vs EV -or- roundabout vs crossing with traffic lights? Feels more like a roundabout, no? Is this the problem behind the objections?
> 
> - Sauli
> 
> On Tue, Jun 4, 2024 at 9:19 PM Stuart Cheshire via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
> On May 7, 2024, at 18:48, Dave Taht via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
> 
> > This was a wonderful post, rich!
> 
> <https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/ <https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/>>
> 
> I agree. Thanks for writing this Rich.
> 
> One minor change I will request. Any time you write words like “speed” or “fast”, pause and consider whether it would be more accurate to use some other term like “capacity”, “bandwidth”, or “throughput”. Part of what keeps us in this mess is that people equate network capacity with “speed”, as if those terms were synonyms. We can’t change how people think overnight, but at least we can avoid further reinforcing that wrong thinking.
> 
> If someone has 200 Mb/s Internet service and it feels slow, then they might upgrade to 400 Mb/s Internet service and expect everything to be uniformly twice as fast. We here know that doubling the network capacity may make large downloads faster, but everything else is most likely unchanged, and can be even worse.
> 
> People never make this mistake in other contexts. If someone commutes to work in their 20-foot RV feels that it’s too slow, then upgrading to a 40-foot RV will not get them to work faster. A 40-foot RV is *bigger* than a 20-foot RV, but it’s probably not *faster*. If you are moving a vast amount of cargo that requires multiple trips, then a larger truck will let you complete that task in fewer trips. But for most daily driving, a bigger truck will not get to your destination any quicker.
> 
> Some simple edits:
> 
> Instead of “varying speed ISP links” how about “varying capacity ISP links”?
> 
> Instead of “they profit if you decide your network is too slow and you upgrade to a faster device/plan” how about “they profit if you decide your network is too slow and you upgrade to a higher throughput device/plan”?
> 
> Stuart Cheshire
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


[-- Attachment #1.2: Type: text/html, Size: 12649 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-06-04 18:19                             ` Stuart Cheshire
@ 2024-06-04 20:06                               ` Sauli Kiviranta
  2024-06-04 20:58                                 ` Eugene Y Chang
  2024-06-04 23:03                               ` Rich Brown
  1 sibling, 1 reply; 59+ messages in thread
From: Sauli Kiviranta @ 2024-06-04 20:06 UTC (permalink / raw)
  To: Stuart Cheshire; +Cc: Rich Brown, Dave Taht via Starlink, Colin_Higbie

[-- Attachment #1: Type: text/plain, Size: 6132 bytes --]

Good examples Stuart, it is quite interesting that as humanity we have not
come up with aggregate term what would fairly collapse the dimensions to
one single metric that would describe the snappy feeling we intuitively
seek for but can not quite verbalize. Vehicles have the same issues, we
have top speed (F1 at 360mph feels fast compared to Starship at 16000mph),
we have acceleration (Hot-rod going 0 to 60 mph in 5 seconds feels high but
pales in comparison to Tesla going 0 to 60 mph in 2 sec), we have horse
powers (tractor plowing field with 300hp feels great but seems small
compared to 1000hp of Hot-rod) then also there is torque (tractor with 1450
Nm of torque wins a Tesla having 900Nm on wheel while at completely
different torque curve).

Capacity has the same issue as literally the truck from your example
shipping magnetic tapes for "raw carry capacity" but it does not feel
responsive, snappy, good to handle in the "traffic" of Internet. We have
jitter, that could be compared to how a vehicle does in repeatability of
track laps? We have packet loss on how the car handles on curves and does
it slip off the track or on accelerations spin the wheels? Download is
speed forward, upload is almost like speed at reverse gear usually far
worse. Latency is like a lap track as such, depends on the track, use-case
specific tests "What time did it do on Nürburgring?" or "How fast does it
go from 0 to 60Mbps? Less than 200ms?". Horse power feels much like raw
capacity of the HW / radio channel and techniques available beam forming,
frequencies etc. what was discussed here related to Starlink and even
collectively across different technologies. Speed is then instead of how
much specific combination of modem and base-station combo can achieve at
certain configuration? Torque feels like ability to maintain that
performance, closest we get is loaded performance in context of
bufferbloat?

Watching videos on Netflix require different performance characteristics
than downloading a big update to Fortnite. One has certain acceleration
need to have snappy user experience but focus is more on connection
stability at certain bitrate. On the other hand Fortnite update you want to
be delivered at brute force speeds without ruining others user experience.

Maybe we can not find that aggregate property or metric, but just need to
be rigorous on making sure we accurately characterize each dimension and
standardize them so the confusion and play with words, specially with
marketing, get stabilized. Each needs to have standardized benchmarks much
like 3D rendering benchmarks and PC perf tests are done? All that said, as
I failed to come up with a perfect term, "varying performance ISP links"
feels like the right thing to say? Now we have obfuscated to be able to
throw any of the dimensions underneath. Only thing left for us to do is
then to provide those dimensions like a nutrient labels. We are getting
there? Nothing new under the sun also to some extend.

Just as a funny side note on the tractor marketing:

”Torque gives you the feeling of responsiveness and that the machine does
the right things,” Tapani Katila encapsulates his view. “The torque is
directly linked to the feeling of having power available in the entire
range of the power curve, resulting in more meaningful work.” from
https://www.agcopower.com/power-is-important-but-torque-is-crucial/

Seems like some other people are also trying to figure out what dimensions
to showcase to customers?

Thank you for the thought provoking examples!

Is bufferbloat property of a vehicle or characteristic of the road design?
Is it a question of ICE vs EV -or- roundabout vs crossing with traffic
lights? Feels more like a roundabout, no? Is this the problem behind the
objections?

- Sauli

On Tue, Jun 4, 2024 at 9:19 PM Stuart Cheshire via Starlink <
starlink@lists.bufferbloat.net> wrote:

> On May 7, 2024, at 18:48, Dave Taht via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
> > This was a wonderful post, rich!
>
> <
> https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/
> >
>
> I agree. Thanks for writing this Rich.
>
> One minor change I will request. Any time you write words like “speed” or
> “fast”, pause and consider whether it would be more accurate to use some
> other term like “capacity”, “bandwidth”, or “throughput”. Part of what
> keeps us in this mess is that people equate network capacity with “speed”,
> as if those terms were synonyms. We can’t change how people think
> overnight, but at least we can avoid further reinforcing that wrong
> thinking.
>
> If someone has 200 Mb/s Internet service and it feels slow, then they
> might upgrade to 400 Mb/s Internet service and expect everything to be
> uniformly twice as fast. We here know that doubling the network capacity
> may make large downloads faster, but everything else is most likely
> unchanged, and can be even worse.
>
> People never make this mistake in other contexts. If someone commutes to
> work in their 20-foot RV feels that it’s too slow, then upgrading to a
> 40-foot RV will not get them to work faster. A 40-foot RV is *bigger* than
> a 20-foot RV, but it’s probably not *faster*. If you are moving a vast
> amount of cargo that requires multiple trips, then a larger truck will let
> you complete that task in fewer trips. But for most daily driving, a bigger
> truck will not get to your destination any quicker.
>
> Some simple edits:
>
> Instead of “varying speed ISP links” how about “varying capacity ISP
> links”?
>
> Instead of “they profit if you decide your network is too slow and you
> upgrade to a faster device/plan” how about “they profit if you decide your
> network is too slow and you upgrade to a higher throughput device/plan”?
>
> Stuart Cheshire
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 7031 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-08  1:48                           ` Dave Taht
  2024-05-08  7:58                             ` Frantisek Borsik
  2024-05-08 18:29                             ` Eugene Y Chang
@ 2024-06-04 18:19                             ` Stuart Cheshire
  2024-06-04 20:06                               ` Sauli Kiviranta
  2024-06-04 23:03                               ` Rich Brown
  2 siblings, 2 replies; 59+ messages in thread
From: Stuart Cheshire @ 2024-06-04 18:19 UTC (permalink / raw)
  To: Rich Brown; +Cc: Dave Täht, Dave Taht via Starlink, Colin_Higbie

On May 7, 2024, at 18:48, Dave Taht via Starlink <starlink@lists.bufferbloat.net> wrote:

> This was a wonderful post, rich!

<https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/>

I agree. Thanks for writing this Rich.

One minor change I will request. Any time you write words like “speed” or “fast”, pause and consider whether it would be more accurate to use some other term like “capacity”, “bandwidth”, or “throughput”. Part of what keeps us in this mess is that people equate network capacity with “speed”, as if those terms were synonyms. We can’t change how people think overnight, but at least we can avoid further reinforcing that wrong thinking.

If someone has 200 Mb/s Internet service and it feels slow, then they might upgrade to 400 Mb/s Internet service and expect everything to be uniformly twice as fast. We here know that doubling the network capacity may make large downloads faster, but everything else is most likely unchanged, and can be even worse.

People never make this mistake in other contexts. If someone commutes to work in their 20-foot RV feels that it’s too slow, then upgrading to a 40-foot RV will not get them to work faster. A 40-foot RV is *bigger* than a 20-foot RV, but it’s probably not *faster*. If you are moving a vast amount of cargo that requires multiple trips, then a larger truck will let you complete that task in fewer trips. But for most daily driving, a bigger truck will not get to your destination any quicker.

Some simple edits:

Instead of “varying speed ISP links” how about “varying capacity ISP links”?

Instead of “they profit if you decide your network is too slow and you upgrade to a faster device/plan” how about “they profit if you decide your network is too slow and you upgrade to a higher throughput device/plan”?

Stuart Cheshire


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-08  1:48                           ` Dave Taht
  2024-05-08  7:58                             ` Frantisek Borsik
@ 2024-05-08 18:29                             ` Eugene Y Chang
  2024-06-04 18:19                             ` Stuart Cheshire
  2 siblings, 0 replies; 59+ messages in thread
From: Eugene Y Chang @ 2024-05-08 18:29 UTC (permalink / raw)
  To: Dave Taht
  Cc: Eugene Y Chang, Rich Brown, Sebastian Moeller, Colin_Higbie,
	Dave Taht via Starlink


[-- Attachment #1.1: Type: text/plain, Size: 11990 bytes --]

I am appreciating this email thread.

It is really hard to “sell” the features ala carte. They need to be bundled into reference packages. This you know.

> The wisps totally got it with fq codel and cake arriving native for mikeotiks entire product line and much of ubnts gear prior to that.


Now we need a demo (or packaged test suite) that shows a full package (aka Mikrotik) against a less capable implementation with missing features. Users need to visualize the difference to develop envy for the whole package. Hopefully, the demo is not lame.

Dave, did you indirectly point out that an eSports demo with Miriotik AP/routers could deliver visible improvement? What do I need to verify before trying it out? Any advice on what expectations to set?

Gene
----------------------------------------------
Eugene Chang




> On May 7, 2024, at 3:48 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> This was a wonderful post, rich!
> 
> I note that preseem, paraqum,  bequant and libreqos (a bufferbloat.net <http://bufferbloat.net/> backed project) are in the fq codel or cake Middlebox for isps *Qoe) market and all of us have made a substantial dent in the problem for oh, call it 1000 isps worldwide total between us. Comcast also has done a pretty good job but it seems yhe rest of the cable industry is asleep at the switch.
> 
> The wisps totally got it with fq codel and cake arriving native for mikeotiks entire product line and much of ubnts gear prior to that.
> 
> 
> Qoe is still a pretty hard sell. Libreqos has a ton of free users and we think over a million devices managed by it but not enough paid users to justify even 1/10th the investment we have made so far into it (something that I hope turns around with the upcoming v1.5 lts release and some outputs from the nlnet and Comcast funded cakemaint and nqb projects)
> 
> Thing is, at higher and fiber rates all the bloat moves to the wifi, and a ton of that, like eero especially was long ago fq codeled and so I think several major players have also (except for those stuck with broadcom).
> 
> That said there are a lot of defective wifi aps left to replace. Nearly every coffee shop I have been in with the exception of Starbucks has really lousy wifi.
> 
> I am so thrilled to see what starlink has accomplished so far with their rollout of bufferbloat.net <http://bufferbloat.net/> stuff and look forward to more. They are still missing a few tricks... but are aware of what tricks they are missing...
> 
> Lack of knowledge of which regrettably remains the case for 97% of the market and 99.99$ user base. Still ar apps will drive this rventually... I think starlink is nicely positioned now to meet their demanding growth goals and humanity's future in space assured, so there's that. ( i still would rather like elone to send over a nice pair of tesla motors and battery pack for my sailboat)
> 
> I did have a nice jam with ajit Pai last week who is now well on his way towards getting it. (See my twitter for the pics)
> 
> On Mon, May 6, 2024, 4:25 AM Rich Brown via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
> Hi Gene,
> 
> I've been vacillating on whether to send this note, but have decided to pull the trigger. I apologize in advance for the "Debbie Downer" nature of this message. I also apologize for any errors, omissions, or over-simplifications of the "birth of bufferbloat" story and its fixes. Corrections welcome.
> 
> Rich
> ------
> 
> If we are going to take a shot at opening people's eyes to bufferbloat, we should know some of the "objections" we'll run up against. Even though there's terrific technical data to back it up, people seem especially resistant to thinking that bufferbloat might affect their network, even when they're seeing problems that sound exactly like bufferbloat symptoms. But first, some history:
> 
> The very idea of bufferbloat is simply unbelievable. Jim Gettys in 2011 [1] couldn't believe it, and he's a smart networking guy,. At the time, it seemed incredible (that is "not credible" == impossible) that something could induce 1.2 seconds of latency into his home network connection. He called in favors from technical contacts at his ISP and at Bell Labs who went over everything with a fine-toothed comb. It was all exactly as spec'd. But he still had the latency.
> 
> This led Jim and Dave Täht to start the investigation into the phenomenon known today as "bufferbloat" - the undesirable latency that comes from a router or other network equipment buffering too much data. Over several years, a group of smart people made huge improvements: fq_codel was released 14 May 2012 [3]; it was incorporated into the Linux kernel shortly afterward. CAKE came in 2015, and the fixes that minimize bufferbloat in Wi-Fi arrived in 2018. In 2021 cake-autorate [4] arrived to handle varying speed ISP links. All these techniques work great: in 2014, my 7mbps DSL link was quite usable. And when the pandemic hit, fq_codel on my OpenWrt router allowed me to use that same 7mbps DSL line for two simultaneous zoom calls.
> 
> As one of the authors of [2], I am part of the team that has tried over the years to explain bufferbloat and how to fix it. We've spoken with vendors. We've spent untold hours responding to posts on assorted boards and forums with the the bufferbloat story.
> 
> With these technical fixes in hand, we cockily set about to tell the world about how to fix bufferbloat. Our efforts have been met with skepticism at best, or stony silence. What are the objections?
> 
> - This is just the ordinary behavior: I would expect things to be slower when there's more traffic (Willfully ignoring orders of magnitude increase in delay.)
> - Besides, I'm the only one using the internet. (Except when my phone uploads photos. Or my computer kicks off some automated process. Or I browse the web. Or ...)
> - It only happens some of the time. (Exactly. That's probably when something's uploading photos, or your computer is doing stuff in the background.)
> - Those bufferbloat tests you hear about are bogus. They artificially add load, which isn't a realistic test. (...and if you actually are downloading a file?)
> - Bufferbloat only happens when the network is 100% loaded. (True. But when you open a web page, your browser briefly uses 100% of the link. Is this enough to cause momentary lag?)
> - It's OK. I just tell my kids/spouse not to use the internet when I'm gaming. (Huh?)
> - I have gigabit service from my ISP. (That helps, but if you're complaining about "slowness" you still need to rule out bufferbloat in your router.)
> - I can't believe that router manufacturers would ever allow such a thing to happen in their gear. (See the Jim Gettys story above.)
> - I mean... wouldn't router vendors want to provide the best for their customers? (No - implementing this (new-ish) code requires engineering effort. They're selling plenty of routers with decade-old software. The Boss says, "would we sell more if they made these changes? Probably not.")
> - Why would my ISP provision/sell me a router that gave crappy service? They're a big company, they must know about this stuff. (Maybe. We have reached out to all the vendors. But remember they profit if you decide your network is too slow and you upgrade to a faster device/plan.)
> - But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
> - Besides, I just spent $300 on a "gaming router". Obviously, I bought the most expensive/best possible solution on the market (But I still have lag...)
> - You're telling me that a bunch of pointy-headed academics are smarter than commercial router developers - who sold me that $300 router? (I can't believe it.)
> - And then you say that I should throw away that gaming router and install some "open source firmware"? (What the heck is that? And why should I believe you?)
> - What if it doesn't solve the problem? Who will give me support? And how will I get back to a vendor-supported system? (Valid point - the first valid point)
> - Aren't there any commercial solutions I can just buy? (Not at the moment. IQrouter was a shining light here - available from Amazon, simple setup, worked a treat - but they have gone out of business. And of course, for the skeptic, this is proof that the "fq_codel-stuff" isn't really a solution - it seems just like snake oil.)
> 
> So... All these hurdles make it hard to convince people that bufferbloat could be the problem, or that they can fix for themselves.
> 
> A couple of us have reached out to Consumer Reports, wondering if they would like a story about how vendors would prefer to sell you a new, faster router (or new faster ISP plan) than fix your bufferbloat. This kind of story seemed to be straight up their alley, but we never heard back after an initial contact. Maybe they deserve another call...
> 
> The recent latency results from Starlink give me a modicum of hope. They're a major player. They (and their customers) can point to an order of magnitude reduction in latency over other solutions. It still requires enough "regular customers" to tell their current ISP that they are switching to Starlink (and spend $600 to purchase a Dishy plus $100/month) to provide a market incentive.
> 
> Despite all this doom and gloom, I remain hopeful that things will get better. We know the technology exists for people to take control of their network and solve the problem for themselves. We can continue to respond on forums where people express their dismay at the crummy performance and suggest a solution. We can hope that a major vendor will twig to this effect and bring out a mass-market solution.
> 
> I think your suggestion of speaking to eSports people is intriguing. They're highly motivated to make their personal networks better. And actually solving the problem would have a network effect of bringing in others with the same problem.
> 
> Good luck, and thanks for thinking about this.
> 
> Rich Brown
> 
> [1] https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf <https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf>[2] https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/ <https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/>
> [3] https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html <https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html>
> [4] https://github.com/lynxthecat/cake-autorate <https://github.com/lynxthecat/cake-autorate>
> [5] https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos <https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos>
> 
>> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> 
>> Of course. For the gamers, the focus is managing latency. They have control of everything else.
>> 
>> With our high latency and wide range of values, the eSports teams train on campus. It will be interesting to see how much improvements there can be for teams to be able to training from their homes.
>> 
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>> IEEE Communications Society & Signal Processing Society,
>>     Hawaii Chapter Chair
>> IEEE Life Member Affinity Group Hawaii Chair
>> IEEE Entrepreneurship, Mentor
>> eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>
>> m 781-799-0233 (in Honolulu)
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>


[-- Attachment #1.2: Type: text/html, Size: 20622 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
@ 2024-05-08  9:31 David Fernández
  0 siblings, 0 replies; 59+ messages in thread
From: David Fernández @ 2024-05-08  9:31 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

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 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>
Content-Type: text/plain; charset="utf-8"; Format="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 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ández 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-videojuegos-nokia-vodafone

Regards,

David F.

[-- Attachment #2: Type: text/html, Size: 2553 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-08  7:58                             ` Frantisek Borsik
@ 2024-05-08  8:01                               ` Frantisek Borsik
  0 siblings, 0 replies; 59+ messages in thread
From: Frantisek Borsik @ 2024-05-08  8:01 UTC (permalink / raw)
  To: Dave Taht via Starlink; +Cc: Rich Brown, Colin_Higbie, Dave Taht

[-- Attachment #1: Type: text/plain, Size: 13083 bytes --]

Sorry - I meant ~ 4,5 % of the ISPs, not 2 :)

All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Wed, May 8, 2024 at 9:58 AM Frantisek Borsik <frantisek.borsik@gmail.com>
wrote:

> Just to add the latest numbers from our (LibreQoS) ongoing "QoE
> competitive landscape research":
>
> Out of 66k plus ISPs worldwide, barely 3k use some QoE middle-box. Preseem
> is the market leader, with well over 400 T2 & T3 ISPs (number shared in
> their wonderful Fixed Wireless Network Report 2024 Q1 Edition
> <https://preseem.com/wp-content/uploads/2024/01/Preseem-Fixed-Wireless-Network-Report-2024-Q1.pdf>),
> Bequant seems to be 2nd, in terms of market penetration, claiming 500+ ISPs
> worldwide. Then we assume Cambium Networks and Paraqum - numbers of their
> users are not know, but we can expect something similar, in the Preseem and
> Bequant ballpark. Then there is LibreQoS. All in all, it's safe to say that
> somewhere between 2,5 and 3 thousand Internet Service Providers worldwide
> are using QoE middle-box of sort. So barely 2% of the ISPs worldwide are
> using it, we are still in the "innovator" stage of the whole "crossing the
> chasm" paradigm.
>
> We are all still very early on, working on it, and I'm lovin' it.
>
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.borsik@gmail.com
>
>
> On Wed, May 8, 2024 at 4:16 AM Dave Taht via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> This was a wonderful post, rich!
>>
>> I note that preseem, paraqum,  bequant and libreqos (a bufferbloat.net
>> backed project) are in the fq codel or cake Middlebox for isps *Qoe) market
>> and all of us have made a substantial dent in the problem for oh, call it
>> 1000 isps worldwide total between us. Comcast also has done a pretty good
>> job but it seems yhe rest of the cable industry is asleep at the switch.
>>
>> The wisps totally got it with fq codel and cake arriving native for
>> mikeotiks entire product line and much of ubnts gear prior to that.
>>
>>
>> Qoe is still a pretty hard sell. Libreqos has a ton of free users and we
>> think over a million devices managed by it but not enough paid users to
>> justify even 1/10th the investment we have made so far into it (something
>> that I hope turns around with the upcoming v1.5 lts release and some
>> outputs from the nlnet and Comcast funded cakemaint and nqb projects)
>>
>> Thing is, at higher and fiber rates all the bloat moves to the wifi, and
>> a ton of that, like eero especially was long ago fq codeled and so I think
>> several major players have also (except for those stuck with broadcom).
>>
>> That said there are a lot of defective wifi aps left to replace. Nearly
>> every coffee shop I have been in with the exception of Starbucks has really
>> lousy wifi.
>>
>> I am so thrilled to see what starlink has accomplished so far with their
>> rollout of bufferbloat.net stuff and look forward to more. They are
>> still missing a few tricks... but are aware of what tricks they are
>> missing...
>>
>> Lack of knowledge of which regrettably remains the case for 97% of the
>> market and 99.99$ user base. Still ar apps will drive this rventually... I
>> think starlink is nicely positioned now to meet their demanding growth
>> goals and humanity's future in space assured, so there's that. ( i still
>> would rather like elone to send over a nice pair of tesla motors and
>> battery pack for my sailboat)
>>
>> I did have a nice jam with ajit Pai last week who is now well on his way
>> towards getting it. (See my twitter for the pics)
>>
>> On Mon, May 6, 2024, 4:25 AM Rich Brown via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> Hi Gene,
>>>
>>> I've been vacillating on whether to send this note, but have decided to
>>> pull the trigger. I apologize in advance for the "Debbie Downer" nature of
>>> this message. I also apologize for any errors, omissions, or
>>> over-simplifications of the "birth of bufferbloat" story and its fixes.
>>> Corrections welcome.
>>>
>>> Rich
>>> ------
>>>
>>> If we are going to take a shot at opening people's eyes to bufferbloat,
>>> we should know some of the "objections" we'll run up against. Even though
>>> there's terrific technical data to back it up, people seem especially
>>> resistant to thinking that bufferbloat might affect their network, even
>>> when they're seeing problems that sound exactly like bufferbloat symptoms.
>>> But first, some history:
>>>
>>> The very idea of bufferbloat is simply unbelievable. Jim Gettys in 2011
>>> [1] couldn't believe it, and he's a smart networking guy,. At the time, it
>>> seemed incredible (that is "not credible" == impossible) that something
>>> could induce 1.2 seconds of latency into his home network connection. He
>>> called in favors from technical contacts at his ISP and at Bell Labs who
>>> went over everything with a fine-toothed comb. It was all exactly as
>>> spec'd. But he still had the latency.
>>>
>>> This led Jim and Dave Täht to start the investigation into the
>>> phenomenon known today as "bufferbloat" - the undesirable latency that
>>> comes from a router or other network equipment buffering too much data.
>>> Over several years, a group of smart people made huge improvements:
>>> fq_codel was released 14 May 2012 [3]; it was incorporated into the Linux
>>> kernel shortly afterward. CAKE came in 2015, and the fixes that minimize
>>> bufferbloat in Wi-Fi arrived in 2018. In 2021 cake-autorate [4] arrived to
>>> handle varying speed ISP links. All these techniques work great: in 2014,
>>> my 7mbps DSL link was quite usable. And when the pandemic hit, fq_codel on
>>> my OpenWrt router allowed me to use that same 7mbps DSL line for two
>>> simultaneous zoom calls.
>>>
>>> As one of the authors of [2], I am part of the team that has tried over
>>> the years to explain bufferbloat and how to fix it. We've spoken with
>>> vendors. We've spent untold hours responding to posts on assorted boards
>>> and forums with the the bufferbloat story.
>>>
>>> With these technical fixes in hand, we cockily set about to tell the
>>> world about how to fix bufferbloat. Our efforts have been met with
>>> skepticism at best, or stony silence. What are the objections?
>>>
>>> - This is just the ordinary behavior: I would expect things to be slower
>>> when there's more traffic (Willfully ignoring orders of magnitude increase
>>> in delay.)
>>> - Besides, I'm the only one using the internet. (Except when my phone
>>> uploads photos. Or my computer kicks off some automated process. Or I
>>> browse the web. Or ...)
>>> - It only happens some of the time. (Exactly. That's probably when
>>> something's uploading photos, or your computer is doing stuff in the
>>> background.)
>>> - Those bufferbloat tests you hear about are bogus. They artificially
>>> add load, which isn't a realistic test. (...and if you actually are
>>> downloading a file?)
>>> - Bufferbloat only happens when the network is 100% loaded. (True. But
>>> when you open a web page, your browser briefly uses 100% of the link. Is
>>> this enough to cause momentary lag?)
>>> - It's OK. I just tell my kids/spouse not to use the internet when I'm
>>> gaming. (Huh?)
>>> - I have gigabit service from my ISP. (That helps, but if you're
>>> complaining about "slowness" you still need to rule out bufferbloat in your
>>> router.)
>>> - I can't believe that router manufacturers would ever allow such a
>>> thing to happen in their gear. (See the Jim Gettys story above.)
>>> - I mean... wouldn't router vendors want to provide the best for their
>>> customers? (No - implementing this (new-ish) code requires engineering
>>> effort. They're selling plenty of routers with decade-old software. The
>>> Boss says, "would we sell more if they made these changes? Probably not.")
>>> - Why would my ISP provision/sell me a router that gave crappy service?
>>> They're a big company, they must know about this stuff. (Maybe. We have
>>> reached out to all the vendors. But remember they profit if you decide your
>>> network is too slow and you upgrade to a faster device/plan.)
>>> - But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
>>> - Besides, I just spent $300 on a "gaming router". Obviously, I bought
>>> the most expensive/best possible solution on the market (But I still have
>>> lag...)
>>> - You're telling me that a bunch of pointy-headed academics are smarter
>>> than commercial router developers - who sold me that $300 router? (I can't
>>> believe it.)
>>> - And then you say that I should throw away that gaming router and
>>> install some "open source firmware"? (What the heck is that? And why should
>>> I believe you?)
>>> - What if it doesn't solve the problem? Who will give me support? And
>>> how will I get back to a vendor-supported system? (Valid point - the first
>>> valid point)
>>> - Aren't there any commercial solutions I can just buy? (Not at the
>>> moment. IQrouter was a shining light here - available from Amazon, simple
>>> setup, worked a treat - but they have gone out of business. And of course,
>>> for the skeptic, this is proof that the "fq_codel-stuff" isn't really a
>>> solution - it seems just like snake oil.)
>>>
>>> So... All these hurdles make it hard to convince people that bufferbloat
>>> could be the problem, or that they can fix for themselves.
>>>
>>> A couple of us have reached out to Consumer Reports, wondering if they
>>> would like a story about how vendors would prefer to sell you a new, faster
>>> router (or new faster ISP plan) than fix your bufferbloat. This kind of
>>> story seemed to be straight up their alley, but we never heard back after
>>> an initial contact. Maybe they deserve another call...
>>>
>>> The recent latency results from Starlink give me a modicum of hope.
>>> They're a major player. They (and their customers) can point to an order of
>>> magnitude reduction in latency over other solutions. It still requires
>>> enough "regular customers" to tell their current ISP that they are
>>> switching to Starlink (and spend $600 to purchase a Dishy plus $100/month)
>>> to provide a market incentive.
>>>
>>> Despite all this doom and gloom, I remain hopeful that things will get
>>> better. We know the technology exists for people to take control of their
>>> network and solve the problem for themselves. We can continue to respond on
>>> forums where people express their dismay at the crummy performance and
>>> suggest a solution. We can hope that a major vendor will twig to this
>>> effect and bring out a mass-market solution.
>>>
>>> I think your suggestion of speaking to eSports people is intriguing.
>>> They're highly motivated to make their personal networks better. And
>>> actually solving the problem would have a network effect of bringing in
>>> others with the same problem.
>>>
>>> Good luck, and thanks for thinking about this.
>>>
>>> Rich Brown
>>>
>>> [1]
>>> https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf
>>> [2]
>>> https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/
>>> [3]
>>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html
>>> [4] https://github.com/lynxthecat/cake-autorate
>>> [5]
>>> https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos
>>>
>>> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>> Of course. For the gamers, the focus is managing latency. They have
>>> control of everything else.
>>>
>>> With our high latency and wide range of values, the eSports teams train
>>> on campus. It will be interesting to see how much improvements there can be
>>> for teams to be able to training from their homes.
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>> IEEE Communications Society & Signal Processing Society,
>>>     Hawaii Chapter Chair
>>> IEEE Life Member Affinity Group Hawaii Chair
>>> IEEE Entrepreneurship, Mentor
>>> eugene.chang@ieee.org
>>> m 781-799-0233 (in Honolulu)
>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>

[-- Attachment #2: Type: text/html, Size: 19679 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-08  1:48                           ` Dave Taht
@ 2024-05-08  7:58                             ` Frantisek Borsik
  2024-05-08  8:01                               ` Frantisek Borsik
  2024-05-08 18:29                             ` Eugene Y Chang
  2024-06-04 18:19                             ` Stuart Cheshire
  2 siblings, 1 reply; 59+ messages in thread
From: Frantisek Borsik @ 2024-05-08  7:58 UTC (permalink / raw)
  To: Dave Taht via Starlink; +Cc: Rich Brown, Colin_Higbie, Dave Taht

[-- Attachment #1: Type: text/plain, Size: 12418 bytes --]

Just to add the latest numbers from our (LibreQoS) ongoing "QoE competitive
landscape research":

Out of 66k plus ISPs worldwide, barely 3k use some QoE middle-box. Preseem
is the market leader, with well over 400 T2 & T3 ISPs (number shared in
their wonderful Fixed Wireless Network Report 2024 Q1 Edition
<https://preseem.com/wp-content/uploads/2024/01/Preseem-Fixed-Wireless-Network-Report-2024-Q1.pdf>),
Bequant seems to be 2nd, in terms of market penetration, claiming 500+ ISPs
worldwide. Then we assume Cambium Networks and Paraqum - numbers of their
users are not know, but we can expect something similar, in the Preseem and
Bequant ballpark. Then there is LibreQoS. All in all, it's safe to say that
somewhere between 2,5 and 3 thousand Internet Service Providers worldwide
are using QoE middle-box of sort. So barely 2% of the ISPs worldwide are
using it, we are still in the "innovator" stage of the whole "crossing the
chasm" paradigm.

We are all still very early on, working on it, and I'm lovin' it.


All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Wed, May 8, 2024 at 4:16 AM Dave Taht via Starlink <
starlink@lists.bufferbloat.net> wrote:

> This was a wonderful post, rich!
>
> I note that preseem, paraqum,  bequant and libreqos (a bufferbloat.net
> backed project) are in the fq codel or cake Middlebox for isps *Qoe) market
> and all of us have made a substantial dent in the problem for oh, call it
> 1000 isps worldwide total between us. Comcast also has done a pretty good
> job but it seems yhe rest of the cable industry is asleep at the switch.
>
> The wisps totally got it with fq codel and cake arriving native for
> mikeotiks entire product line and much of ubnts gear prior to that.
>
>
> Qoe is still a pretty hard sell. Libreqos has a ton of free users and we
> think over a million devices managed by it but not enough paid users to
> justify even 1/10th the investment we have made so far into it (something
> that I hope turns around with the upcoming v1.5 lts release and some
> outputs from the nlnet and Comcast funded cakemaint and nqb projects)
>
> Thing is, at higher and fiber rates all the bloat moves to the wifi, and a
> ton of that, like eero especially was long ago fq codeled and so I think
> several major players have also (except for those stuck with broadcom).
>
> That said there are a lot of defective wifi aps left to replace. Nearly
> every coffee shop I have been in with the exception of Starbucks has really
> lousy wifi.
>
> I am so thrilled to see what starlink has accomplished so far with their
> rollout of bufferbloat.net stuff and look forward to more. They are still
> missing a few tricks... but are aware of what tricks they are missing...
>
> Lack of knowledge of which regrettably remains the case for 97% of the
> market and 99.99$ user base. Still ar apps will drive this rventually... I
> think starlink is nicely positioned now to meet their demanding growth
> goals and humanity's future in space assured, so there's that. ( i still
> would rather like elone to send over a nice pair of tesla motors and
> battery pack for my sailboat)
>
> I did have a nice jam with ajit Pai last week who is now well on his way
> towards getting it. (See my twitter for the pics)
>
> On Mon, May 6, 2024, 4:25 AM Rich Brown via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> Hi Gene,
>>
>> I've been vacillating on whether to send this note, but have decided to
>> pull the trigger. I apologize in advance for the "Debbie Downer" nature of
>> this message. I also apologize for any errors, omissions, or
>> over-simplifications of the "birth of bufferbloat" story and its fixes.
>> Corrections welcome.
>>
>> Rich
>> ------
>>
>> If we are going to take a shot at opening people's eyes to bufferbloat,
>> we should know some of the "objections" we'll run up against. Even though
>> there's terrific technical data to back it up, people seem especially
>> resistant to thinking that bufferbloat might affect their network, even
>> when they're seeing problems that sound exactly like bufferbloat symptoms.
>> But first, some history:
>>
>> The very idea of bufferbloat is simply unbelievable. Jim Gettys in 2011
>> [1] couldn't believe it, and he's a smart networking guy,. At the time, it
>> seemed incredible (that is "not credible" == impossible) that something
>> could induce 1.2 seconds of latency into his home network connection. He
>> called in favors from technical contacts at his ISP and at Bell Labs who
>> went over everything with a fine-toothed comb. It was all exactly as
>> spec'd. But he still had the latency.
>>
>> This led Jim and Dave Täht to start the investigation into the phenomenon
>> known today as "bufferbloat" - the undesirable latency that comes from a
>> router or other network equipment buffering too much data. Over several
>> years, a group of smart people made huge improvements: fq_codel was
>> released 14 May 2012 [3]; it was incorporated into the Linux kernel shortly
>> afterward. CAKE came in 2015, and the fixes that minimize bufferbloat in
>> Wi-Fi arrived in 2018. In 2021 cake-autorate [4] arrived to handle varying
>> speed ISP links. All these techniques work great: in 2014, my 7mbps DSL
>> link was quite usable. And when the pandemic hit, fq_codel on my OpenWrt
>> router allowed me to use that same 7mbps DSL line for two simultaneous zoom
>> calls.
>>
>> As one of the authors of [2], I am part of the team that has tried over
>> the years to explain bufferbloat and how to fix it. We've spoken with
>> vendors. We've spent untold hours responding to posts on assorted boards
>> and forums with the the bufferbloat story.
>>
>> With these technical fixes in hand, we cockily set about to tell the
>> world about how to fix bufferbloat. Our efforts have been met with
>> skepticism at best, or stony silence. What are the objections?
>>
>> - This is just the ordinary behavior: I would expect things to be slower
>> when there's more traffic (Willfully ignoring orders of magnitude increase
>> in delay.)
>> - Besides, I'm the only one using the internet. (Except when my phone
>> uploads photos. Or my computer kicks off some automated process. Or I
>> browse the web. Or ...)
>> - It only happens some of the time. (Exactly. That's probably when
>> something's uploading photos, or your computer is doing stuff in the
>> background.)
>> - Those bufferbloat tests you hear about are bogus. They artificially add
>> load, which isn't a realistic test. (...and if you actually are downloading
>> a file?)
>> - Bufferbloat only happens when the network is 100% loaded. (True. But
>> when you open a web page, your browser briefly uses 100% of the link. Is
>> this enough to cause momentary lag?)
>> - It's OK. I just tell my kids/spouse not to use the internet when I'm
>> gaming. (Huh?)
>> - I have gigabit service from my ISP. (That helps, but if you're
>> complaining about "slowness" you still need to rule out bufferbloat in your
>> router.)
>> - I can't believe that router manufacturers would ever allow such a thing
>> to happen in their gear. (See the Jim Gettys story above.)
>> - I mean... wouldn't router vendors want to provide the best for their
>> customers? (No - implementing this (new-ish) code requires engineering
>> effort. They're selling plenty of routers with decade-old software. The
>> Boss says, "would we sell more if they made these changes? Probably not.")
>> - Why would my ISP provision/sell me a router that gave crappy service?
>> They're a big company, they must know about this stuff. (Maybe. We have
>> reached out to all the vendors. But remember they profit if you decide your
>> network is too slow and you upgrade to a faster device/plan.)
>> - But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
>> - Besides, I just spent $300 on a "gaming router". Obviously, I bought
>> the most expensive/best possible solution on the market (But I still have
>> lag...)
>> - You're telling me that a bunch of pointy-headed academics are smarter
>> than commercial router developers - who sold me that $300 router? (I can't
>> believe it.)
>> - And then you say that I should throw away that gaming router and
>> install some "open source firmware"? (What the heck is that? And why should
>> I believe you?)
>> - What if it doesn't solve the problem? Who will give me support? And how
>> will I get back to a vendor-supported system? (Valid point - the first
>> valid point)
>> - Aren't there any commercial solutions I can just buy? (Not at the
>> moment. IQrouter was a shining light here - available from Amazon, simple
>> setup, worked a treat - but they have gone out of business. And of course,
>> for the skeptic, this is proof that the "fq_codel-stuff" isn't really a
>> solution - it seems just like snake oil.)
>>
>> So... All these hurdles make it hard to convince people that bufferbloat
>> could be the problem, or that they can fix for themselves.
>>
>> A couple of us have reached out to Consumer Reports, wondering if they
>> would like a story about how vendors would prefer to sell you a new, faster
>> router (or new faster ISP plan) than fix your bufferbloat. This kind of
>> story seemed to be straight up their alley, but we never heard back after
>> an initial contact. Maybe they deserve another call...
>>
>> The recent latency results from Starlink give me a modicum of hope.
>> They're a major player. They (and their customers) can point to an order of
>> magnitude reduction in latency over other solutions. It still requires
>> enough "regular customers" to tell their current ISP that they are
>> switching to Starlink (and spend $600 to purchase a Dishy plus $100/month)
>> to provide a market incentive.
>>
>> Despite all this doom and gloom, I remain hopeful that things will get
>> better. We know the technology exists for people to take control of their
>> network and solve the problem for themselves. We can continue to respond on
>> forums where people express their dismay at the crummy performance and
>> suggest a solution. We can hope that a major vendor will twig to this
>> effect and bring out a mass-market solution.
>>
>> I think your suggestion of speaking to eSports people is intriguing.
>> They're highly motivated to make their personal networks better. And
>> actually solving the problem would have a network effect of bringing in
>> others with the same problem.
>>
>> Good luck, and thanks for thinking about this.
>>
>> Rich Brown
>>
>> [1]
>> https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf
>> [2]
>> https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/
>> [3]
>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html
>> [4] https://github.com/lynxthecat/cake-autorate
>> [5]
>> https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos
>>
>> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>> Of course. For the gamers, the focus is managing latency. They have
>> control of everything else.
>>
>> With our high latency and wide range of values, the eSports teams train
>> on campus. It will be interesting to see how much improvements there can be
>> for teams to be able to training from their homes.
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>> IEEE Communications Society & Signal Processing Society,
>>     Hawaii Chapter Chair
>> IEEE Life Member Affinity Group Hawaii Chair
>> IEEE Entrepreneurship, Mentor
>> eugene.chang@ieee.org
>> m 781-799-0233 (in Honolulu)
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 17880 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-06 11:25                         ` [Starlink] The "reasons" that bufferbloat isn't a problem Rich Brown
                                             ` (2 preceding siblings ...)
  2024-05-07  0:38                           ` Eugene Y Chang
@ 2024-05-08  1:48                           ` Dave Taht
  2024-05-08  7:58                             ` Frantisek Borsik
                                               ` (2 more replies)
  3 siblings, 3 replies; 59+ messages in thread
From: Dave Taht @ 2024-05-08  1:48 UTC (permalink / raw)
  To: Rich Brown
  Cc: Sebastian Moeller, Colin_Higbie, Dave Taht via Starlink, Eugene Y Chang

[-- Attachment #1: Type: text/plain, Size: 10636 bytes --]

This was a wonderful post, rich!

I note that preseem, paraqum,  bequant and libreqos (a bufferbloat.net
backed project) are in the fq codel or cake Middlebox for isps *Qoe) market
and all of us have made a substantial dent in the problem for oh, call it
1000 isps worldwide total between us. Comcast also has done a pretty good
job but it seems yhe rest of the cable industry is asleep at the switch.

The wisps totally got it with fq codel and cake arriving native for
mikeotiks entire product line and much of ubnts gear prior to that.


Qoe is still a pretty hard sell. Libreqos has a ton of free users and we
think over a million devices managed by it but not enough paid users to
justify even 1/10th the investment we have made so far into it (something
that I hope turns around with the upcoming v1.5 lts release and some
outputs from the nlnet and Comcast funded cakemaint and nqb projects)

Thing is, at higher and fiber rates all the bloat moves to the wifi, and a
ton of that, like eero especially was long ago fq codeled and so I think
several major players have also (except for those stuck with broadcom).

That said there are a lot of defective wifi aps left to replace. Nearly
every coffee shop I have been in with the exception of Starbucks has really
lousy wifi.

I am so thrilled to see what starlink has accomplished so far with their
rollout of bufferbloat.net stuff and look forward to more. They are still
missing a few tricks... but are aware of what tricks they are missing...

Lack of knowledge of which regrettably remains the case for 97% of the
market and 99.99$ user base. Still ar apps will drive this rventually... I
think starlink is nicely positioned now to meet their demanding growth
goals and humanity's future in space assured, so there's that. ( i still
would rather like elone to send over a nice pair of tesla motors and
battery pack for my sailboat)

I did have a nice jam with ajit Pai last week who is now well on his way
towards getting it. (See my twitter for the pics)

On Mon, May 6, 2024, 4:25 AM Rich Brown via Starlink <
starlink@lists.bufferbloat.net> wrote:

> Hi Gene,
>
> I've been vacillating on whether to send this note, but have decided to
> pull the trigger. I apologize in advance for the "Debbie Downer" nature of
> this message. I also apologize for any errors, omissions, or
> over-simplifications of the "birth of bufferbloat" story and its fixes.
> Corrections welcome.
>
> Rich
> ------
>
> If we are going to take a shot at opening people's eyes to bufferbloat, we
> should know some of the "objections" we'll run up against. Even though
> there's terrific technical data to back it up, people seem especially
> resistant to thinking that bufferbloat might affect their network, even
> when they're seeing problems that sound exactly like bufferbloat symptoms.
> But first, some history:
>
> The very idea of bufferbloat is simply unbelievable. Jim Gettys in 2011
> [1] couldn't believe it, and he's a smart networking guy,. At the time, it
> seemed incredible (that is "not credible" == impossible) that something
> could induce 1.2 seconds of latency into his home network connection. He
> called in favors from technical contacts at his ISP and at Bell Labs who
> went over everything with a fine-toothed comb. It was all exactly as
> spec'd. But he still had the latency.
>
> This led Jim and Dave Täht to start the investigation into the phenomenon
> known today as "bufferbloat" - the undesirable latency that comes from a
> router or other network equipment buffering too much data. Over several
> years, a group of smart people made huge improvements: fq_codel was
> released 14 May 2012 [3]; it was incorporated into the Linux kernel shortly
> afterward. CAKE came in 2015, and the fixes that minimize bufferbloat in
> Wi-Fi arrived in 2018. In 2021 cake-autorate [4] arrived to handle varying
> speed ISP links. All these techniques work great: in 2014, my 7mbps DSL
> link was quite usable. And when the pandemic hit, fq_codel on my OpenWrt
> router allowed me to use that same 7mbps DSL line for two simultaneous zoom
> calls.
>
> As one of the authors of [2], I am part of the team that has tried over
> the years to explain bufferbloat and how to fix it. We've spoken with
> vendors. We've spent untold hours responding to posts on assorted boards
> and forums with the the bufferbloat story.
>
> With these technical fixes in hand, we cockily set about to tell the world
> about how to fix bufferbloat. Our efforts have been met with skepticism at
> best, or stony silence. What are the objections?
>
> - This is just the ordinary behavior: I would expect things to be slower
> when there's more traffic (Willfully ignoring orders of magnitude increase
> in delay.)
> - Besides, I'm the only one using the internet. (Except when my phone
> uploads photos. Or my computer kicks off some automated process. Or I
> browse the web. Or ...)
> - It only happens some of the time. (Exactly. That's probably when
> something's uploading photos, or your computer is doing stuff in the
> background.)
> - Those bufferbloat tests you hear about are bogus. They artificially add
> load, which isn't a realistic test. (...and if you actually are downloading
> a file?)
> - Bufferbloat only happens when the network is 100% loaded. (True. But
> when you open a web page, your browser briefly uses 100% of the link. Is
> this enough to cause momentary lag?)
> - It's OK. I just tell my kids/spouse not to use the internet when I'm
> gaming. (Huh?)
> - I have gigabit service from my ISP. (That helps, but if you're
> complaining about "slowness" you still need to rule out bufferbloat in your
> router.)
> - I can't believe that router manufacturers would ever allow such a thing
> to happen in their gear. (See the Jim Gettys story above.)
> - I mean... wouldn't router vendors want to provide the best for their
> customers? (No - implementing this (new-ish) code requires engineering
> effort. They're selling plenty of routers with decade-old software. The
> Boss says, "would we sell more if they made these changes? Probably not.")
> - Why would my ISP provision/sell me a router that gave crappy service?
> They're a big company, they must know about this stuff. (Maybe. We have
> reached out to all the vendors. But remember they profit if you decide your
> network is too slow and you upgrade to a faster device/plan.)
> - But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
> - Besides, I just spent $300 on a "gaming router". Obviously, I bought the
> most expensive/best possible solution on the market (But I still have
> lag...)
> - You're telling me that a bunch of pointy-headed academics are smarter
> than commercial router developers - who sold me that $300 router? (I can't
> believe it.)
> - And then you say that I should throw away that gaming router and install
> some "open source firmware"? (What the heck is that? And why should I
> believe you?)
> - What if it doesn't solve the problem? Who will give me support? And how
> will I get back to a vendor-supported system? (Valid point - the first
> valid point)
> - Aren't there any commercial solutions I can just buy? (Not at the
> moment. IQrouter was a shining light here - available from Amazon, simple
> setup, worked a treat - but they have gone out of business. And of course,
> for the skeptic, this is proof that the "fq_codel-stuff" isn't really a
> solution - it seems just like snake oil.)
>
> So... All these hurdles make it hard to convince people that bufferbloat
> could be the problem, or that they can fix for themselves.
>
> A couple of us have reached out to Consumer Reports, wondering if they
> would like a story about how vendors would prefer to sell you a new, faster
> router (or new faster ISP plan) than fix your bufferbloat. This kind of
> story seemed to be straight up their alley, but we never heard back after
> an initial contact. Maybe they deserve another call...
>
> The recent latency results from Starlink give me a modicum of hope.
> They're a major player. They (and their customers) can point to an order of
> magnitude reduction in latency over other solutions. It still requires
> enough "regular customers" to tell their current ISP that they are
> switching to Starlink (and spend $600 to purchase a Dishy plus $100/month)
> to provide a market incentive.
>
> Despite all this doom and gloom, I remain hopeful that things will get
> better. We know the technology exists for people to take control of their
> network and solve the problem for themselves. We can continue to respond on
> forums where people express their dismay at the crummy performance and
> suggest a solution. We can hope that a major vendor will twig to this
> effect and bring out a mass-market solution.
>
> I think your suggestion of speaking to eSports people is intriguing.
> They're highly motivated to make their personal networks better. And
> actually solving the problem would have a network effect of bringing in
> others with the same problem.
>
> Good luck, and thanks for thinking about this.
>
> Rich Brown
>
> [1]
> https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf
> [2]
> https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/
> [3]
> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html
> [4] https://github.com/lynxthecat/cake-autorate
> [5]
> https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos
>
> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
> Of course. For the gamers, the focus is managing latency. They have
> control of everything else.
>
> With our high latency and wide range of values, the eSports teams train on
> campus. It will be interesting to see how much improvements there can be
> for teams to be able to training from their homes.
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
> IEEE Communications Society & Signal Processing Society,
>     Hawaii Chapter Chair
> IEEE Life Member Affinity Group Hawaii Chair
> IEEE Entrepreneurship, Mentor
> eugene.chang@ieee.org
> m 781-799-0233 (in Honolulu)
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 14739 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-07 20:05             ` Frantisek Borsik
@ 2024-05-07 20:25               ` Eugene Y Chang
  0 siblings, 0 replies; 59+ messages in thread
From: Eugene Y Chang @ 2024-05-07 20:25 UTC (permalink / raw)
  To: Frantisek Borsik
  Cc: Eugene Y Chang, Dave Taht, Jeremy Austin, Dave Taht via Starlink,
	Dave Collier-Brown


[-- Attachment #1.1: Type: text/plain, Size: 4617 bytes --]

Thanks Frank,
So it is not the universal cure. Not surprising.
I don’t see a show-stopper for pushing adoption.

Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
IEEE Communications Society & Signal Processing Society,
    Hawaii Chapter Chair
IEEE Life Member Affinity Group Hawaii Chair
IEEE Entrepreneurship, Mentor
eugene.chang@ieee.org
m 781-799-0233 (in Honolulu)



> On May 7, 2024, at 10:05 AM, Frantisek Borsik <frantisek.borsik@gmail.com> wrote:
> 
> Here is a current view of it, IIRC:
> 
> https://forum.openwrt.org/t/rfc9330-rfc9331-rfc9332-for-lower-latency/180519/12 <https://forum.openwrt.org/t/rfc9330-rfc9331-rfc9332-for-lower-latency/180519/12>
> 
> All the best,
> 
> Frank
> 
> Frantisek (Frank) Borsik
> 
> 
> 
> https://www.linkedin.com/in/frantisekborsik <https://www.linkedin.com/in/frantisekborsik>
> Signal, Telegram, WhatsApp: +421919416714
> 
> iMessage, mobile: +420775230885
> 
> Skype: casioa5302ca
> 
> frantisek.borsik@gmail.com <mailto:frantisek.borsik@gmail.com>
> 
> On Tue, May 7, 2024 at 10:03 PM Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
> I thought I saw a reference to an OpenWRT implementation with L4S. How well does that work?
> 
> 
> 
> Gene
> ----------------------------------------------
> Eugene Chang
> 
> 
> 
>> On May 7, 2024, at 9:46 AM, Dave Taht <dave.taht@gmail.com <mailto:dave.taht@gmail.com>> wrote:
>> 
>> 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 <https://github.com/heistp>
>> 
>> The last was: https://github.com/heistp/l4s-tests?tab=readme-ov-file#key-findings <https://github.com/heistp/l4s-tests?tab=readme-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 ECN.
>> 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 PM Jeremy Austin <jeremy@aterlo.com <mailto:jeremy@aterlo.com>> wrote:
>>> 
>>> 
>>> 
>>> On Tue, May 7, 2024 at 11:11 AM Dave Taht via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> 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=BVFWSyMp3xg&t=1098s <https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s> Waves Podcast
>> Dave Täht CSO, LibreQos
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>


[-- Attachment #1.2: Type: text/html, Size: 12908 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-07 20:03           ` Eugene Y Chang
@ 2024-05-07 20:05             ` Frantisek Borsik
  2024-05-07 20:25               ` Eugene Y Chang
  0 siblings, 1 reply; 59+ messages in thread
From: Frantisek Borsik @ 2024-05-07 20:05 UTC (permalink / raw)
  To: Eugene Y Chang
  Cc: Dave Taht, Jeremy Austin, Dave Taht via Starlink, Dave Collier-Brown

[-- Attachment #1: Type: text/plain, Size: 3443 bytes --]

Here is a current view of it, IIRC:

https://forum.openwrt.org/t/rfc9330-rfc9331-rfc9332-for-lower-latency/180519/12

All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Tue, May 7, 2024 at 10:03 PM Eugene Y Chang via Starlink <
starlink@lists.bufferbloat.net> wrote:

> I thought I saw a reference to an OpenWRT implementation with L4S. How
> well does that work?
>
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
>
>
>
> On May 7, 2024, at 9:46 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
> 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=readme-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
> ECN.
> 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 PM Jeremy Austin <jeremy@aterlo.com> wrote:
>
>
>
>
> On Tue, May 7, 2024 at 11:11 AM Dave Taht via Starlink <
> starlink@lists.bufferbloat.net> 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=BVFWSyMp3xg&t=1098s Waves Podcast
> Dave Täht CSO, LibreQos
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 7534 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-07 19:46         ` Dave Taht
@ 2024-05-07 20:03           ` Eugene Y Chang
  2024-05-07 20:05             ` Frantisek Borsik
  0 siblings, 1 reply; 59+ messages in thread
From: Eugene Y Chang @ 2024-05-07 20:03 UTC (permalink / raw)
  To: Dave Taht, Jeremy Austin, Dave Taht via Starlink, Dave Collier-Brown


[-- Attachment #1.1: Type: text/plain, Size: 2801 bytes --]

I thought I saw a reference to an OpenWRT implementation with L4S. How well does that work?



Gene
----------------------------------------------
Eugene Chang



> On May 7, 2024, at 9:46 AM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> 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=readme-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 ECN.
> 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 PM Jeremy Austin <jeremy@aterlo.com> wrote:
>> 
>> 
>> 
>> On Tue, May 7, 2024 at 11:11 AM Dave Taht via Starlink <starlink@lists.bufferbloat.net> 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=BVFWSyMp3xg&t=1098s Waves Podcast
> Dave Täht CSO, LibreQos


[-- Attachment #1.2: Type: text/html, Size: 6904 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-07 19:14       ` Jeremy Austin
@ 2024-05-07 19:46         ` Dave Taht
  2024-05-07 20:03           ` Eugene Y Chang
  0 siblings, 1 reply; 59+ messages in thread
From: Dave Taht @ 2024-05-07 19:46 UTC (permalink / raw)
  To: Jeremy Austin; +Cc: Eugene Y Chang, Dave Taht via Starlink, Dave Collier-Brown

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=readme-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 ECN.
 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 PM Jeremy Austin <jeremy@aterlo.com> wrote:
>
>
>
> On Tue, May 7, 2024 at 11:11 AM Dave Taht via Starlink <starlink@lists.bufferbloat.net> 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=BVFWSyMp3xg&t=1098s Waves Podcast
Dave Täht CSO, LibreQos

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-07 19:11     ` Dave Taht
@ 2024-05-07 19:14       ` Jeremy Austin
  2024-05-07 19:46         ` Dave Taht
  0 siblings, 1 reply; 59+ messages in thread
From: Jeremy Austin @ 2024-05-07 19:14 UTC (permalink / raw)
  To: Dave Taht; +Cc: Eugene Y Chang, Dave Taht via Starlink, Dave Collier-Brown

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

On Tue, May 7, 2024 at 11:11 AM Dave Taht via Starlink <
starlink@lists.bufferbloat.net> 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

[-- Attachment #2: Type: text/html, Size: 703 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-07 19:09   ` Eugene Y Chang
@ 2024-05-07 19:11     ` Dave Taht
  2024-05-07 19:14       ` Jeremy Austin
  0 siblings, 1 reply; 59+ messages in thread
From: Dave Taht @ 2024-05-07 19:11 UTC (permalink / raw)
  To: Eugene Y Chang; +Cc: Dave Collier-Brown, Dave Taht via Starlink

The RFC is very plausible but the methods break down in multiple ways,
particularly with wifi.

On Tue, May 7, 2024 at 12:10 PM Eugene Y Chang via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> Dave,
> Thank you for calling attention to the RFC. I took a quick peek, and I need to put more time into reading the whole doc. It feels very intuitive.
>
> What I like is that it is written for incremental adoption. I will focus on that in my next pass. It opens the door to be incrementally deployed to pacify an influential squeaky wheel. I like the possibility that a happy squeaky wheel becomes a role model attracting more squeaky wheels until it makes more sense to just adopt broad deployment. If you read my earlier emails, you know I am in the hunt for an influential squeaky wheel. :P
>
> Anticipating more discussion in this direction, are there core router vendors that have a favorable view of  L4S? Are there router implementations just waiting to be turned on?
>
> Gene
> ----------------------------------------------
> Eugene Chang
>
>
>
>
> On May 7, 2024, at 2:46 AM, Dave Collier-Brown via Starlink <starlink@lists.bufferbloat.net> wrote:
>
> 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 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ández 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-videojuegos-nokia-vodafone
>
> Regards,
>
> David F.
>
> Date: Tue, 7 May 2024 06:50:41 -0400
> From: Rich Brown <richb.hanover@gmail.com>
> To: Eugene Y Chang <eugene.chang@ieee.org>
> Cc: Sebastian Moeller <moeller0@gmx.de>, Colin_Higbie
>         <CHigbie1@Higbie.name>, Dave Taht via Starlink
>         <starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <175CC5C3-F70A-49E8-A84D-87E24C04EABD@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Gene,
>
> > On May 6, 2024, at 8:38 PM, Eugene Y Chang <eugene.chang@ieee.org> wrote:
> >
> > It seems like you signed off on this challenge. Don’t do that. Help give me the tools to push this to the next level.
>
> Not at all - I'm definitely signed up for this. But I collected all these points so we can be clear-eyed about the objections that people cite.
>
> Bufferbloat definitely exists. And there are straightforward technical solutions. And as you say, our challenge is to find a way to build the case for broad adoption of these techniques.
>
> Best regards,
>
> Rich
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240507/ecb7b91e/attachment-0001.html>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
> --
> David Collier-Brown,         | Always do right. This will gratify
> System Programmer and Author | some people and astonish the rest
> dave.collier-brown@indexexchange.com |              -- Mark Twain
>
>
> CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



-- 
https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
Dave Täht CSO, LibreQos

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-07 12:46 ` Dave Collier-Brown
@ 2024-05-07 19:09   ` Eugene Y Chang
  2024-05-07 19:11     ` Dave Taht
  0 siblings, 1 reply; 59+ messages in thread
From: Eugene Y Chang @ 2024-05-07 19:09 UTC (permalink / raw)
  To: Dave Collier-Brown; +Cc: Eugene Y Chang, Dave Taht via Starlink


[-- Attachment #1.1: Type: text/plain, Size: 4957 bytes --]

Dave,
Thank you for calling attention to the RFC. I took a quick peek, and I need to put more time into reading the whole doc. It feels very intuitive.

What I like is that it is written for incremental adoption. I will focus on that in my next pass. It opens the door to be incrementally deployed to pacify an influential squeaky wheel. I like the possibility that a happy squeaky wheel becomes a role model attracting more squeaky wheels until it makes more sense to just adopt broad deployment. If you read my earlier emails, you know I am in the hunt for an influential squeaky wheel. :P

Anticipating more discussion in this direction, are there core router vendors that have a favorable view of  L4S? Are there router implementations just waiting to be turned on?

Gene
----------------------------------------------
Eugene Chang




> On May 7, 2024, at 2:46 AM, Dave Collier-Brown via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> It has an RFC at https://datatracker.ietf.org/doc/rfc9330/ <https://datatracker.ietf.org/doc/rfc9330/>
> 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.
> 
> I suspect My Smarter Colleagues know more (;-))
> 
> --dave
> 
> 
> On 2024-05-07 08:13, David Fernández 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-videojuegos-nokia-vodafone <https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone>
>> 
>> Regards,
>> 
>> David F.
>> 
>> Date: Tue, 7 May 2024 06:50:41 -0400
>> From: Rich Brown <richb.hanover@gmail.com <mailto:richb.hanover@gmail.com>>
>> To: Eugene Y Chang <eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>>
>> Cc: Sebastian Moeller <moeller0@gmx.de <mailto:moeller0@gmx.de>>, Colin_Higbie
>>         <CHigbie1@Higbie.name> <mailto:CHigbie1@Higbie.name>, Dave Taht via Starlink
>>         <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
>> Message-ID: <175CC5C3-F70A-49E8-A84D-87E24C04EABD@gmail.com <mailto:175CC5C3-F70A-49E8-A84D-87E24C04EABD@gmail.com>>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Hi Gene,
>> 
>> > On May 6, 2024, at 8:38 PM, Eugene Y Chang <eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>> wrote:
>> >
>> > It seems like you signed off on this challenge. Don’t do that. Help give me the tools to push this to the next level.
>> 
>> Not at all - I'm definitely signed up for this. But I collected all these points so we can be clear-eyed about the objections that people cite.
>> 
>> Bufferbloat definitely exists. And there are straightforward technical solutions. And as you say, our challenge is to find a way to build the case for broad adoption of these techniques.
>> 
>> Best regards,
>> 
>> Rich
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240507/ecb7b91e/attachment-0001.html <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240507/ecb7b91e/attachment-0001.html>>
>> 
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> --
> David Collier-Brown,         | Always do right. This will gratify
> System Programmer and Author | some people and astonish the rest
> dave.collier-brown@indexexchange.com <mailto:dave.collier-brown@indexexchange.com> |              -- Mark Twain
> 
> CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


[-- Attachment #1.2: Type: text/html, Size: 10734 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-07 12:13 David Fernández
@ 2024-05-07 12:46 ` Dave Collier-Brown
  2024-05-07 19:09   ` Eugene Y Chang
  0 siblings, 1 reply; 59+ messages in thread
From: Dave Collier-Brown @ 2024-05-07 12:46 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 3401 bytes --]

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 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ández 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-videojuegos-nokia-vodafone

Regards,

David F.

Date: Tue, 7 May 2024 06:50:41 -0400
From: Rich Brown <richb.hanover@gmail.com<mailto:richb.hanover@gmail.com>>
To: Eugene Y Chang <eugene.chang@ieee.org<mailto:eugene.chang@ieee.org>>
Cc: Sebastian Moeller <moeller0@gmx.de<mailto:moeller0@gmx.de>>, Colin_Higbie
        <CHigbie1@Higbie.name><mailto:CHigbie1@Higbie.name>, Dave Taht via Starlink
        <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>>
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Message-ID: <175CC5C3-F70A-49E8-A84D-87E24C04EABD@gmail.com<mailto:175CC5C3-F70A-49E8-A84D-87E24C04EABD@gmail.com>>
Content-Type: text/plain; charset="utf-8"

Hi Gene,

> On May 6, 2024, at 8:38 PM, Eugene Y Chang <eugene.chang@ieee.org<mailto:eugene.chang@ieee.org>> wrote:
>
> It seems like you signed off on this challenge. Don’t do that. Help give me the tools to push this to the next level.

Not at all - I'm definitely signed up for this. But I collected all these points so we can be clear-eyed about the objections that people cite.

Bufferbloat definitely exists. And there are straightforward technical solutions. And as you say, our challenge is to find a way to build the case for broad adoption of these techniques.

Best regards,

Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240507/ecb7b91e/attachment-0001.html>



_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net<mailto:Starlink@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink


--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> |              -- Mark Twain


CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

[-- Attachment #2: Type: text/html, Size: 5559 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
@ 2024-05-07 12:13 David Fernández
  2024-05-07 12:46 ` Dave Collier-Brown
  0 siblings, 1 reply; 59+ messages in thread
From: David Fernández @ 2024-05-07 12:13 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

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-videojuegos-nokia-vodafone

Regards,

David F.

Date: Tue, 7 May 2024 06:50:41 -0400
From: Rich Brown <richb.hanover@gmail.com>
To: Eugene Y Chang <eugene.chang@ieee.org>
Cc: Sebastian Moeller <moeller0@gmx.de>, Colin_Higbie
        <CHigbie1@Higbie.name>, Dave Taht via Starlink
        <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Message-ID: <175CC5C3-F70A-49E8-A84D-87E24C04EABD@gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Gene,

> On May 6, 2024, at 8:38 PM, Eugene Y Chang <eugene.chang@ieee.org> wrote:
>
> It seems like you signed off on this challenge. Don’t do that. Help give
me the tools to push this to the next level.

Not at all - I'm definitely signed up for this. But I collected all these
points so we can be clear-eyed about the objections that people cite.

Bufferbloat definitely exists. And there are straightforward technical
solutions. And as you say, our challenge is to find a way to build the case
for broad adoption of these techniques.

Best regards,

Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.bufferbloat.net/pipermail/starlink/attachments/20240507/ecb7b91e/attachment-0001.html>

[-- Attachment #2: Type: text/html, Size: 2403 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-07  0:43                             ` Eugene Y Chang
@ 2024-05-07 12:05                               ` Dave Collier-Brown
  0 siblings, 0 replies; 59+ messages in thread
From: Dave Collier-Brown @ 2024-05-07 12:05 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 12323 bytes --]

Oh goodness, I wasn't suggesting that we had a total solution, I was 
pointing out that the gaming community was missing the point, even with 
evidence in their hands.

That suggests we have not made the point to a technically aware part of 
our community.

--dave

On 2024-05-06 20:43, Eugene Y Chang via Starlink wrote:
> Dave,
> We just can’t represent that we have the total solution.
> We need to show the problem can be reduced.
> We need to show that latency is a significant negative phenomena.
> Take out one contributor and sic the users to the next contributor.
>
> If we expect to solve the whole problem in one step, we end up where 
> we are and effectively say the problem is too complex to solve.
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
> IEEE Communications Society & Signal Processing Society,
>     Hawaii Chapter Chair
> IEEE Life Member Affinity Group Hawaii Chair
> IEEE Entrepreneurship, Mentor
> eugene.chang@ieee.org
> m 781-799-0233 (in Honolulu)
>
>
>
>> On May 6, 2024, at 2:11 AM, Dave Collier-Brown via Starlink 
>> <starlink@lists.bufferbloat.net> wrote:
>>
>> I think that gamer experience doing simple (over-simple) tests with 
>> CAKE is a booby-trap. This discussion suggests that the real 
>> performance of their link is horrid, and that they turn off CAKE to 
>> get what they think is full performance... but isn't.
>>
>> https://www.reddit.com/r/HomeNetworking/comments/174k0ko/low_latency_gaming_and_bufferbloat/#:~:text=If%20there's%20any%20chance%20that,out%20any%20intermittent%20latency%20spikes. 
>>
>>
>>  (I used to work for World Gaming, and follow the game commentators 
>> more that I do now)
>>
>> --dave
>>
>>
>> On 2024-05-06 07:25, Rich Brown via Starlink wrote:
>>> Hi Gene,
>>>
>>> I've been vacillating on whether to send this note, but have decided 
>>> to pull the trigger. I apologize in advance for the "Debbie Downer" 
>>> nature of this message. I also apologize for any errors, omissions, 
>>> or over-simplifications of the "birth of bufferbloat" story and its 
>>> fixes. Corrections welcome.
>>>
>>> Rich
>>> ------
>>>
>>> If we are going to take a shot at opening people's eyes to 
>>> bufferbloat, we should know some of the "objections" we'll run up 
>>> against. Even though there's terrific technical data to back it up, 
>>> people seem especially resistant to thinking that bufferbloat might 
>>> affect their network, even when they're seeing problems that sound 
>>> exactly like bufferbloat symptoms. But first, some history:
>>>
>>> The very idea of bufferbloat is simply unbelievable. Jim Gettys in 
>>> 2011 [1] couldn't believe it, and he's a smart networking guy,. At 
>>> the time, it seemed incredible (that is "not credible" == 
>>> impossible) that something could induce 1.2 seconds of latency into 
>>> his home network connection. He called in favors from technical 
>>> contacts at his ISP and at Bell Labs who went over everything with a 
>>> fine-toothed comb. It was all exactly as spec'd. But he still had 
>>> the latency.
>>>
>>> This led Jim and Dave Täht to start the investigation into the 
>>> phenomenon known today as "bufferbloat" - the undesirable latency 
>>> that comes from a router or other network equipment buffering too 
>>> much data. Over several years, a group of smart people made huge 
>>> improvements: fq_codel was released 14 May 2012 [3]; it was 
>>> incorporated into the Linux kernel shortly afterward. CAKE came in 
>>> 2015, and the fixes that minimize bufferbloat in Wi-Fi arrived in 
>>> 2018. In 2021 cake-autorate [4] arrived to handle varying speed ISP 
>>> links. All these techniques work great: in 2014, my 7mbps DSL link 
>>> was quite usable. And when the pandemic hit, fq_codel on my OpenWrt 
>>> router allowed me to use that same 7mbps DSL line for two 
>>> simultaneous zoom calls.
>>>
>>> As one of the authors of [2], I am part of the team that has tried 
>>> over the years to explain bufferbloat and how to fix it. We've 
>>> spoken with vendors. We've spent untold hours responding to posts on 
>>> assorted boards and forums with the the bufferbloat story.
>>>
>>> With these technical fixes in hand, we cockily set about to tell the 
>>> world about how to fix bufferbloat. Our efforts have been met with 
>>> skepticism at best, or stony silence. What are the objections?
>>>
>>> - This is just the ordinary behavior: I would expect things to be 
>>> slower when there's more traffic (Willfully ignoring orders of 
>>> magnitude increase in delay.)
>>> - Besides, I'm the only one using the internet. (Except when my 
>>> phone uploads photos. Or my computer kicks off some automated 
>>> process. Or I browse the web. Or ...)
>>> - It only happens some of the time. (Exactly. That's probably when 
>>> something's uploading photos, or your computer is doing stuff in the 
>>> background.)
>>> - Those bufferbloat tests you hear about are bogus. They 
>>> artificially add load, which isn't a realistic test. (...and if you 
>>> actually are downloading a file?)
>>> - Bufferbloat only happens when the network is 100% loaded. (True. 
>>> But when you open a web page, your browser briefly uses 100% of the 
>>> link. Is this enough to cause momentary lag?)
>>> - It's OK. I just tell my kids/spouse not to use the internet when 
>>> I'm gaming. (Huh?)
>>> - I have gigabit service from my ISP. (That helps, but if you're 
>>> complaining about "slowness" you still need to rule out bufferbloat 
>>> in your router.)
>>> - I can't believe that router manufacturers would ever allow such a 
>>> thing to happen in their gear. (See the Jim Gettys story above.)
>>> - I mean... wouldn't router vendors want to provide the best for 
>>> their customers? (No - implementing this (new-ish) code requires 
>>> engineering effort. They're selling plenty of routers with 
>>> decade-old software. The Boss says, "would we sell more if they made 
>>> these changes? Probably not.")
>>> - Why would my ISP provision/sell me a router that gave crappy 
>>> service? They're a big company, they must know about this stuff. 
>>> (Maybe. We have reached out to all the vendors. But remember they 
>>> profit if you decide your network is too slow and you upgrade to a 
>>> faster device/plan.)
>>> - But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
>>> - Besides, I just spent $300 on a "gaming router". Obviously, I 
>>> bought the most expensive/best possible solution on the market (But 
>>> I still have lag...)
>>> - You're telling me that a bunch of pointy-headed academics are 
>>> smarter than commercial router developers - who sold me that $300 
>>> router? (I can't believe it.)
>>> - And then you say that I should throw away that gaming router and 
>>> install some "open source firmware"? (What the heck is that? And why 
>>> should I believe you?)
>>> - What if it doesn't solve the problem? Who will give me support? 
>>> And how will I get back to a vendor-supported system? (Valid point - 
>>> the first valid point)
>>> - Aren't there any commercial solutions I can just buy? (Not at the 
>>> moment. IQrouter was a shining light here - available from Amazon, 
>>> simple setup, worked a treat - but they have gone out of business. 
>>> And of course, for the skeptic, this is proof that the 
>>> "fq_codel-stuff" isn't really a solution - it seems just like snake 
>>> oil.)
>>>
>>> So... All these hurdles make it hard to convince people that 
>>> bufferbloat could be the problem, or that they can fix for themselves.
>>>
>>> A couple of us have reached out to Consumer Reports, wondering if 
>>> they would like a story about how vendors would prefer to sell you a 
>>> new, faster router (or new faster ISP plan) than fix your 
>>> bufferbloat. This kind of story seemed to be straight up their 
>>> alley, but we never heard back after an initial contact. Maybe they 
>>> deserve another call...
>>>
>>> The recent latency results from Starlink give me a modicum of hope. 
>>> They're a major player. They (and their customers) can point to an 
>>> order of magnitude reduction in latency over other solutions. It 
>>> still requires enough "regular customers" to tell their current ISP 
>>> that they are switching to Starlink (and spend $600 to purchase a 
>>> Dishy plus $100/month) to provide a market incentive.
>>>
>>> Despite all this doom and gloom, I remain hopeful that things will 
>>> get better. We know the technology exists for people to take control 
>>> of their network and solve the problem for themselves. We can 
>>> continue to respond on forums where people express their dismay at 
>>> the crummy performance and suggest a solution. We can hope that a 
>>> major vendor will twig to this effect and bring out a mass-market 
>>> solution.
>>>
>>> I think your suggestion of speaking to eSports people is intriguing. 
>>> They're highly motivated to make their personal networks better. And 
>>> actually solving the problem would have a network effect of bringing 
>>> in others with the same problem.
>>>
>>> Good luck, and thanks for thinking about this.
>>>
>>> Rich Brown
>>>
>>> [1] 
>>> https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf
>>> [2] 
>>> https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/
>>> [3] 
>>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html
>>> [4] https://github.com/lynxthecat/cake-autorate
>>> [5] 
>>> https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos
>>>
>>>> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink 
>>>> <starlink@lists.bufferbloat.net> wrote:
>>>>
>>>> Of course. For the gamers, the focus is managing latency. They have 
>>>> control of everything else.
>>>>
>>>> With our high latency and wide range of values, the eSports teams 
>>>> train on campus. It will be interesting to see how much 
>>>> improvements there can be for teams to be able to training from 
>>>> their homes.
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>> IEEE Life Senior Member
>>>> IEEE Communications Society & Signal Processing Society,
>>>>     Hawaii Chapter Chair
>>>> IEEE Life Member Affinity Group Hawaii Chair
>>>> IEEE Entrepreneurship, Mentor
>>>> eugene.chang@ieee.org
>>>> m 781-799-0233 (in Honolulu)
>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> -- 
>> David Collier-Brown,         | Always do right. This will gratify
>> System Programmer and Author | some people and astonish the rest
>> dave.collier-brown@indexexchange.com  |              -- Mark Twain
>>
>> */CONFIDENTIALITY NOTICE AND DISCLAIMER/*/ : This telecommunication, 
>> including any and all attachments, contains confidential information 
>> intended only for the person(s) to whom it is addressed. Any 
>> dissemination, distribution, copying or disclosure is strictly 
>> prohibited and is not a waiver of confidentiality. If you have 
>> received this telecommunication in error, please notify the sender 
>> immediately by return electronic mail and delete the message from 
>> your inbox and deleted items folders. This telecommunication does not 
>> constitute an express or implied agreement to conduct transactions by 
>> electronic means, nor does it constitute a contract offer, a contract 
>> amendment or an acceptance of a contract offer. Contract terms 
>> contained in this telecommunication are subject to legal review and 
>> the completion of formal documentation and are not binding until same 
>> is confirmed in writing and has been signed by an authorized signatory./
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com  |              -- Mark Twain

[-- Attachment #2: Type: text/html, Size: 30963 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-07  0:38                           ` Eugene Y Chang
@ 2024-05-07 10:50                             ` Rich Brown
  0 siblings, 0 replies; 59+ messages in thread
From: Rich Brown @ 2024-05-07 10:50 UTC (permalink / raw)
  To: Eugene Y Chang; +Cc: Sebastian Moeller, Colin_Higbie, Dave Taht via Starlink

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

Hi Gene,

> On May 6, 2024, at 8:38 PM, Eugene Y Chang <eugene.chang@ieee.org> wrote:
> 
> It seems like you signed off on this challenge. Don’t do that. Help give me the tools to push this to the next level.

Not at all - I'm definitely signed up for this. But I collected all these points so we can be clear-eyed about the objections that people cite. 

Bufferbloat definitely exists. And there are straightforward technical solutions. And as you say, our challenge is to find a way to build the case for broad adoption of these techniques. 

Best regards,

Rich

[-- Attachment #2: Type: text/html, Size: 1752 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-06 12:11                           ` Dave Collier-Brown
@ 2024-05-07  0:43                             ` Eugene Y Chang
  2024-05-07 12:05                               ` Dave Collier-Brown
  0 siblings, 1 reply; 59+ messages in thread
From: Eugene Y Chang @ 2024-05-07  0:43 UTC (permalink / raw)
  To: Dave Collier-Brown; +Cc: Eugene Y Chang, Dave Taht via Starlink


[-- Attachment #1.1: Type: text/plain, Size: 11854 bytes --]

Dave,
We just can’t represent that we have the total solution.
We need to show the problem can be reduced.
We need to show that latency is a significant negative phenomena.
Take out one contributor and sic the users to the next contributor.

If we expect to solve the whole problem in one step, we end up where we are and effectively say the problem is too complex to solve.


Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
IEEE Communications Society & Signal Processing Society,
    Hawaii Chapter Chair
IEEE Life Member Affinity Group Hawaii Chair
IEEE Entrepreneurship, Mentor
eugene.chang@ieee.org
m 781-799-0233 (in Honolulu)



> On May 6, 2024, at 2:11 AM, Dave Collier-Brown via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> I think that gamer experience doing simple (over-simple) tests with CAKE is a booby-trap. This discussion suggests that the real performance of their link is horrid, and that they turn off CAKE to get what they think is full performance... but isn't.
> 
> https://www.reddit.com/r/HomeNetworking/comments/174k0ko/low_latency_gaming_and_bufferbloat/#:~:text=If%20there's%20any%20chance%20that,out%20any%20intermittent%20latency%20spikes <https://www.reddit.com/r/HomeNetworking/comments/174k0ko/low_latency_gaming_and_bufferbloat/#:~:text=If%20there's%20any%20chance%20that,out%20any%20intermittent%20latency%20spikes>.
>  (I used to work for World Gaming, and follow the game commentators more that I do now)
> 
> --dave
> 
> 
> On 2024-05-06 07:25, Rich Brown via Starlink wrote:
>> Hi Gene,
>> 
>> I've been vacillating on whether to send this note, but have decided to pull the trigger. I apologize in advance for the "Debbie Downer" nature of this message. I also apologize for any errors, omissions, or over-simplifications of the "birth of bufferbloat" story and its fixes. Corrections welcome.
>> 
>> Rich
>> ------
>> 
>> If we are going to take a shot at opening people's eyes to bufferbloat, we should know some of the "objections" we'll run up against. Even though there's terrific technical data to back it up, people seem especially resistant to thinking that bufferbloat might affect their network, even when they're seeing problems that sound exactly like bufferbloat symptoms. But first, some history:
>> 
>> The very idea of bufferbloat is simply unbelievable. Jim Gettys in 2011 [1] couldn't believe it, and he's a smart networking guy,. At the time, it seemed incredible (that is "not credible" == impossible) that something could induce 1.2 seconds of latency into his home network connection. He called in favors from technical contacts at his ISP and at Bell Labs who went over everything with a fine-toothed comb. It was all exactly as spec'd. But he still had the latency.
>> 
>> This led Jim and Dave Täht to start the investigation into the phenomenon known today as "bufferbloat" - the undesirable latency that comes from a router or other network equipment buffering too much data. Over several years, a group of smart people made huge improvements: fq_codel was released 14 May 2012 [3]; it was incorporated into the Linux kernel shortly afterward. CAKE came in 2015, and the fixes that minimize bufferbloat in Wi-Fi arrived in 2018. In 2021 cake-autorate [4] arrived to handle varying speed ISP links. All these techniques work great: in 2014, my 7mbps DSL link was quite usable. And when the pandemic hit, fq_codel on my OpenWrt router allowed me to use that same 7mbps DSL line for two simultaneous zoom calls.
>> 
>> As one of the authors of [2], I am part of the team that has tried over the years to explain bufferbloat and how to fix it. We've spoken with vendors. We've spent untold hours responding to posts on assorted boards and forums with the the bufferbloat story.
>> 
>> With these technical fixes in hand, we cockily set about to tell the world about how to fix bufferbloat. Our efforts have been met with skepticism at best, or stony silence. What are the objections?
>> 
>> - This is just the ordinary behavior: I would expect things to be slower when there's more traffic (Willfully ignoring orders of magnitude increase in delay.)
>> - Besides, I'm the only one using the internet. (Except when my phone uploads photos. Or my computer kicks off some automated process. Or I browse the web. Or ...)
>> - It only happens some of the time. (Exactly. That's probably when something's uploading photos, or your computer is doing stuff in the background.)
>> - Those bufferbloat tests you hear about are bogus. They artificially add load, which isn't a realistic test. (...and if you actually are downloading a file?)
>> - Bufferbloat only happens when the network is 100% loaded. (True. But when you open a web page, your browser briefly uses 100% of the link. Is this enough to cause momentary lag?)
>> - It's OK. I just tell my kids/spouse not to use the internet when I'm gaming. (Huh?)
>> - I have gigabit service from my ISP. (That helps, but if you're complaining about "slowness" you still need to rule out bufferbloat in your router.)
>> - I can't believe that router manufacturers would ever allow such a thing to happen in their gear. (See the Jim Gettys story above.)
>> - I mean... wouldn't router vendors want to provide the best for their customers? (No - implementing this (new-ish) code requires engineering effort. They're selling plenty of routers with decade-old software. The Boss says, "would we sell more if they made these changes? Probably not.")
>> - Why would my ISP provision/sell me a router that gave crappy service? They're a big company, they must know about this stuff. (Maybe. We have reached out to all the vendors. But remember they profit if you decide your network is too slow and you upgrade to a faster device/plan.)
>> - But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
>> - Besides, I just spent $300 on a "gaming router". Obviously, I bought the most expensive/best possible solution on the market (But I still have lag...)
>> - You're telling me that a bunch of pointy-headed academics are smarter than commercial router developers - who sold me that $300 router? (I can't believe it.)
>> - And then you say that I should throw away that gaming router and install some "open source firmware"? (What the heck is that? And why should I believe you?)
>> - What if it doesn't solve the problem? Who will give me support? And how will I get back to a vendor-supported system? (Valid point - the first valid point)
>> - Aren't there any commercial solutions I can just buy? (Not at the moment. IQrouter was a shining light here - available from Amazon, simple setup, worked a treat - but they have gone out of business. And of course, for the skeptic, this is proof that the "fq_codel-stuff" isn't really a solution - it seems just like snake oil.)
>> 
>> So... All these hurdles make it hard to convince people that bufferbloat could be the problem, or that they can fix for themselves.
>> 
>> A couple of us have reached out to Consumer Reports, wondering if they would like a story about how vendors would prefer to sell you a new, faster router (or new faster ISP plan) than fix your bufferbloat. This kind of story seemed to be straight up their alley, but we never heard back after an initial contact. Maybe they deserve another call...
>> 
>> The recent latency results from Starlink give me a modicum of hope. They're a major player. They (and their customers) can point to an order of magnitude reduction in latency over other solutions. It still requires enough "regular customers" to tell their current ISP that they are switching to Starlink (and spend $600 to purchase a Dishy plus $100/month) to provide a market incentive.
>> 
>> Despite all this doom and gloom, I remain hopeful that things will get better. We know the technology exists for people to take control of their network and solve the problem for themselves. We can continue to respond on forums where people express their dismay at the crummy performance and suggest a solution. We can hope that a major vendor will twig to this effect and bring out a mass-market solution.
>> 
>> I think your suggestion of speaking to eSports people is intriguing. They're highly motivated to make their personal networks better. And actually solving the problem would have a network effect of bringing in others with the same problem.
>> 
>> Good luck, and thanks for thinking about this.
>> 
>> Rich Brown
>> 
>> [1] https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf <https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf>[2] https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/ <https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/>
>> [3] https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html <https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html>
>> [4] https://github.com/lynxthecat/cake-autorate <https://github.com/lynxthecat/cake-autorate>
>> [5] https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos <https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos>
>> 
>>> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>> 
>>> Of course. For the gamers, the focus is managing latency. They have control of everything else.
>>> 
>>> With our high latency and wide range of values, the eSports teams train on campus. It will be interesting to see how much improvements there can be for teams to be able to training from their homes.
>>> 
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>> IEEE Communications Society & Signal Processing Society,
>>>     Hawaii Chapter Chair
>>> IEEE Life Member Affinity Group Hawaii Chair
>>> IEEE Entrepreneurship, Mentor
>>> eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>
>>> m 781-799-0233 (in Honolulu)
>> 
>> 
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> --
> David Collier-Brown,         | Always do right. This will gratify
> System Programmer and Author | some people and astonish the rest
> dave.collier-brown@indexexchange.com <mailto:dave.collier-brown@indexexchange.com> |              -- Mark Twain
> 
> CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


[-- Attachment #1.2: Type: text/html, Size: 21312 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-06 11:25                         ` [Starlink] The "reasons" that bufferbloat isn't a problem Rich Brown
  2024-05-06 12:11                           ` Dave Collier-Brown
       [not found]                           ` <CAJUtOOhH3oPDCyo=mk=kwzm5DiFp7OZPiFu+0MzajTQqps==_g@mail.gmail.com>
@ 2024-05-07  0:38                           ` Eugene Y Chang
  2024-05-07 10:50                             ` Rich Brown
  2024-05-08  1:48                           ` Dave Taht
  3 siblings, 1 reply; 59+ messages in thread
From: Eugene Y Chang @ 2024-05-07  0:38 UTC (permalink / raw)
  To: Rich Brown
  Cc: Eugene Y Chang, Sebastian Moeller, Colin_Higbie, Dave Taht via Starlink


[-- Attachment #1.1: Type: text/plain, Size: 9734 bytes --]

Rich,
Thanks for the recap in the email.
I have seen all of those bits.

I will help with the marketing magic needed.
We need a team of smart people engaged to help vouch for the technical integrity.

We need a simple case (call it a special case, if you must) that shows the problem can be fixed.
Never mind if it is not a universal fix.
We only need to show one happy, very visible community.
Give me something to work with that we can defend from the list of do-nothing reasons you list.

It seems like you signed off on this challenge. Don’t do that. Help give me the tools to push this to the next level.
An energetic, vocal community is very valuable. They aren’t satisfying if we want to debate the technology. We shouldn’t care. We just want to win adoption.

Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
IEEE Communications Society & Signal Processing Society,
    Hawaii Chapter Chair
IEEE Life Member Affinity Group Hawaii Chair
IEEE Entrepreneurship, Mentor
eugene.chang@ieee.org
m 781-799-0233 (in Honolulu)



> On May 6, 2024, at 1:25 AM, Rich Brown <richb.hanover@gmail.com> wrote:
> 
> Hi Gene,
> 
> I've been vacillating on whether to send this note, but have decided to pull the trigger. I apologize in advance for the "Debbie Downer" nature of this message. I also apologize for any errors, omissions, or over-simplifications of the "birth of bufferbloat" story and its fixes. Corrections welcome.
> 
> Rich
> ------
> 
> If we are going to take a shot at opening people's eyes to bufferbloat, we should know some of the "objections" we'll run up against. Even though there's terrific technical data to back it up, people seem especially resistant to thinking that bufferbloat might affect their network, even when they're seeing problems that sound exactly like bufferbloat symptoms. But first, some history:
> 
> The very idea of bufferbloat is simply unbelievable. Jim Gettys in 2011 [1] couldn't believe it, and he's a smart networking guy,. At the time, it seemed incredible (that is "not credible" == impossible) that something could induce 1.2 seconds of latency into his home network connection. He called in favors from technical contacts at his ISP and at Bell Labs who went over everything with a fine-toothed comb. It was all exactly as spec'd. But he still had the latency.
> 
> This led Jim and Dave Täht to start the investigation into the phenomenon known today as "bufferbloat" - the undesirable latency that comes from a router or other network equipment buffering too much data. Over several years, a group of smart people made huge improvements: fq_codel was released 14 May 2012 [3]; it was incorporated into the Linux kernel shortly afterward. CAKE came in 2015, and the fixes that minimize bufferbloat in Wi-Fi arrived in 2018. In 2021 cake-autorate [4] arrived to handle varying speed ISP links. All these techniques work great: in 2014, my 7mbps DSL link was quite usable. And when the pandemic hit, fq_codel on my OpenWrt router allowed me to use that same 7mbps DSL line for two simultaneous zoom calls.
> 
> As one of the authors of [2], I am part of the team that has tried over the years to explain bufferbloat and how to fix it. We've spoken with vendors. We've spent untold hours responding to posts on assorted boards and forums with the the bufferbloat story.
> 
> With these technical fixes in hand, we cockily set about to tell the world about how to fix bufferbloat. Our efforts have been met with skepticism at best, or stony silence. What are the objections?
> 
> - This is just the ordinary behavior: I would expect things to be slower when there's more traffic (Willfully ignoring orders of magnitude increase in delay.)
> - Besides, I'm the only one using the internet. (Except when my phone uploads photos. Or my computer kicks off some automated process. Or I browse the web. Or ...)
> - It only happens some of the time. (Exactly. That's probably when something's uploading photos, or your computer is doing stuff in the background.)
> - Those bufferbloat tests you hear about are bogus. They artificially add load, which isn't a realistic test. (...and if you actually are downloading a file?)
> - Bufferbloat only happens when the network is 100% loaded. (True. But when you open a web page, your browser briefly uses 100% of the link. Is this enough to cause momentary lag?)
> - It's OK. I just tell my kids/spouse not to use the internet when I'm gaming. (Huh?)
> - I have gigabit service from my ISP. (That helps, but if you're complaining about "slowness" you still need to rule out bufferbloat in your router.)
> - I can't believe that router manufacturers would ever allow such a thing to happen in their gear. (See the Jim Gettys story above.)
> - I mean... wouldn't router vendors want to provide the best for their customers? (No - implementing this (new-ish) code requires engineering effort. They're selling plenty of routers with decade-old software. The Boss says, "would we sell more if they made these changes? Probably not.")
> - Why would my ISP provision/sell me a router that gave crappy service? They're a big company, they must know about this stuff. (Maybe. We have reached out to all the vendors. But remember they profit if you decide your network is too slow and you upgrade to a faster device/plan.)
> - But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
> - Besides, I just spent $300 on a "gaming router". Obviously, I bought the most expensive/best possible solution on the market (But I still have lag...)
> - You're telling me that a bunch of pointy-headed academics are smarter than commercial router developers - who sold me that $300 router? (I can't believe it.)
> - And then you say that I should throw away that gaming router and install some "open source firmware"? (What the heck is that? And why should I believe you?)
> - What if it doesn't solve the problem? Who will give me support? And how will I get back to a vendor-supported system? (Valid point - the first valid point)
> - Aren't there any commercial solutions I can just buy? (Not at the moment. IQrouter was a shining light here - available from Amazon, simple setup, worked a treat - but they have gone out of business. And of course, for the skeptic, this is proof that the "fq_codel-stuff" isn't really a solution - it seems just like snake oil.)
> 
> So... All these hurdles make it hard to convince people that bufferbloat could be the problem, or that they can fix for themselves.
> 
> A couple of us have reached out to Consumer Reports, wondering if they would like a story about how vendors would prefer to sell you a new, faster router (or new faster ISP plan) than fix your bufferbloat. This kind of story seemed to be straight up their alley, but we never heard back after an initial contact. Maybe they deserve another call...
> 
> The recent latency results from Starlink give me a modicum of hope. They're a major player. They (and their customers) can point to an order of magnitude reduction in latency over other solutions. It still requires enough "regular customers" to tell their current ISP that they are switching to Starlink (and spend $600 to purchase a Dishy plus $100/month) to provide a market incentive.
> 
> Despite all this doom and gloom, I remain hopeful that things will get better. We know the technology exists for people to take control of their network and solve the problem for themselves. We can continue to respond on forums where people express their dismay at the crummy performance and suggest a solution. We can hope that a major vendor will twig to this effect and bring out a mass-market solution.
> 
> I think your suggestion of speaking to eSports people is intriguing. They're highly motivated to make their personal networks better. And actually solving the problem would have a network effect of bringing in others with the same problem.
> 
> Good luck, and thanks for thinking about this.
> 
> Rich Brown
> 
> [1] https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf <https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf>[2] https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/ <https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/>
> [3] https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html <https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html>
> [4] https://github.com/lynxthecat/cake-autorate <https://github.com/lynxthecat/cake-autorate>
> [5] https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos <https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos>
> 
>> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> 
>> Of course. For the gamers, the focus is managing latency. They have control of everything else.
>> 
>> With our high latency and wide range of values, the eSports teams train on campus. It will be interesting to see how much improvements there can be for teams to be able to training from their homes.
>> 
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>> IEEE Communications Society & Signal Processing Society,
>>     Hawaii Chapter Chair
>> IEEE Life Member Affinity Group Hawaii Chair
>> IEEE Entrepreneurship, Mentor
>> eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>
>> m 781-799-0233 (in Honolulu)
> 


[-- Attachment #1.2: Type: text/html, Size: 18149 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
       [not found]                           ` <CAJUtOOhH3oPDCyo=mk=kwzm5DiFp7OZPiFu+0MzajTQqps==_g@mail.gmail.com>
@ 2024-05-06 19:47                             ` Rich Brown
  0 siblings, 0 replies; 59+ messages in thread
From: Rich Brown @ 2024-05-06 19:47 UTC (permalink / raw)
  To: Dave Taht via Starlink, bloat

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

Thanks! I just posted to: https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/ 

It has mild edits from the original to address a broader audience. Also posted to the bloat list.

Rich

> On May 6, 2024, at 3:05 PM, Frantisek Borsik <frantisek.borsik@gmail.com> wrote:
> 
> Hey Rich,
> 
> This was really great trip down the memory lane.
> 
> Could you please publish it somewhere, like on your blog?
> 
> Would be great to share it with the world!
> 
> Greetings from Prague.
> 
> All the best,
> 
> Frank
> 
> Frantisek (Frank) Borsik
> 


[-- Attachment #2: Type: text/html, Size: 2251 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-06 11:25                         ` [Starlink] The "reasons" that bufferbloat isn't a problem Rich Brown
@ 2024-05-06 12:11                           ` Dave Collier-Brown
  2024-05-07  0:43                             ` Eugene Y Chang
       [not found]                           ` <CAJUtOOhH3oPDCyo=mk=kwzm5DiFp7OZPiFu+0MzajTQqps==_g@mail.gmail.com>
                                             ` (2 subsequent siblings)
  3 siblings, 1 reply; 59+ messages in thread
From: Dave Collier-Brown @ 2024-05-06 12:11 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 9979 bytes --]

I think that gamer experience doing simple (over-simple) tests with CAKE is a booby-trap. This discussion suggests that the real performance of their link is horrid, and that they turn off CAKE to get what they think is full performance... but isn't.

https://www.reddit.com/r/HomeNetworking/comments/174k0ko/low_latency_gaming_and_bufferbloat/#:~:text=If%20there's%20any%20chance%20that,out%20any%20intermittent%20latency%20spikes.

 (I used to work for World Gaming, and follow the game commentators more that I do now)

--dave

On 2024-05-06 07:25, Rich Brown via Starlink wrote:
Hi Gene,

I've been vacillating on whether to send this note, but have decided to pull the trigger. I apologize in advance for the "Debbie Downer" nature of this message. I also apologize for any errors, omissions, or over-simplifications of the "birth of bufferbloat" story and its fixes. Corrections welcome.

Rich
------

If we are going to take a shot at opening people's eyes to bufferbloat, we should know some of the "objections" we'll run up against. Even though there's terrific technical data to back it up, people seem especially resistant to thinking that bufferbloat might affect their network, even when they're seeing problems that sound exactly like bufferbloat symptoms. But first, some history:

The very idea of bufferbloat is simply unbelievable. Jim Gettys in 2011 [1] couldn't believe it, and he's a smart networking guy,. At the time, it seemed incredible (that is "not credible" == impossible) that something could induce 1.2 seconds of latency into his home network connection. He called in favors from technical contacts at his ISP and at Bell Labs who went over everything with a fine-toothed comb. It was all exactly as spec'd. But he still had the latency.

This led Jim and Dave Täht to start the investigation into the phenomenon known today as "bufferbloat" - the undesirable latency that comes from a router or other network equipment buffering too much data. Over several years, a group of smart people made huge improvements: fq_codel was released 14 May 2012 [3]; it was incorporated into the Linux kernel shortly afterward. CAKE came in 2015, and the fixes that minimize bufferbloat in Wi-Fi arrived in 2018. In 2021 cake-autorate [4] arrived to handle varying speed ISP links. All these techniques work great: in 2014, my 7mbps DSL link was quite usable. And when the pandemic hit, fq_codel on my OpenWrt router allowed me to use that same 7mbps DSL line for two simultaneous zoom calls.

As one of the authors of [2], I am part of the team that has tried over the years to explain bufferbloat and how to fix it. We've spoken with vendors. We've spent untold hours responding to posts on assorted boards and forums with the the bufferbloat story.

With these technical fixes in hand, we cockily set about to tell the world about how to fix bufferbloat. Our efforts have been met with skepticism at best, or stony silence. What are the objections?

- This is just the ordinary behavior: I would expect things to be slower when there's more traffic (Willfully ignoring orders of magnitude increase in delay.)
- Besides, I'm the only one using the internet. (Except when my phone uploads photos. Or my computer kicks off some automated process. Or I browse the web. Or ...)
- It only happens some of the time. (Exactly. That's probably when something's uploading photos, or your computer is doing stuff in the background.)
- Those bufferbloat tests you hear about are bogus. They artificially add load, which isn't a realistic test. (...and if you actually are downloading a file?)
- Bufferbloat only happens when the network is 100% loaded. (True. But when you open a web page, your browser briefly uses 100% of the link. Is this enough to cause momentary lag?)
- It's OK. I just tell my kids/spouse not to use the internet when I'm gaming. (Huh?)
- I have gigabit service from my ISP. (That helps, but if you're complaining about "slowness" you still need to rule out bufferbloat in your router.)
- I can't believe that router manufacturers would ever allow such a thing to happen in their gear. (See the Jim Gettys story above.)
- I mean... wouldn't router vendors want to provide the best for their customers? (No - implementing this (new-ish) code requires engineering effort. They're selling plenty of routers with decade-old software. The Boss says, "would we sell more if they made these changes? Probably not.")
- Why would my ISP provision/sell me a router that gave crappy service? They're a big company, they must know about this stuff. (Maybe. We have reached out to all the vendors. But remember they profit if you decide your network is too slow and you upgrade to a faster device/plan.)
- But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
- Besides, I just spent $300 on a "gaming router". Obviously, I bought the most expensive/best possible solution on the market (But I still have lag...)
- You're telling me that a bunch of pointy-headed academics are smarter than commercial router developers - who sold me that $300 router? (I can't believe it.)
- And then you say that I should throw away that gaming router and install some "open source firmware"? (What the heck is that? And why should I believe you?)
- What if it doesn't solve the problem? Who will give me support? And how will I get back to a vendor-supported system? (Valid point - the first valid point)
- Aren't there any commercial solutions I can just buy? (Not at the moment. IQrouter was a shining light here - available from Amazon, simple setup, worked a treat - but they have gone out of business. And of course, for the skeptic, this is proof that the "fq_codel-stuff" isn't really a solution - it seems just like snake oil.)

So... All these hurdles make it hard to convince people that bufferbloat could be the problem, or that they can fix for themselves.

A couple of us have reached out to Consumer Reports, wondering if they would like a story about how vendors would prefer to sell you a new, faster router (or new faster ISP plan) than fix your bufferbloat. This kind of story seemed to be straight up their alley, but we never heard back after an initial contact. Maybe they deserve another call...

The recent latency results from Starlink give me a modicum of hope. They're a major player. They (and their customers) can point to an order of magnitude reduction in latency over other solutions. It still requires enough "regular customers" to tell their current ISP that they are switching to Starlink (and spend $600 to purchase a Dishy plus $100/month) to provide a market incentive.

Despite all this doom and gloom, I remain hopeful that things will get better. We know the technology exists for people to take control of their network and solve the problem for themselves. We can continue to respond on forums where people express their dismay at the crummy performance and suggest a solution. We can hope that a major vendor will twig to this effect and bring out a mass-market solution.

I think your suggestion of speaking to eSports people is intriguing. They're highly motivated to make their personal networks better. And actually solving the problem would have a network effect of bringing in others with the same problem.

Good luck, and thanks for thinking about this.

Rich Brown

[1] https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf
[2] https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/
[3] https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html
[4] https://github.com/lynxthecat/cake-autorate
[5] https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos

On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>> wrote:

Of course. For the gamers, the focus is managing latency. They have control of everything else.

With our high latency and wide range of values, the eSports teams train on campus. It will be interesting to see how much improvements there can be for teams to be able to training from their homes.

Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
IEEE Communications Society & Signal Processing Society,
    Hawaii Chapter Chair
IEEE Life Member Affinity Group Hawaii Chair
IEEE Entrepreneurship, Mentor
eugene.chang@ieee.org<mailto:eugene.chang@ieee.org>
m 781-799-0233 (in Honolulu)




_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net<mailto:Starlink@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink


--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> |              -- Mark Twain


CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

[-- Attachment #2: Type: text/html, Size: 16537 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

* [Starlink] The "reasons" that bufferbloat isn't a problem
  2024-05-01 22:19                       ` Eugene Y Chang
@ 2024-05-06 11:25                         ` Rich Brown
  2024-05-06 12:11                           ` Dave Collier-Brown
                                             ` (3 more replies)
  0 siblings, 4 replies; 59+ messages in thread
From: Rich Brown @ 2024-05-06 11:25 UTC (permalink / raw)
  To: Sebastian Moeller, Colin_Higbie, Dave Taht via Starlink, Eugene Y Chang

[-- Attachment #1: Type: text/plain, Size: 7999 bytes --]

Hi Gene,

I've been vacillating on whether to send this note, but have decided to pull the trigger. I apologize in advance for the "Debbie Downer" nature of this message. I also apologize for any errors, omissions, or over-simplifications of the "birth of bufferbloat" story and its fixes. Corrections welcome.

Rich
------

If we are going to take a shot at opening people's eyes to bufferbloat, we should know some of the "objections" we'll run up against. Even though there's terrific technical data to back it up, people seem especially resistant to thinking that bufferbloat might affect their network, even when they're seeing problems that sound exactly like bufferbloat symptoms. But first, some history:

The very idea of bufferbloat is simply unbelievable. Jim Gettys in 2011 [1] couldn't believe it, and he's a smart networking guy,. At the time, it seemed incredible (that is "not credible" == impossible) that something could induce 1.2 seconds of latency into his home network connection. He called in favors from technical contacts at his ISP and at Bell Labs who went over everything with a fine-toothed comb. It was all exactly as spec'd. But he still had the latency. 

This led Jim and Dave Täht to start the investigation into the phenomenon known today as "bufferbloat" - the undesirable latency that comes from a router or other network equipment buffering too much data. Over several years, a group of smart people made huge improvements: fq_codel was released 14 May 2012 [3]; it was incorporated into the Linux kernel shortly afterward. CAKE came in 2015, and the fixes that minimize bufferbloat in Wi-Fi arrived in 2018. In 2021 cake-autorate [4] arrived to handle varying speed ISP links. All these techniques work great: in 2014, my 7mbps DSL link was quite usable. And when the pandemic hit, fq_codel on my OpenWrt router allowed me to use that same 7mbps DSL line for two simultaneous zoom calls. 

As one of the authors of [2], I am part of the team that has tried over the years to explain bufferbloat and how to fix it. We've spoken with vendors. We've spent untold hours responding to posts on assorted boards and forums with the the bufferbloat story. 

With these technical fixes in hand, we cockily set about to tell the world about how to fix bufferbloat. Our efforts have been met with skepticism at best, or stony silence. What are the objections? 

- This is just the ordinary behavior: I would expect things to be slower when there's more traffic (Willfully ignoring orders of magnitude increase in delay.)
- Besides, I'm the only one using the internet. (Except when my phone uploads photos. Or my computer kicks off some automated process. Or I browse the web. Or ...)
- It only happens some of the time. (Exactly. That's probably when something's uploading photos, or your computer is doing stuff in the background.)
- Those bufferbloat tests you hear about are bogus. They artificially add load, which isn't a realistic test. (...and if you actually are downloading a file?)
- Bufferbloat only happens when the network is 100% loaded. (True. But when you open a web page, your browser briefly uses 100% of the link. Is this enough to cause momentary lag?)
- It's OK. I just tell my kids/spouse not to use the internet when I'm gaming. (Huh?)
- I have gigabit service from my ISP. (That helps, but if you're complaining about "slowness" you still need to rule out bufferbloat in your router.)
- I can't believe that router manufacturers would ever allow such a thing to happen in their gear. (See the Jim Gettys story above.)
- I mean... wouldn't router vendors want to provide the best for their customers? (No - implementing this (new-ish) code requires engineering effort. They're selling plenty of routers with decade-old software. The Boss says, "would we sell more if they made these changes? Probably not.")
- Why would my ISP provision/sell me a router that gave crappy service? They're a big company, they must know about this stuff. (Maybe. We have reached out to all the vendors. But remember they profit if you decide your network is too slow and you upgrade to a faster device/plan.)
- But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
- Besides, I just spent $300 on a "gaming router". Obviously, I bought the most expensive/best possible solution on the market (But I still have lag...)
- You're telling me that a bunch of pointy-headed academics are smarter than commercial router developers - who sold me that $300 router? (I can't believe it.)
- And then you say that I should throw away that gaming router and install some "open source firmware"? (What the heck is that? And why should I believe you?) 
- What if it doesn't solve the problem? Who will give me support? And how will I get back to a vendor-supported system? (Valid point - the first valid point)
- Aren't there any commercial solutions I can just buy? (Not at the moment. IQrouter was a shining light here - available from Amazon, simple setup, worked a treat - but they have gone out of business. And of course, for the skeptic, this is proof that the "fq_codel-stuff" isn't really a solution - it seems just like snake oil.)

So... All these hurdles make it hard to convince people that bufferbloat could be the problem, or that they can fix for themselves.

A couple of us have reached out to Consumer Reports, wondering if they would like a story about how vendors would prefer to sell you a new, faster router (or new faster ISP plan) than fix your bufferbloat. This kind of story seemed to be straight up their alley, but we never heard back after an initial contact. Maybe they deserve another call...

The recent latency results from Starlink give me a modicum of hope. They're a major player. They (and their customers) can point to an order of magnitude reduction in latency over other solutions. It still requires enough "regular customers" to tell their current ISP that they are switching to Starlink (and spend $600 to purchase a Dishy plus $100/month) to provide a market incentive.

Despite all this doom and gloom, I remain hopeful that things will get better. We know the technology exists for people to take control of their network and solve the problem for themselves. We can continue to respond on forums where people express their dismay at the crummy performance and suggest a solution. We can hope that a major vendor will twig to this effect and bring out a mass-market solution.

I think your suggestion of speaking to eSports people is intriguing. They're highly motivated to make their personal networks better. And actually solving the problem would have a network effect of bringing in others with the same problem. 

Good luck, and thanks for thinking about this.

Rich Brown

[1] https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.pdf
[2] https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/
[3] https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html
[4] https://github.com/lynxthecat/cake-autorate
[5] https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos

> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Of course. For the gamers, the focus is managing latency. They have control of everything else.
> 
> With our high latency and wide range of values, the eSports teams train on campus. It will be interesting to see how much improvements there can be for teams to be able to training from their homes.
> 
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
> IEEE Communications Society & Signal Processing Society,    
>     Hawaii Chapter Chair
> IEEE Life Member Affinity Group Hawaii Chair
> IEEE Entrepreneurship, Mentor
> eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>
> m 781-799-0233 (in Honolulu)


[-- Attachment #2: Type: text/html, Size: 13195 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread

end of thread, other threads:[~2024-06-08  1:53 UTC | newest]

Thread overview: 59+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-05 15:16 [Starlink] The "reasons" that bufferbloat isn't a problem David Fernández
2024-06-05 15:21 ` Bless, Roland (TM)
2024-06-05 15:32   ` David Fernández
2024-06-05 16:24   ` Sebastian Moeller
2024-06-06 23:10     ` Michael Richardson
2024-06-07  1:39       ` David Lang
2024-06-07  6:20       ` Sebastian Moeller
2024-06-07 17:41         ` Eugene Y Chang
2024-06-07 17:51           ` David Lang
2024-06-07 20:09             ` Eugene Y Chang
2024-06-08  1:53               ` David Lang
2024-06-05 16:23 ` Sebastian Moeller
2024-06-06  7:07   ` David Fernández
2024-06-06  7:41     ` Sebastian Moeller
  -- strict thread matches above, loose matches on Subject: below --
2024-06-07  7:36 David Fernández
2024-06-05 14:46 David Fernández
2024-06-05 14:57 ` Vint Cerf
2024-06-06 17:12   ` Michael Richardson
2024-06-06 10:18 ` Alexandre Petrescu
2024-06-06 10:37   ` Aidan Van Dyk
2024-06-06 10:33 ` Alexandre Petrescu
2024-05-08  9:31 David Fernández
2024-05-07 12:13 David Fernández
2024-05-07 12:46 ` Dave Collier-Brown
2024-05-07 19:09   ` Eugene Y Chang
2024-05-07 19:11     ` Dave Taht
2024-05-07 19:14       ` Jeremy Austin
2024-05-07 19:46         ` Dave Taht
2024-05-07 20:03           ` Eugene Y Chang
2024-05-07 20:05             ` Frantisek Borsik
2024-05-07 20:25               ` Eugene Y Chang
     [not found] <mailman.2773.1714488060.1074.starlink@lists.bufferbloat.net>
2024-04-30 18:05 ` [Starlink] It’s the Latency, FCC Colin_Higbie
2024-04-30 19:04   ` Eugene Y Chang
2024-05-01  0:36     ` David Lang
2024-05-01  1:30       ` [Starlink] Itʼs " Eugene Y Chang
2024-05-01  1:52         ` Jim Forster
2024-05-01  3:59           ` Eugene Y Chang
2024-05-01  4:12             ` David Lang
2024-05-01 18:51               ` Eugene Y Chang
2024-05-01 19:18                 ` David Lang
2024-05-01 21:12                   ` Eugene Y Chang
2024-05-01 21:27                     ` Sebastian Moeller
2024-05-01 22:19                       ` Eugene Y Chang
2024-05-06 11:25                         ` [Starlink] The "reasons" that bufferbloat isn't a problem Rich Brown
2024-05-06 12:11                           ` Dave Collier-Brown
2024-05-07  0:43                             ` Eugene Y Chang
2024-05-07 12:05                               ` Dave Collier-Brown
     [not found]                           ` <CAJUtOOhH3oPDCyo=mk=kwzm5DiFp7OZPiFu+0MzajTQqps==_g@mail.gmail.com>
2024-05-06 19:47                             ` Rich Brown
2024-05-07  0:38                           ` Eugene Y Chang
2024-05-07 10:50                             ` Rich Brown
2024-05-08  1:48                           ` Dave Taht
2024-05-08  7:58                             ` Frantisek Borsik
2024-05-08  8:01                               ` Frantisek Borsik
2024-05-08 18:29                             ` Eugene Y Chang
2024-06-04 18:19                             ` Stuart Cheshire
2024-06-04 20:06                               ` Sauli Kiviranta
2024-06-04 20:58                                 ` Eugene Y Chang
2024-06-05 11:36                                   ` Alexandre Petrescu
2024-06-05 13:08                                     ` Aidan Van Dyk
2024-06-05 13:28                                       ` Alexandre Petrescu
2024-06-05 13:40                                         ` Gert Doering
2024-06-05 13:43                                           ` Alexandre Petrescu
2024-06-05 14:16                                             ` David Lang
2024-06-05 15:10                                               ` Sebastian Moeller
2024-06-05 16:21                                           ` Alexandre Petrescu
2024-06-05 19:17                                     ` Eugene Y Chang
2024-06-04 23:03                               ` Rich Brown
2024-06-06 17:51                                 ` Stuart Cheshire
2024-06-07  2:28                                   ` Dave Taht
2024-06-07  5:36                                     ` Sebastian Moeller
2024-06-07  7:51                                       ` Gert Doering

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox