Re: [Starlink] Starlink ISL data

Re: [Starlink] Starlink ISL data

[David Fernández]

I thought Starlink was not supporting IPv6, because of this:

https://twitter.com/elonmusk/status/967712110661615616

> Date: Sun, 26 Mar 2023 19:32:31 -0700
> From: Dave Taht <dave.taht@gmail.com>
> To: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] Starlink ISL data
> Message-ID:
> 	<CAA93jw4kcfXiwMw0zKAuQV3BjpWp6ZvQ2TQFbtEy9CFRN5aY2w@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Nate gave me the opportunity to test a bit of ipv6 access on one of
> his dishys today. I am going to give p2p a shot, also, and he
> conveniently has bbr2 installed. It is of course difficult to discern
> the difference between transport behaviors and their underlying
> connectivity - for example the BBR2 result attached has a baseline
> (idle!) latency jump of over 40ms which is hard to explain.
>
> Despite these plots saying downloads, they were essentially uploads
> from his box over the internet.
>
> The summary of the data I have so far on this direction is:
>
> Cubic, looks like cubic, usually, but not always. BBR rarely looks like BBR.
>
> On Fri, Mar 24, 2023 at 2:46 PM Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Vint just asked me a difficult question over here about the
>> performance of the ISL links for my upcoming AMA next week
>>
>> https://twitter.com/mtaht/status/1639361656106156032
>>
>> And to date, we really don't know. We do know it is up!? but...
>>
>> has anyone managed to measure p2p ipv6 performance starlink to
>> starlink over an ISL link as yet? Do we know anyone at the poles? In
>> general I always look for flent and irtt data, but I'd settle for a,
>> oh, call it 5-10 minute long packet capture of single iperf flow,
>> running over tcp cubic (bbr would be great too).... one test in each
>> direction.
>>
>> (in fact that would be great from any starlink terminal to any of my
>> servers around the world)
>>
>> I have some data from a couple of you (thx ulrich in particular!), but
>> I have not sat down to take it apart as I have been far, far too busy
>> with libreqos and a bunch of nice, small, competent ISPs deploying
>> that, to worry about fixing a billionaire's network all that much....
>> but I've set aside next week to answer AMAs about everything from all
>> and sundry, so if you got data, please share?
>>
>> --
>> Come Heckle Mar 6-9 at: https://www.understandinglatency.com/
>> Dave Täht CEO, TekLibre, LLC
>
>
>
> --
> https://www.youtube.com/watch?v=tAVwmUG21OY&t=6483s
> Dave Täht CEO, TekLibre, LLC
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: tcp_ndown_-_starlink-ipv6-cubic.png
> Type: image/png
> Size: 145300 bytes
> Desc: not available
> URL:
> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230326/32c7fed1/attachment.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: tcp_ndown_-_starlink-ipv6-bbr2.png
> Type: image/png
> Size: 64805 bytes
> Desc: not available
> URL:
> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230326/32c7fed1/attachment-0001.png>

Re: [Starlink] Starlink ISL data

[David Lang]

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

I'm seeing some IPv6 on starlink (and had to troubleshoot another person on 
starlink that had a corporate access problem that was resovled by disabling 
IPv6)

David Lang

  On Mon, 27 Mar 2023, David Fernández via Starlink wrote:

> Date: Mon, 27 Mar 2023 12:44:26 +0200
> From: David Fernández via Starlink <starlink@lists.bufferbloat.net>
> Reply-To: David Fernández <davidfdzp@gmail.com>
> To: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Starlink ISL data
> 
> I thought Starlink was not supporting IPv6, because of this:
>
> https://twitter.com/elonmusk/status/967712110661615616
>
>> Date: Sun, 26 Mar 2023 19:32:31 -0700
>> From: Dave Taht <dave.taht@gmail.com>
>> To: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
>> Subject: Re: [Starlink] Starlink ISL data
>> Message-ID:
>> 	<CAA93jw4kcfXiwMw0zKAuQV3BjpWp6ZvQ2TQFbtEy9CFRN5aY2w@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Nate gave me the opportunity to test a bit of ipv6 access on one of
>> his dishys today. I am going to give p2p a shot, also, and he
>> conveniently has bbr2 installed. It is of course difficult to discern
>> the difference between transport behaviors and their underlying
>> connectivity - for example the BBR2 result attached has a baseline
>> (idle!) latency jump of over 40ms which is hard to explain.
>>
>> Despite these plots saying downloads, they were essentially uploads
>> from his box over the internet.
>>
>> The summary of the data I have so far on this direction is:
>>
>> Cubic, looks like cubic, usually, but not always. BBR rarely looks like BBR.
>>
>> On Fri, Mar 24, 2023 at 2:46 PM Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>> Vint just asked me a difficult question over here about the
>>> performance of the ISL links for my upcoming AMA next week
>>>
>>> https://twitter.com/mtaht/status/1639361656106156032
>>>
>>> And to date, we really don't know. We do know it is up!? but...
>>>
>>> has anyone managed to measure p2p ipv6 performance starlink to
>>> starlink over an ISL link as yet? Do we know anyone at the poles? In
>>> general I always look for flent and irtt data, but I'd settle for a,
>>> oh, call it 5-10 minute long packet capture of single iperf flow,
>>> running over tcp cubic (bbr would be great too).... one test in each
>>> direction.
>>>
>>> (in fact that would be great from any starlink terminal to any of my
>>> servers around the world)
>>>
>>> I have some data from a couple of you (thx ulrich in particular!), but
>>> I have not sat down to take it apart as I have been far, far too busy
>>> with libreqos and a bunch of nice, small, competent ISPs deploying
>>> that, to worry about fixing a billionaire's network all that much....
>>> but I've set aside next week to answer AMAs about everything from all
>>> and sundry, so if you got data, please share?
>>>
>>> --
>>> Come Heckle Mar 6-9 at: https://www.understandinglatency.com/
>>> Dave Täht CEO, TekLibre, LLC
>>
>>
>>
>> --
>> https://www.youtube.com/watch?v=tAVwmUG21OY&t=6483s
>> Dave Täht CEO, TekLibre, LLC
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: tcp_ndown_-_starlink-ipv6-cubic.png
>> Type: image/png
>> Size: 145300 bytes
>> Desc: not available
>> URL:
>> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230326/32c7fed1/attachment.png>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: tcp_ndown_-_starlink-ipv6-bbr2.png
>> Type: image/png
>> Size: 64805 bytes
>> Desc: not available
>> URL:
>> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230326/32c7fed1/attachment-0001.png>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink ISL data

[Ulrich Speidel]

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

Still not seeing any IPv6 from a roaming unit in New Zealand, although I 
notice Starlink advertising global maritime coverage now, which requires 
the laser links to work at least a little bit.

Dave, I'm currently collecting more flent data for you - did so the 
other week but then realised that the directory the data was going to 
was cloud synced, so wouldn't have made for a fair measurement given 
that it would have synced via Starlink, too.

As for the jumps in performance, that's easily explained: As dishy 
switches to a different satellite, it sees a different queue, but the 
satellite that this queue belongs to also sees a different set of users 
with different cardinality, doing different things. So if you're 
switching to a satellite that sits over an area with low Starlink user 
density, you're likely to see a shorter queue (less latency) than if 
you're thrown in with the crowd. If it's the BBR where a significant 
jump happened, then that could just be coincidence.

On 28/03/2023 7:54 am, David Lang via Starlink wrote:
> I'm seeing some IPv6 on starlink (and had to troubleshoot another 
> person on
> starlink that had a corporate access problem that was resovled by 
> disabling
> IPv6)
>
> David Lang
>
> On Mon, 27 Mar 2023, David Fernández via Starlink wrote:
>
> > Date: Mon, 27 Mar 2023 12:44:26 +0200
> > From: David Fernández via Starlink <starlink@lists.bufferbloat.net>
> > Reply-To: David Fernández <davidfdzp@gmail.com>
> > To: starlink@lists.bufferbloat.net
> > Subject: Re: [Starlink] Starlink ISL data
> >
> > I thought Starlink was not supporting IPv6, because of this:
> >
> > https://twitter.com/elonmusk/status/967712110661615616 
> <https://twitter.com/elonmusk/status/967712110661615616>
> >
> >> Date: Sun, 26 Mar 2023 19:32:31 -0700
> >> From: Dave Taht <dave.taht@gmail.com>
> >> To: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> >> Subject: Re: [Starlink] Starlink ISL data
> >> Message-ID:
> >> <CAA93jw4kcfXiwMw0zKAuQV3BjpWp6ZvQ2TQFbtEy9CFRN5aY2w@mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> Nate gave me the opportunity to test a bit of ipv6 access on one of
> >> his dishys today. I am going to give p2p a shot, also, and he
> >> conveniently has bbr2 installed. It is of course difficult to discern
> >> the difference between transport behaviors and their underlying
> >> connectivity - for example the BBR2 result attached has a baseline
> >> (idle!) latency jump of over 40ms which is hard to explain.
> >>
> >> Despite these plots saying downloads, they were essentially uploads
> >> from his box over the internet.
> >>
> >> The summary of the data I have so far on this direction is:
> >>
> >> Cubic, looks like cubic, usually, but not always. BBR rarely looks 
> like BBR.
> >>
> >> On Fri, Mar 24, 2023 at 2:46 PM Dave Taht <dave.taht@gmail.com> wrote:
> >>>
> >>> Vint just asked me a difficult question over here about the
> >>> performance of the ISL links for my upcoming AMA next week
> >>>
> >>> https://twitter.com/mtaht/status/1639361656106156032 
> <https://twitter.com/mtaht/status/1639361656106156032>
> >>>
> >>> And to date, we really don't know. We do know it is up!? but...
> >>>
> >>> has anyone managed to measure p2p ipv6 performance starlink to
> >>> starlink over an ISL link as yet? Do we know anyone at the poles? In
> >>> general I always look for flent and irtt data, but I'd settle for a,
> >>> oh, call it 5-10 minute long packet capture of single iperf flow,
> >>> running over tcp cubic (bbr would be great too).... one test in each
> >>> direction.
> >>>
> >>> (in fact that would be great from any starlink terminal to any of my
> >>> servers around the world)
> >>>
> >>> I have some data from a couple of you (thx ulrich in particular!), but
> >>> I have not sat down to take it apart as I have been far, far too busy
> >>> with libreqos and a bunch of nice, small, competent ISPs deploying
> >>> that, to worry about fixing a billionaire's network all that much....
> >>> but I've set aside next week to answer AMAs about everything from all
> >>> and sundry, so if you got data, please share?
> >>>
> >>> --
> >>> Come Heckle Mar 6-9 at: https://www.understandinglatency.com/ 
> <https://www.understandinglatency.com>
> >>> Dave Täht CEO, TekLibre, LLC
> >>
> >>
> >>
> >> --
> >> https://www.youtube.com/watch?v=tAVwmUG21OY&t=6483s 
> <https://www.youtube.com/watch?v=tAVwmUG21OY&t=6483s>
> >> Dave Täht CEO, TekLibre, LLC
> >> -------------- next part --------------
> >> A non-text attachment was scrubbed...
> >> Name: tcp_ndown_-_starlink-ipv6-cubic.png
> >> Type: image/png
> >> Size: 145300 bytes
> >> Desc: not available
> >> URL:
> >> 
> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230326/32c7fed1/attachment.png 
> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230326/32c7fed1/attachment.png>>
> >> -------------- next part --------------
> >> A non-text attachment was scrubbed...
> >> Name: tcp_ndown_-_starlink-ipv6-bbr2.png
> >> Type: image/png
> >> Size: 64805 bytes
> >> Desc: not available
> >> URL:
> >> 
> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230326/32c7fed1/attachment-0001.png 
> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230326/32c7fed1/attachment-0001.png>>
> > _______________________________________________
> > Starlink mailing list
> > 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
>
-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



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

Re: [Starlink] Starlink ISL data

[Dave Taht]

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

Nate gave me the opportunity to test a bit of ipv6 access on one of
his dishys today. I am going to give p2p a shot, also, and he
conveniently has bbr2 installed. It is of course difficult to discern
the difference between transport behaviors and their underlying
connectivity - for example the BBR2 result attached has a baseline
(idle!) latency jump of over 40ms which is hard to explain.

Despite these plots saying downloads, they were essentially uploads
from his box over the internet.

The summary of the data I have so far on this direction is:

Cubic, looks like cubic, usually, but not always. BBR rarely looks like BBR.

On Fri, Mar 24, 2023 at 2:46 PM Dave Taht <dave.taht@gmail.com> wrote:
>
> Vint just asked me a difficult question over here about the
> performance of the ISL links for my upcoming AMA next week
>
> https://twitter.com/mtaht/status/1639361656106156032
>
> And to date, we really don't know. We do know it is up!? but...
>
> has anyone managed to measure p2p ipv6 performance starlink to
> starlink over an ISL link as yet? Do we know anyone at the poles? In
> general I always look for flent and irtt data, but I'd settle for a,
> oh, call it 5-10 minute long packet capture of single iperf flow,
> running over tcp cubic (bbr would be great too).... one test in each
> direction.
>
> (in fact that would be great from any starlink terminal to any of my
> servers around the world)
>
> I have some data from a couple of you (thx ulrich in particular!), but
> I have not sat down to take it apart as I have been far, far too busy
> with libreqos and a bunch of nice, small, competent ISPs deploying
> that, to worry about fixing a billionaire's network all that much....
> but I've set aside next week to answer AMAs about everything from all
> and sundry, so if you got data, please share?
>
> --
> Come Heckle Mar 6-9 at: https://www.understandinglatency.com/
> Dave Täht CEO, TekLibre, LLC



-- 
https://www.youtube.com/watch?v=tAVwmUG21OY&t=6483s
Dave Täht CEO, TekLibre, LLC

[-- Attachment #2: tcp_ndown_-_starlink-ipv6-cubic.png --]
[-- Type: image/png, Size: 145300 bytes --]

[-- Attachment #3: tcp_ndown_-_starlink-ipv6-bbr2.png --]
[-- Type: image/png, Size: 64805 bytes --]

[Starlink] Starlink ISL data

[Dave Taht]

Vint just asked me a difficult question over here about the
performance of the ISL links for my upcoming AMA next week

https://twitter.com/mtaht/status/1639361656106156032

And to date, we really don't know. We do know it is up!? but...

has anyone managed to measure p2p ipv6 performance starlink to
starlink over an ISL link as yet? Do we know anyone at the poles? In
general I always look for flent and irtt data, but I'd settle for a,
oh, call it 5-10 minute long packet capture of single iperf flow,
running over tcp cubic (bbr would be great too).... one test in each
direction.

(in fact that would be great from any starlink terminal to any of my
servers around the world)

I have some data from a couple of you (thx ulrich in particular!), but
I have not sat down to take it apart as I have been far, far too busy
with libreqos and a bunch of nice, small, competent ISPs deploying
that, to worry about fixing a billionaire's network all that much....
but I've set aside next week to answer AMAs about everything from all
and sundry, so if you got data, please share?

-- 
Come Heckle Mar 6-9 at: https://www.understandinglatency.com/
Dave Täht CEO, TekLibre, LLC