[Starlink] Network quality for rocket scientists

[Starlink] Network quality for rocket scientists

[Bjørn Ivar Teigen]

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

Hi everyone,

I was inspired by the latest Starship presentation to write a piece on
network quality in the language of rocket science. The blog can be found
here:
https://www.domos.no/news-updates/network-quality-for-rocket-scientists

Cheers,
Bjørn Ivar Teigen

-- 
Bjørn Ivar Teigen
Head of Research
+47 47335952 | bjorn@domos.no <name@domos.no> | www.domos.no
WiFi Slicing by Domos

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

Re: [Starlink] Network quality for rocket scientists

[Dave Taht]

It is wonderful to see another take on this subject from another perspective!

Only nit is at the conclusion... the benefits of applying fair queuing
to level out apparent jitter is well demonstrated at this point, for
most kinds of traffic. Wish you'd mentioned it.


On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <bjorn@domos.no> wrote:
>
> Hi everyone,
>
> I was inspired by the latest Starship presentation to write a piece on network quality in the language of rocket science. The blog can be found here: https://www.domos.no/news-updates/network-quality-for-rocket-scientists
>
> Cheers,
> Bjørn Ivar Teigen
>
> --
> Bjørn Ivar Teigen
> Head of Research
> +47 47335952 | bjorn@domos.no | www.domos.no
> WiFi Slicing by Domos
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

Re: [Starlink] Network quality for rocket scientists

[Bjørn Ivar Teigen]

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

Thanks Dave, appreciate the feedback!

Sorry to not mention fair queuing explicitly here (I did link people to
bufferbloat.net though! Don't know if that makes up for it).
I agree it solves the bulk of these problems.

/Bjørn Ivar

On Mon, 14 Feb 2022 at 15:30, Dave Taht <dave.taht@gmail.com> wrote:

> It is wonderful to see another take on this subject from another
> perspective!
>
> Only nit is at the conclusion... the benefits of applying fair queuing
> to level out apparent jitter is well demonstrated at this point, for
> most kinds of traffic. Wish you'd mentioned it.
>
>
> On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <bjorn@domos.no> wrote:
> >
> > Hi everyone,
> >
> > I was inspired by the latest Starship presentation to write a piece on
> network quality in the language of rocket science. The blog can be found
> here:
> https://www.domos.no/news-updates/network-quality-for-rocket-scientists
> >
> > Cheers,
> > Bjørn Ivar Teigen
> >
> > --
> > Bjørn Ivar Teigen
> > Head of Research
> > +47 47335952 | bjorn@domos.no | www.domos.no
> > WiFi Slicing by Domos
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>
>
>
> --
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>
> Dave Täht CEO, TekLibre, LLC
>


-- 
Bjørn Ivar Teigen
Head of Research
+47 47335952 | bjorn@domos.no <name@domos.no> | www.domos.no
WiFi Slicing by Domos

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

Re: [Starlink] Network quality for rocket scientists

[Sebastian Moeller]

Hi Dave,


> On Feb 14, 2022, at 16:30, Dave Taht <dave.taht@gmail.com> wrote:
> 
> It is wonderful to see another take on this subject from another perspective!


"See the problem? Buffers produce jitter!"


I would rephrase that as "over-sized and under-managed" buffers increase jitter unduly. Interestingly, bound jitter can be converted into static latency by using, wait for it, (delay) buffers and a scheduler.



> 
> Only nit is at the conclusion... the benefits of applying fair queuing
> to level out apparent jitter is well demonstrated at this point, for
> most kinds of traffic. Wish you'd mentioned it.

	I rather wish low latency DOCSIS (LLD) aka L4S's primary driver/use-case would not have been mentioned before it has been properly tested and confirmed delivering on its promises. Because most of what L4S offers/mandates for jitter reduction is "hopes and prayers", aka end-points are supposed to behave well... in fairness LLD at least has a poor man's FQ on board in the guise of "queue protection" (with by default like 32 "buckets")... some of the cost of FQ with only few of its benefits...

Regards
	Sebastian



> 
> 
> On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <bjorn@domos.no> wrote:
>> 
>> Hi everyone,
>> 
>> I was inspired by the latest Starship presentation to write a piece on network quality in the language of rocket science. The blog can be found here: https://www.domos.no/news-updates/network-quality-for-rocket-scientists
>> 
>> Cheers,
>> Bjørn Ivar Teigen
>> 
>> --
>> Bjørn Ivar Teigen
>> Head of Research
>> +47 47335952 | bjorn@domos.no | www.domos.no
>> WiFi Slicing by Domos
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
> 
> 
> 
> -- 
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> 
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Network quality for rocket scientists

[Bjørn Ivar Teigen]

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

Hi Sebastian, thank you for the feedback.

"See the problem? Buffers produce jitter!"
>
>
> I would rephrase that as "over-sized and under-managed" buffers increase
> jitter unduly. Interestingly, bound jitter can be converted into static
> latency by using, wait for it, (delay) buffers and a scheduler.
>

You are absolutely right. I was hoping someone would spot that! There is
one problem with that approach though. To actually remove the jitter the
scheduler can no longer be work-conserving (needs delay as you also point
out), and that increases TCP ramp-up times (among other things). Can be a
hard sell. I think the benefits outweigh the costs though, so I would do it
your way.

>
> > Only nit is at the conclusion... the benefits of applying fair queuing
> > to level out apparent jitter is well demonstrated at this point, for
> > most kinds of traffic. Wish you'd mentioned it.
>
>         I rather wish low latency DOCSIS (LLD) aka L4S's primary
> driver/use-case would not have been mentioned before it has been properly
> tested and confirmed delivering on its promises. Because most of what L4S
> offers/mandates for jitter reduction is "hopes and prayers", aka end-points
> are supposed to behave well... in fairness LLD at least has a poor man's FQ
> on board in the guise of "queue protection" (with by default like 32
> "buckets")... some of the cost of FQ with only few of its benefits...
>
Fair enough, time will show!


> Regards
>         Sebastian
>
>
>
> >
> >
> > On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <bjorn@domos.no>
> wrote:
> >>
> >> Hi everyone,
> >>
> >> I was inspired by the latest Starship presentation to write a piece on
> network quality in the language of rocket science. The blog can be found
> here:
> https://www.domos.no/news-updates/network-quality-for-rocket-scientists
> >>
> >> Cheers,
> >> Bjørn Ivar Teigen
> >>
> >> --
> >> Bjørn Ivar Teigen
> >> Head of Research
> >> +47 47335952 | bjorn@domos.no | www.domos.no
> >> WiFi Slicing by Domos
> >> _______________________________________________
> >> Starlink mailing list
> >> Starlink@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/starlink
> >
> >
> >
> > --
> > I tried to build a better future, a few times:
> > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> >
> > Dave Täht CEO, TekLibre, LLC
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>
>

-- 
Bjørn Ivar Teigen
Head of Research
+47 47335952 | bjorn@domos.no <name@domos.no> | www.domos.no
WiFi Slicing by Domos

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

Re: [Starlink] Network quality for rocket scientists

[Sebastian Moeller]

Hi Bjørn,


I guess I should have started with the obvious. Nice short article!



> On Feb 14, 2022, at 17:32, Bjørn Ivar Teigen <bjorn@domos.no> wrote:
> 
> Hi Sebastian, thank you for the feedback.
> 
> "See the problem? Buffers produce jitter!"
> 
> 
> I would rephrase that as "over-sized and under-managed" buffers increase jitter unduly. Interestingly, bound jitter can be converted into static latency by using, wait for it, (delay) buffers and a scheduler.
> 
> You are absolutely right. I was hoping someone would spot that! There is one problem with that approach though. To actually remove the jitter the scheduler can no longer be work-conserving (needs delay as you also point out), and that increases TCP ramp-up times (among other things). Can be a hard sell. I think the benefits outweigh the costs though, so I would do it your way.

	But that is what end-points already do, on-line games do this to equalize internet access quality between players (allowing them to make matches over larger populations), as do DASH type video streaming applications, where the isochronous play-out takes the role of the scheduler and the race-to-fill-the-play-out-buffers serves to keep the buffers filled so the scheduler never runs "dry".


> 
> > 
> > Only nit is at the conclusion... the benefits of applying fair queuing
> > to level out apparent jitter is well demonstrated at this point, for
> > most kinds of traffic. Wish you'd mentioned it.
> 
>         I rather wish low latency DOCSIS (LLD) aka L4S's primary driver/use-case would not have been mentioned before it has been properly tested and confirmed delivering on its promises. Because most of what L4S offers/mandates for jitter reduction is "hopes and prayers", aka end-points are supposed to behave well... in fairness LLD at least has a poor man's FQ on board in the guise of "queue protection" (with by default like 32 "buckets")... some of the cost of FQ with only few of its benefits...
> Fair enough, time will show! 

	Given Pete's data at https://github.com/heistp/l4s-tests I am cautious to hold my breath... or to put it differently, I am certain they will not deliver on their promises, the bigger question is whether the incremental improvement they offer (over the default FIFO) is decent enough to retroactively justify the disruption they will have caused...

Regards
	Sebastian



>  
> Regards
>         Sebastian
> 
> 
> 
> > 
> > 
> > On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <bjorn@domos.no> wrote:
> >> 
> >> Hi everyone,
> >> 
> >> I was inspired by the latest Starship presentation to write a piece on network quality in the language of rocket science. The blog can be found here: https://www.domos.no/news-updates/network-quality-for-rocket-scientists
> >> 
> >> Cheers,
> >> Bjørn Ivar Teigen
> >> 
> >> --
> >> Bjørn Ivar Teigen
> >> Head of Research
> >> +47 47335952 | bjorn@domos.no | www.domos.no
> >> WiFi Slicing by Domos
> >> _______________________________________________
> >> Starlink mailing list
> >> Starlink@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/starlink
> > 
> > 
> > 
> > -- 
> > I tried to build a better future, a few times:
> > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> > 
> > Dave Täht CEO, TekLibre, LLC
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> 
> 
> 
> -- 
> Bjørn Ivar Teigen
> Head of Research
> +47 47335952 | bjorn@domos.no | www.domos.no
> WiFi Slicing by Domos

Re: [Starlink] Network quality for rocket scientists

[Bjørn Ivar Teigen]

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

Sebastian,

On Mon, 14 Feb 2022 at 17:15, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Bjørn,
>
>
> I guess I should have started with the obvious. Nice short article!
>
Thank you!

>
> > "See the problem? Buffers produce jitter!"
> >
> > I would rephrase that as "over-sized and under-managed" buffers increase
> jitter unduly. Interestingly, bound jitter can be converted into static
> latency by using, wait for it, (delay) buffers and a scheduler.
> >
> > You are absolutely right. I was hoping someone would spot that! There is
> one problem with that approach though. To actually remove the jitter the
> scheduler can no longer be work-conserving (needs delay as you also point
> out), and that increases TCP ramp-up times (among other things). Can be a
> hard sell. I think the benefits outweigh the costs though, so I would do it
> your way.
>
>         But that is what end-points already do, on-line games do this to
> equalize internet access quality between players (allowing them to make
> matches over larger populations), as do DASH type video streaming
> applications, where the isochronous play-out takes the role of the
> scheduler and the race-to-fill-the-play-out-buffers serves to keep the
> buffers filled so the scheduler never runs "dry".


Good points. The application clients and servers can choose to use their
resources in a way that is not work-conserving and thus achieve sharing of
resources without introducing jitter. I would argue it's a different story
with the queues "in the network", in routers, switches, access points, etc.
There seems to be an unwritten law that those schedulers must be work
conserving, presumably to minimize round-trip times, and this makes it
harder to achieve well-behaved sharing. So in network devices configured to
forward packets as quickly as possible, I think it's mostly true to say
that buffers produce jitter.

        Given Pete's data at https://github.com/heistp/l4s-tests I am
> cautious to hold my breath... or to put it differently, I am certain they
> will not deliver on their promises, the bigger question is whether the
> incremental improvement they offer (over the default FIFO) is decent enough
> to retroactively justify the disruption they will have caused...


Ohh, that work has been updated a lot since the IETF showdown! Thanks for
reminding me, I'll have a look at it again.

- Bjørn Ivar


> Regards
>         Sebastian
>
>
> > >
> > >
> > > On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <bjorn@domos.no>
> wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> I was inspired by the latest Starship presentation to write a piece
> on network quality in the language of rocket science. The blog can be found
> here:
> https://www.domos.no/news-updates/network-quality-for-rocket-scientists
> > >>
> > >> Cheers,
> > >> Bjørn Ivar Teigen
> > >>
> > >> --
> > >> Bjørn Ivar Teigen
> > >> Head of Research
> > >> +47 47335952 | bjorn@domos.no | www.domos.no
> > >> WiFi Slicing by Domos
> > >> _______________________________________________
> > >> Starlink mailing list
> > >> Starlink@lists.bufferbloat.net
> > >> https://lists.bufferbloat.net/listinfo/starlink
> > >
> > >
> > >
> > > --
> > > I tried to build a better future, a few times:
> > > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> > >
> > > Dave Täht CEO, TekLibre, LLC
> > > _______________________________________________
> > > Starlink mailing list
> > > Starlink@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/starlink
> >
> >
> >
> > --
> > Bjørn Ivar Teigen
> > Head of Research
> > +47 47335952 | bjorn@domos.no | www.domos.no
> > WiFi Slicing by Domos
>
>

-- 
Bjørn Ivar Teigen
Head of Research
+47 47335952 | bjorn@domos.no <name@domos.no> | www.domos.no
WiFi Slicing by Domos

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

Re: [Starlink] Network quality for rocket scientists

[Sebastian Moeller]

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

Regarding work conservation, FQ as so often appears to be a decent solution that while not optimal will also not be pessimal. Which IMHO is as much as we can hope for unless we want to burden all middleboxes with deducing relative importance of packets....

Regards
        Sebastian



On 14 February 2022 18:52:29 CET, "Bjørn Ivar Teigen" <bjorn@domos.no> wrote:
>Sebastian,
>
>On Mon, 14 Feb 2022 at 17:15, Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Hi Bjørn,
>>
>>
>> I guess I should have started with the obvious. Nice short article!
>>
>Thank you!
>
>>
>> > "See the problem? Buffers produce jitter!"
>> >
>> > I would rephrase that as "over-sized and under-managed" buffers increase
>> jitter unduly. Interestingly, bound jitter can be converted into static
>> latency by using, wait for it, (delay) buffers and a scheduler.
>> >
>> > You are absolutely right. I was hoping someone would spot that! There is
>> one problem with that approach though. To actually remove the jitter the
>> scheduler can no longer be work-conserving (needs delay as you also point
>> out), and that increases TCP ramp-up times (among other things). Can be a
>> hard sell. I think the benefits outweigh the costs though, so I would do it
>> your way.
>>
>>         But that is what end-points already do, on-line games do this to
>> equalize internet access quality between players (allowing them to make
>> matches over larger populations), as do DASH type video streaming
>> applications, where the isochronous play-out takes the role of the
>> scheduler and the race-to-fill-the-play-out-buffers serves to keep the
>> buffers filled so the scheduler never runs "dry".
>
>
>Good points. The application clients and servers can choose to use their
>resources in a way that is not work-conserving and thus achieve sharing of
>resources without introducing jitter. I would argue it's a different story
>with the queues "in the network", in routers, switches, access points, etc.
>There seems to be an unwritten law that those schedulers must be work
>conserving, presumably to minimize round-trip times, and this makes it
>harder to achieve well-behaved sharing. So in network devices configured to
>forward packets as quickly as possible, I think it's mostly true to say
>that buffers produce jitter.
>
>        Given Pete's data at https://github.com/heistp/l4s-tests I am
>> cautious to hold my breath... or to put it differently, I am certain they
>> will not deliver on their promises, the bigger question is whether the
>> incremental improvement they offer (over the default FIFO) is decent enough
>> to retroactively justify the disruption they will have caused...
>
>
>Ohh, that work has been updated a lot since the IETF showdown! Thanks for
>reminding me, I'll have a look at it again.
>
>- Bjørn Ivar
>
>
>> Regards
>>         Sebastian
>>
>>
>> > >
>> > >
>> > > On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <bjorn@domos.no>
>> wrote:
>> > >>
>> > >> Hi everyone,
>> > >>
>> > >> I was inspired by the latest Starship presentation to write a piece
>> on network quality in the language of rocket science. The blog can be found
>> here:
>> https://www.domos.no/news-updates/network-quality-for-rocket-scientists
>> > >>
>> > >> Cheers,
>> > >> Bjørn Ivar Teigen
>> > >>
>> > >> --
>> > >> Bjørn Ivar Teigen
>> > >> Head of Research
>> > >> +47 47335952 | bjorn@domos.no | www.domos.no
>> > >> WiFi Slicing by Domos
>> > >> _______________________________________________
>> > >> Starlink mailing list
>> > >> Starlink@lists.bufferbloat.net
>> > >> https://lists.bufferbloat.net/listinfo/starlink
>> > >
>> > >
>> > >
>> > > --
>> > > I tried to build a better future, a few times:
>> > > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>> > >
>> > > Dave Täht CEO, TekLibre, LLC
>> > > _______________________________________________
>> > > Starlink mailing list
>> > > Starlink@lists.bufferbloat.net
>> > > https://lists.bufferbloat.net/listinfo/starlink
>> >
>> >
>> >
>> > --
>> > Bjørn Ivar Teigen
>> > Head of Research
>> > +47 47335952 | bjorn@domos.no | www.domos.no
>> > WiFi Slicing by Domos
>>
>>
>
>-- 
>Bjørn Ivar Teigen
>Head of Research
>+47 47335952 | bjorn@domos.no <name@domos.no> | www.domos.no
>WiFi Slicing by Domos

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

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

Re: [Starlink] Network quality for rocket scientists

[Bjørn Ivar Teigen]

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

FQ clearly gets us very good behavior, so no argument there.
Also agree the cost of giving up work conservation might be too high, and
I'm not saying we should necessarily do that. I just wanted to point out
that insisting on work conservation also comes at a cost (which we are free
to choose to pay of course!). It's a choice between adding some middlebox
complexity or accepting the amount of jitter induced by the amount of
queuing needed to maintain high utilization (which depends on the
jitteriness of the interface working to empty the queue).

Regards,
Bjørn Ivar


On Mon, 14 Feb 2022 at 18:39, Sebastian Moeller <moeller0@gmx.de> wrote:

> Regarding work conservation, FQ as so often appears to be a decent
> solution that while not optimal will also not be pessimal. Which IMHO is as
> much as we can hope for unless we want to burden all middleboxes with
> deducing relative importance of packets....
>
> Regards
> Sebastian
>
>
>
> On 14 February 2022 18:52:29 CET, "Bjørn Ivar Teigen" <bjorn@domos.no>
> wrote:
>>
>> Sebastian,
>>
>> On Mon, 14 Feb 2022 at 17:15, Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>>> Hi Bjørn,
>>>
>>>
>>> I guess I should have started with the obvious. Nice short article!
>>>
>> Thank you!
>>
>>>
>>> > "See the problem? Buffers produce jitter!"
>>> >
>>> > I would rephrase that as "over-sized and under-managed" buffers
>>> increase jitter unduly. Interestingly, bound jitter can be converted into
>>> static latency by using, wait for it, (delay) buffers and a scheduler.
>>> >
>>> > You are absolutely right. I was hoping someone would spot that! There
>>> is one problem with that approach though. To actually remove the jitter the
>>> scheduler can no longer be work-conserving (needs delay as you also point
>>> out), and that increases TCP ramp-up times (among other things). Can be a
>>> hard sell. I think the benefits outweigh the costs though, so I would do it
>>> your way.
>>>
>>>         But that is what end-points already do, on-line games do this to
>>> equalize internet access quality between players (allowing them to make
>>> matches over larger populations), as do DASH type video streaming
>>> applications, where the isochronous play-out takes the role of the
>>> scheduler and the race-to-fill-the-play-out-buffers serves to keep the
>>> buffers filled so the scheduler never runs "dry".
>>
>>
>> Good points. The application clients and servers can choose to use their
>> resources in a way that is not work-conserving and thus achieve sharing of
>> resources without introducing jitter. I would argue it's a different story
>> with the queues "in the network", in routers, switches, access points, etc.
>> There seems to be an unwritten law that those schedulers must be work
>> conserving, presumably to minimize round-trip times, and this makes it
>> harder to achieve well-behaved sharing. So in network devices configured to
>> forward packets as quickly as possible, I think it's mostly true to say
>> that buffers produce jitter.
>>
>>         Given Pete's data at https://github.com/heistp/l4s-tests I am
>>> cautious to hold my breath... or to put it differently, I am certain they
>>> will not deliver on their promises, the bigger question is whether the
>>> incremental improvement they offer (over the default FIFO) is decent enough
>>> to retroactively justify the disruption they will have caused...
>>
>>
>> Ohh, that work has been updated a lot since the IETF showdown! Thanks for
>> reminding me, I'll have a look at it again.
>>
>> - Bjørn Ivar
>>
>>
>>> Regards
>>>         Sebastian
>>>
>>>
>>> > >
>>> > >
>>> > > On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <bjorn@domos.no>
>>> wrote:
>>> > >>
>>> > >> Hi everyone,
>>> > >>
>>> > >> I was inspired by the latest Starship presentation to write a piece
>>> on network quality in the language of rocket science. The blog can be found
>>> here:
>>> https://www.domos.no/news-updates/network-quality-for-rocket-scientists
>>> > >>
>>> > >> Cheers,
>>> > >> Bjørn Ivar Teigen
>>> > >>
>>> > >> --
>>> > >> Bjørn Ivar Teigen
>>> > >> Head of Research
>>> > >> +47 47335952 | bjorn@domos.no | www.domos.no
>>> > >> WiFi Slicing by Domos
>>> > >> _______________________________________________
>>> > >> Starlink mailing list
>>> > >> Starlink@lists.bufferbloat.net
>>> > >> https://lists.bufferbloat.net/listinfo/starlink
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > I tried to build a better future, a few times:
>>> > > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>>> > >
>>> > > Dave Täht CEO, TekLibre, LLC
>>> > > _______________________________________________
>>> > > Starlink mailing list
>>> > > Starlink@lists.bufferbloat.net
>>> > > https://lists.bufferbloat.net/listinfo/starlink
>>> >
>>> >
>>> >
>>> > --
>>> > Bjørn Ivar Teigen
>>> > Head of Research
>>> > +47 47335952 | bjorn@domos.no | www.domos.no
>>> > WiFi Slicing by Domos
>>>
>>>
>> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>


-- 
Bjørn Ivar Teigen
Head of Research
+47 47335952 | bjorn@domos.no <name@domos.no> | www.domos.no
WiFi Slicing by Domos

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

Re: [Starlink] FQ for rocket scientists

[Dave Taht]

To bring this back to starlink more coherently, FQ would provide
stabler behavior for voip, videoconferencing and gaming traffic, even
if the characteristics of the underlying link mutate from 2Mbit to
300Mbit on any interval under 20ms and the underlying buffering kept
short. In the now ancient data we had gathered, even the sat-sat
switching delay was under 40ms on roughly a 2m interval, which is
easily compensated for in a jitter buffer (though I might tune one to
adjust more quickly), and I imagine they can switch sats faster in the
future.

I wish we knew more about the underlying multiplexing of the uplink.
We did some high resolution irtt based measurements in the early days,
having *two* starlink terminals fairly close together and repeating
that L3 measurement with well synced clocks would reveal much (as
would analog measurements). My guess is for subscriber density they
are more bound by the uplinks than downlinks (please correct me if I'm
wrong)! as a downlink transmission could contain data for all
terminals all the time, separately decoded....

I hope the dishy provides a GPLS locked ntp clock one day.

That leaves the backhaul (skyhaul?) questions still wide open. I would
be trying to regulate bandwidth (and buffering) on the ground stations
to keep the queues in the sky relatively empty, doing ack-filtering in
both directions (because that works well with bursty, blocked, traffic
and reduces pressure on packet fifos), but when the laser links go
up... my head still explodes. Too many unknown unknowns.

On Mon, Feb 14, 2022 at 2:21 PM Bjørn Ivar Teigen <bjorn@domos.no> wrote:
>
> FQ clearly gets us very good behavior, so no argument there.
> Also agree the cost of giving up work conservation might be too high, and I'm not saying we should necessarily do that. I just wanted to point out that insisting on work conservation also comes at a cost (which we are free to choose to pay of course!). It's a choice between adding some middlebox complexity or accepting the amount of jitter induced by the amount of queuing needed to maintain high utilization (which depends on the jitteriness of the interface working to empty the queue).
>
> Regards,
> Bjørn Ivar
>
>
> On Mon, 14 Feb 2022 at 18:39, Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>> Regarding work conservation, FQ as so often appears to be a decent solution that while not optimal will also not be pessimal. Which IMHO is as much as we can hope for unless we want to burden all middleboxes with deducing relative importance of packets....
>>
>> Regards
>> Sebastian
>>
>>
>>
>> On 14 February 2022 18:52:29 CET, "Bjørn Ivar Teigen" <bjorn@domos.no> wrote:
>>>
>>> Sebastian,
>>>
>>> On Mon, 14 Feb 2022 at 17:15, Sebastian Moeller <moeller0@gmx.de> wrote:
>>>>
>>>> Hi Bjørn,
>>>>
>>>>
>>>> I guess I should have started with the obvious. Nice short article!
>>>
>>> Thank you!
>>>>
>>>>
>>>> > "See the problem? Buffers produce jitter!"
>>>> >
>>>> > I would rephrase that as "over-sized and under-managed" buffers increase jitter unduly. Interestingly, bound jitter can be converted into static latency by using, wait for it, (delay) buffers and a scheduler.
>>>> >
>>>> > You are absolutely right. I was hoping someone would spot that! There is one problem with that approach though. To actually remove the jitter the scheduler can no longer be work-conserving (needs delay as you also point out), and that increases TCP ramp-up times (among other things). Can be a hard sell. I think the benefits outweigh the costs though, so I would do it your way.
>>>>
>>>>         But that is what end-points already do, on-line games do this to equalize internet access quality between players (allowing them to make matches over larger populations), as do DASH type video streaming applications, where the isochronous play-out takes the role of the scheduler and the race-to-fill-the-play-out-buffers serves to keep the buffers filled so the scheduler never runs "dry".
>>>
>>>
>>> Good points. The application clients and servers can choose to use their resources in a way that is not work-conserving and thus achieve sharing of resources without introducing jitter. I would argue it's a different story with the queues "in the network", in routers, switches, access points, etc. There seems to be an unwritten law that those schedulers must be work conserving, presumably to minimize round-trip times, and this makes it harder to achieve well-behaved sharing. So in network devices configured to forward packets as quickly as possible, I think it's mostly true to say that buffers produce jitter.
>>>
>>>>         Given Pete's data at https://github.com/heistp/l4s-tests I am cautious to hold my breath... or to put it differently, I am certain they will not deliver on their promises, the bigger question is whether the incremental improvement they offer (over the default FIFO) is decent enough to retroactively justify the disruption they will have caused...
>>>
>>>
>>> Ohh, that work has been updated a lot since the IETF showdown! Thanks for reminding me, I'll have a look at it again.
>>>
>>> - Bjørn Ivar
>>>
>>>>
>>>> Regards
>>>>         Sebastian
>>>>
>>>>
>>>> > >
>>>> > >
>>>> > > On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <bjorn@domos.no> wrote:
>>>> > >>
>>>> > >> Hi everyone,
>>>> > >>
>>>> > >> I was inspired by the latest Starship presentation to write a piece on network quality in the language of rocket science. The blog can be found here: https://www.domos.no/news-updates/network-quality-for-rocket-scientists
>>>> > >>
>>>> > >> Cheers,
>>>> > >> Bjørn Ivar Teigen
>>>> > >>
>>>> > >> --
>>>> > >> Bjørn Ivar Teigen
>>>> > >> Head of Research
>>>> > >> +47 47335952 | bjorn@domos.no | www.domos.no
>>>> > >> WiFi Slicing by Domos
>>>> > >> _______________________________________________
>>>> > >> Starlink mailing list
>>>> > >> Starlink@lists.bufferbloat.net
>>>> > >> https://lists.bufferbloat.net/listinfo/starlink
>>>> > >
>>>> > >
>>>> > >
>>>> > > --
>>>> > > I tried to build a better future, a few times:
>>>> > > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>>>> > >
>>>> > > Dave Täht CEO, TekLibre, LLC
>>>> > > _______________________________________________
>>>> > > Starlink mailing list
>>>> > > Starlink@lists.bufferbloat.net
>>>> > > https://lists.bufferbloat.net/listinfo/starlink
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Bjørn Ivar Teigen
>>>> > Head of Research
>>>> > +47 47335952 | bjorn@domos.no | www.domos.no
>>>> > WiFi Slicing by Domos
>>>>
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
>
> --
> Bjørn Ivar Teigen
> Head of Research
> +47 47335952 | bjorn@domos.no | www.domos.no
> WiFi Slicing by Domos



-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

Re: [Starlink] FQ for rocket scientists

[Michael Richardson]

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


Dave Taht <dave.taht@gmail.com> wrote:
    > I wish we knew more about the underlying multiplexing of the uplink.

I think you are asking: could we send several small packets on frequency/channel A,
while a larger packet is being transmitted on frequency/channel B?

Being able to get around head-of-Q blocks would really be nice.


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

Re: [Starlink] Network quality for rocket scientists

[Dave Collier-Brown]

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

There's a typo n the link to "is much more common than you’d think", https://ieeexplore.ieee.org.no/document/9615514

There is an extra  ".no" after the ".org"

--dave

On 2/14/22 10:07, Bjørn Ivar Teigen wrote:
Hi everyone,

I was inspired by the latest Starship presentation to write a piece on network quality in the language of rocket science. The blog can be found here: https://www.domos.no/news-updates/network-quality-for-rocket-scientists

Cheers,
Bjørn Ivar Teigen

--
Bjørn Ivar Teigen
Head of Research
+47 47335952 | bjorn@domos.no<mailto:name@domos.no> | www.domos.no<http://www.domos.no/>
WiFi Slicing by Domos



_______________________________________________
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: 5309 bytes --]