From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DEE8B3CB37 for ; Sun, 18 Jul 2021 21:34:43 -0400 (EDT) Received: by mail-qt1-x830.google.com with SMTP id r17so11935283qtp.5 for ; Sun, 18 Jul 2021 18:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forwardingplane-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rl7Mc4rdrq+icf3XDHqZ2kpbcgtwarPgeBMrMXoL4vI=; b=kd13RavuRrqqb5P+LNOid/S6t8gU4P8HE5qPK94VItaIVU5hHLyTwJqqlo5UdooVTy 2B7a++A1wwYtEGJbzqLPlYks/Wxj3Dvmf3f/netTWPC+sFl/ZqutO5NN6zQqfQCY/X6S UBbyTJyZHfG+oaFPtnuEaHfZnMt6ZbbENf+RLOeLcpMYDRNslho8587i5GpdiNajBeiE aRWsUW3DjedwJQ3E/nwo7UmLn7QfCPZFbHQi0I48vhGkz31PhlxQ62yik1WwLJ5Rh1dn jxkF4ongUirKg5GhQSlhvdSxQ4GPOWkCvcKYI53vKdQFRJbqwre7cxlZBHmenHdP62It EYFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rl7Mc4rdrq+icf3XDHqZ2kpbcgtwarPgeBMrMXoL4vI=; b=b7VeEzAJrHZzc6ZUuexYa1WK6HazHWstGovobOZEfBwdArvguimpClRWxSB2Tx/x81 aFbbmPRunZIuwy22hkQqA6Onr1f6wodqOIax5boxRFQEp/ramjDKc+4LRU2hHPh4SlGp b6iov6I6VHWV2UsFH29H6egyaKaJfaaHZrtlqKfxjID3FllbrvKo7DDnUiNRk5vnR5Wn 2jHs/mdBHZmLJt1B1lAt2Dhld385/vMPHiK/s0WPyTq6FzwWTQCjj51kgri4wel2sBlh yL7VkTaR8PK6bB9p0GQ1aV0fcmaAnY82CZ6j6pOlc8ek0C7l230DkY3GDViMvgv4IY7Q 3Hhg== X-Gm-Message-State: AOAM53030QWTNCjjapCB3pqkgrxqD1zt8o2JZfg04c6UJIUiQTKTdkE3 JGAaynoTDh8dAcTxe2lPnkRv5Tma8+d4t1dh7ZN0fg== X-Google-Smtp-Source: ABdhPJzaPn0idmEj5xh0xuWQjX2/Y1yBqfCQ538hsBb422pJSHzfRMevq18BXeIJiln8xetljk+Sss/q0yslX/75fXU= X-Received: by 2002:a05:622a:255:: with SMTP id c21mr17155831qtx.375.1626658483069; Sun, 18 Jul 2021 18:34:43 -0700 (PDT) MIME-Version: 1.0 References: <1625856001.74681750@apps.rackspace.com> In-Reply-To: From: Nick Buraglio Date: Sun, 18 Jul 2021 20:34:31 -0500 Message-ID: To: David Lang Cc: "David P. Reed" , Jonathan Bennett , starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000000dfcb905c76ff126" Subject: Re: [Starlink] Starlink and bufferbloat status? X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 01:34:44 -0000 --0000000000000dfcb905c76ff126 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No requirement for layer3 for that. I=E2=80=99d bet money they=E2=80=99ll k= eep L3 out of space. nb On Sun, Jul 18, 2021 at 8:20 PM David Lang wrote: > Elon is talking about a viable path in the future being dishy - sat - sat > - > dishy > > They aren't there yet, but they are sure planning on it > > David Lang > > On Sun, 18 Jul 2021, Nick Buraglio wrote: > > > We keep saying =E2=80=9Croute=E2=80=9D. What do we actually mean from a= network stack > > perspective? Are we talking about relaying light / frames / electric or > do > > we mean actual packet routing, because there are obviously a lot of > > important distinctions there. > > I=E2=80=99m willing to bet that there is no routing (as in layer 3 pack= et > routing) > > at all except the Dish NAT all the way into their peering data center. > The > > ground stations are very likely RF to fiber wave division back to a > carrier > > hotel with no L3 buffering at all. That keeps latency very low (think > O-E-O > > and E-O transitions) and moves L3 buffering to two locations and keeps > the > > terrestrial network very easy to make redundant (optical protection, > etc.). > > > > nb > > > > On Fri, Jul 16, 2021 at 12:39 PM Jonathan Bennett < > > jonathanbennett@hackaday.com> wrote: > > > >> > >> > >> On Fri, Jul 16, 2021, 12:35 PM Nathan Owens wrote: > >> > >>> The other case where they could provide benefit is very long distance > >>> paths --- NY to Tokyo, Johannesburg to London, etc... but presumably = at > >>> high cost, as the capacity will likely be much lower than submarine > cables. > >>> > >>>> > >> Or traffic between Starlink customers. A video call between me and > someone > >> else on the Starlink network is going to be drastically better if it c= an > >> route over the sats. > >> > >>> > >>>> On Fri, Jul 16, 2021 at 10:31 AM Mike Puchol > wrote: > >>> > >>>> Satellite optical links are useful to extend coverage to areas where > you > >>>> don=E2=80=99t have gateways - thus, they will introduce additional l= atency > compared > >>>> to two space segment hops (terminal to satellite -> satellite to > gateway). > >>>> If you have terminal to satellite, two optical hops, then final > satellite > >>>> to gateway, you will have more latency, not less. > >>>> > >>>> We are being =E2=80=9Csold=E2=80=9D optical links for what they are = not IMHO. > >>>> > >>>> Best, > >>>> > >>>> Mike > >>>> On Jul 16, 2021, 19:29 +0200, Nathan Owens , wrote= : > >>>> > >>>>> As there are more satellites, the up down time will get closer to > >>>> 4-5ms rather then the ~7ms you list > >>>> > >>>> Possibly, if you do steering to always jump to the lowest latency > >>>> satellite. > >>>> > >>>>> with laser relays in orbit, and terminal to terminal routing in > orbit, > >>>> there is the potential for the theoretical minimum to tend lower > >>>> Maybe for certain users really in the middle of nowhere, but I did t= he > >>>> best-case math for "bent pipe" in Seattle area, which is as good as > it gets. > >>>> > >>>> On Fri, Jul 16, 2021 at 10:24 AM David Lang wrote: > >>>> > >>>>> hey, it's a good attitude to have :-) > >>>>> > >>>>> Elon tends to set 'impossible' goals, miss the timeline a bit, and > come > >>>>> very > >>>>> close to the goal, if not exceed it. > >>>>> > >>>>> As there are more staellites, the up down time will get closer to > 4-5ms > >>>>> rather > >>>>> then the ~7ms you list, and with laser relays in orbit, and termina= l > to > >>>>> terminal > >>>>> routing in orbit, there is the potential for the theoretical minimu= m > to > >>>>> tend > >>>>> lower, giving some headroom for other overhead but still being in t= he > >>>>> 20ms > >>>>> range. > >>>>> > >>>>> David Lang > >>>>> > >>>>> On Fri, 16 Jul 2021, Nathan Owens wrote: > >>>>> > >>>>>> Elon said "foolish packet routing" for things over 20ms! Which see= ms > >>>>> crazy > >>>>>> if you do some basic math: > >>>>>> > >>>>>> - Sat to User Terminal distance: 550-950km air/vacuum: 1.9 - 3.3= ms > >>>>>> - Sat to GW distance: 550-950km air/vacuum: 1.9 - 3.3ms > >>>>>> - GW to PoP Distance: 50-800km fiber: 0.25 - 4ms > >>>>>> - PoP to Internet Distance: 50km fiber: 0.25 - 0.5ms > >>>>>> - Total one-way delay: 4.3 - 11.1ms > >>>>>> - Theoretical minimum RTT: 8.6ms - 22.2ms, call it 15.4ms > >>>>>> > >>>>>> This includes no transmission delay, queuing delay, > >>>>>> processing/fragmentation/reassembly/etc, and no time-division > >>>>> multiplexing. > >>>>>> > >>>>>> On Fri, Jul 16, 2021 at 10:09 AM David Lang wrote: > >>>>>> > >>>>>>> I think it depends on if you are looking at > datacenter-to-datacenter > >>>>>>> latency of > >>>>>>> home to remote datacenter latency :-) > >>>>>>> > >>>>>>> my rule of thumb for cross US ping time has been 80-100ms latency > >>>>> (but > >>>>>>> it's been > >>>>>>> a few years since I tested it). > >>>>>>> > >>>>>>> I note that an article I saw today said that Elon is saying that > >>>>> latency > >>>>>>> will > >>>>>>> improve significantly in the near future, that up/down latency is > >>>>> ~20ms > >>>>>>> and the > >>>>>>> additional delays pushing it to the 80ms range are 'stupid packet > >>>>> routing' > >>>>>>> problems that they are working on. > >>>>>>> > >>>>>>> If they are still in that level of optimization, it doesn't > surprise > >>>>> me > >>>>>>> that > >>>>>>> they haven't really focused on the bufferbloat issue, they have > more > >>>>>>> obvious > >>>>>>> stuff to fix first. > >>>>>>> > >>>>>>> David Lang > >>>>>>> > >>>>>>> > >>>>>>> On Fri, 16 Jul 2021, Wheelock, Ian wrote: > >>>>>>> > >>>>>>>> Date: Fri, 16 Jul 2021 10:21:52 +0000 > >>>>>>>> From: "Wheelock, Ian" > >>>>>>>> To: David Lang , David P. Reed < > dpreed@deepplum.com> > >>>>>>>> Cc: "starlink@lists.bufferbloat.net" < > >>>>> starlink@lists.bufferbloat.net> > >>>>>>>> Subject: Re: [Starlink] Starlink and bufferbloat status? > >>>>>>>> > >>>>>>>> Hi David > >>>>>>>> In terms of the Latency that David (Reed) mentioned for Californ= ia > >>>>> to > >>>>>>> Massachusetts of about 17ms over the public internet, it seems a > bit > >>>>> faster > >>>>>>> than what I would expect. My own traceroute via my VDSL link show= s > >>>>> 14ms > >>>>>>> just to get out of the operator network. > >>>>>>>> > >>>>>>>> https://www.wondernetwork.com is a handy tool for checking > >>>>> geographic > >>>>>>> ping perf between cities, and it shows a min of about 66ms for > pings > >>>>>>> between Boston and San Diego > >>>>>>> https://wondernetwork.com/pings/boston/San%20Diego (so about 33ms > >>>>> for > >>>>>>> 1-way transfer). > >>>>>>>> > >>>>>>>> Distance wise this is about 4,100 KM (2,500 M), and @2/3 speed o= f > >>>>> light > >>>>>>> (through a pure fibre link of that distance) the propagation time > is > >>>>> just > >>>>>>> over 20ms. If the network equipment between the Boston and San > Diego > >>>>> is > >>>>>>> factored in, with some buffering along the way, 33ms does seem > quite > >>>>>>> reasonable over the 20ms for speed of light in fibre for that 1-w= ay > >>>>> transfer > >>>>>>>> > >>>>>>>> -Ian Wheelock > >>>>>>>> > >>>>>>>> From: Starlink on behal= f > >>>>> of > >>>>>>> David Lang > >>>>>>>> Date: Friday 9 July 2021 at 23:59 > >>>>>>>> To: "David P. Reed" > >>>>>>>> Cc: "starlink@lists.bufferbloat.net" < > >>>>> starlink@lists.bufferbloat.net> > >>>>>>>> Subject: Re: [Starlink] Starlink and bufferbloat status? > >>>>>>>> > >>>>>>>> IIRC, the definition of 'low latency' for the FCC was something > like > >>>>>>> 100ms, and Musk was predicting <40ms. roughly competitive with > >>>>> landlines, > >>>>>>> and worlds better than geostationary satellite (and many > >>>>>>>> External (mailto:david@lang.hm) > >>>>>>>> > >>>>>>> > >>>>> > https://shared.outlook.inky.com/report?id=3DY29tbXNjb3BlL2lhbi53aGVlbG9ja= 0Bjb21tc2NvcGUuY29tL2I1MzFjZDA4OTZmMWI0Yzc5NzdiOTIzNmY3MTAzM2MxLzE2MjU4NzE1= NDkuNjU=3D#key=3D19e8545676e28e577c813de83a4cf1dc > >>>>>>> https://www.inky.com/banner-faq/ https://www.inky.com > >>>>>>>> > >>>>>>>> IIRC, the definition of 'low latency' for the FCC was something > like > >>>>>>> 100ms, and > >>>>>>>> Musk was predicting <40ms. > >>>>>>>> > >>>>>>>> roughly competitive with landlines, and worlds better than > >>>>> geostationary > >>>>>>>> satellite (and many wireless ISPs) > >>>>>>>> > >>>>>>>> but when doing any serious testing of latency, you need to be > wired > >>>>> to > >>>>>>> the > >>>>>>>> router, wifi introduces so much variability that it swamps the > >>>>> signal. > >>>>>>>> > >>>>>>>> David Lang > >>>>>>>> > >>>>>>>> On Fri, 9 Jul 2021, David P. Reed wrote: > >>>>>>>> > >>>>>>>>> Date: Fri, 9 Jul 2021 14:40:01 -0400 (EDT) > >>>>>>>>> From: David P. Reed > >>>>>>>>> To: starlink@lists.bufferbloat.net > >>>>>>>>> Subject: [Starlink] Starlink and bufferbloat status? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Early measurements of performance of Starlink have shown > >>>>> significant > >>>>>>> bufferbloat, as Dave Taht has shown. > >>>>>>>>> > >>>>>>>>> But... Starlink is a moving target. The bufferbloat isn't a > >>>>> hardware > >>>>>>> issue, it should be completely manageable, starting by simple > >>>>> firmware > >>>>>>> changes inside the Starlink system itself. For example, > implementing > >>>>>>> fq_codel so that bottleneck links just drop packets according to > the > >>>>> Best > >>>>>>> Practices RFC, > >>>>>>>>> > >>>>>>>>> So I'm hoping this has improved since Dave's measurements. How > >>>>> much has > >>>>>>> it improved? What's the current maximum packet latency under full > >>>>>>> load, Ive heard anecdotally that a friend of a friend gets 84 > msec. > >>>>> *ping > >>>>>>> times under full load*, but he wasn't using flent or some other > >>>>> measurement > >>>>>>> tool of good quality that gives a true number. > >>>>>>>>> > >>>>>>>>> 84 msec is not great - it's marginal for Zoom quality experienc= e > >>>>> (you > >>>>>>> want latencies significantly less than 100 msec. as a rule of thu= mb > >>>>> for > >>>>>>> teleconferencing quality). But it is better than Dave's > measurements > >>>>> showed. > >>>>>>>>> > >>>>>>>>> Now Musk bragged that his network was "low latency" unlike othe= r > >>>>> high > >>>>>>> speed services, which means low end-to-end latency. That got him > >>>>>>> permission from the FCC to operate Starlink at all. His number > was, I > >>>>>>> think, < 5 msec. 84 is a lot more than 5. (I didn't believe 5, > >>>>> because he > >>>>>>> probably meant just the time from the ground station to the > terminal > >>>>>>> through the satellite. But I regularly get 17 msec. between > >>>>> California and > >>>>>>> Massachusetts over the public Internet) > >>>>>>>>> > >>>>>>>>> So 84 might be the current status. That would mean that someone > at > >>>>>>> Srarlink might be paying some attention, but it is a long way fro= m > >>>>> what > >>>>>>> Musk implied. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> PS: I forget the number of the RFC, but the number of packets > >>>>> queued on > >>>>>>> an egress link should be chosen by taking the hardware bottleneck > >>>>>>> throughput of any path, combined with an end-to-end Internet > >>>>> underlying > >>>>>>> delay of about 10 msec. to account for hops between source and > >>>>> destination. > >>>>>>> Lets say Starlink allocates 50 Mb/sec to each customer, packets a= re > >>>>> limited > >>>>>>> to 10,000 bits (1500 * 8), so the outbound queues should be limit= ed > >>>>> to > >>>>>>> about 0.01 * 50,000,000 / 10,000, which comes out to about 250 > >>>>> packets from > >>>>>>> each terminal of buffering, total, in the path from terminal to > >>>>> public > >>>>>>> Internet, assuming the connection to the public Internet is not a > >>>>> problem. > >>>>>>>> _______________________________________________ > >>>>>>>> Starlink mailing list > >>>>>>>> Starlink@lists.bufferbloat.net > >>>>>>>> > >>>>>>> > >>>>> > https://secure-web.cisco.com/1sNc_-1HhGCW7xdirt_lAoAy5Nn5T6UA85Scjn5BR7QH= Xtumhrf6RKn78SuRJG7DUKI3duggU9g6hJKW-Ze07HTczYqB9mBpIeALqk5drQ7nMvM8K7JbWfU= bPR7JSNrI75UjiNXQk0wslBfoOTvkMlRj5eMOZhps7DMGBRQTVAeTd5vwXoQtDgS6zLCcJkrcO2= S9MRSCC4f1I17SzgQJIwqo3LEwuN6lD-pkX0MFLqGr2zzsHw5eapd-VBlHu5reC4-OEn2zHkb7H= NzS1pcueF6tsUE1vFRsWs2SIOwU5MvbKe3J3Q6NRQ40cHI1AGd-i/https://lists.bufferbl= oat.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 > >>>> > >>>> _______________________________________________ > >>> 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 > --0000000000000dfcb905c76ff126 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No requirement for layer3 for that. I=E2=80=99d bet = money they=E2=80=99ll keep L3 out of space.=C2=A0
nb

On Sun, Jul 18, 2021 at 8:20 PM= David Lang <david@la= ng.hm> wrote:
Elon is talking about a viab= le path in the future being dishy - sat - sat -
dishy

They aren't there yet, but they are sure planning on it

David Lang

On Sun, 18 Jul 2021, Nick Buraglio wrote:

> We keep saying =E2=80=9Croute=E2=80=9D. What do we actually mean from = a network stack
> perspective? Are we talking about relaying light / frames / electric o= r do
> we mean actual packet routing, because there are obviously a lot of > important distinctions there.
> I=E2=80=99m willing to bet that there is no routing (as in layer 3 pac= ket routing)
> at all except the Dish NAT all the way into their peering data center.= The
> ground stations are very likely RF to fiber wave division back to a ca= rrier
> hotel with no L3 buffering at all. That keeps latency very low (think = O-E-O
> and E-O transitions) and moves L3 buffering to two locations and keeps= the
> terrestrial network very easy to make redundant (optical protection, e= tc.).
>
> nb
>
> On Fri, Jul 16, 2021 at 12:39 PM Jonathan Bennett <
> jona= thanbennett@hackaday.com> wrote:
>
>>
>>
>> On Fri, Jul 16, 2021, 12:35 PM Nathan Owens <nathan@nathan.io> wrote:
>>
>>> The other case where they could provide benefit is very long d= istance
>>> paths --- NY to Tokyo, Johannesburg to London, etc... but pres= umably at
>>> high cost, as the capacity will likely be much lower than subm= arine cables.
>>>
>>>>
>> Or traffic between Starlink customers. A video call between me and= someone
>> else on the Starlink network is going to be drastically better if = it can
>> route over the sats.
>>
>>>
>>>> On Fri, Jul 16, 2021 at 10:31 AM Mike Puchol <mike@starlink.sx> wro= te:
>>>
>>>> Satellite optical links are useful to extend coverage to a= reas where you
>>>> don=E2=80=99t have gateways - thus, they will introduce ad= ditional latency compared
>>>> to two space segment hops (terminal to satellite -> sat= ellite to gateway).
>>>> If you have terminal to satellite, two optical hops, then = final satellite
>>>> to gateway, you will have more latency, not less.
>>>>
>>>> We are being =E2=80=9Csold=E2=80=9D optical links for what= they are not IMHO.
>>>>
>>>> Best,
>>>>
>>>> Mike
>>>> On Jul 16, 2021, 19:29 +0200, Nathan Owens <nathan@nathan.io>, wrote:=
>>>>
>>>>> As there are more satellites, the up down time will ge= t closer to
>>>> 4-5ms rather then the ~7ms you list
>>>>
>>>> Possibly, if you do steering to always jump to the lowest = latency
>>>> satellite.
>>>>
>>>>> with laser relays in orbit, and terminal to terminal r= outing in orbit,
>>>> there is the potential for the theoretical minimum to tend= lower
>>>> Maybe for certain users really in the middle of nowhere, b= ut I did the
>>>> best-case math for "bent pipe" in Seattle area, = which is as good as it gets.
>>>>
>>>> On Fri, Jul 16, 2021 at 10:24 AM David Lang <david@lang.hm> wrote:
>>>>
>>>>> hey, it's a good attitude to have :-)
>>>>>
>>>>> Elon tends to set 'impossible' goals, miss the= timeline a bit, and come
>>>>> very
>>>>> close to the goal, if not exceed it.
>>>>>
>>>>> As there are more staellites, the up down time will ge= t closer to 4-5ms
>>>>> rather
>>>>> then the ~7ms you list, and with laser relays in orbit= , and terminal to
>>>>> terminal
>>>>> routing in orbit, there is the potential for the theor= etical minimum to
>>>>> tend
>>>>> lower, giving some headroom for other overhead but sti= ll being in the
>>>>> 20ms
>>>>> range.
>>>>>
>>>>> David Lang
>>>>>
>>>>>=C2=A0 =C2=A0On Fri, 16 Jul 2021, Nathan Owens wrote: >>>>>
>>>>>> Elon said "foolish packet routing" for t= hings over 20ms! Which seems
>>>>> crazy
>>>>>> if you do some basic math:
>>>>>>
>>>>>>=C2=A0 =C2=A0- Sat to User Terminal distance: 550-9= 50km air/vacuum: 1.9 - 3.3ms
>>>>>>=C2=A0 =C2=A0- Sat to GW distance: 550-950km air/va= cuum: 1.9 - 3.3ms
>>>>>>=C2=A0 =C2=A0- GW to PoP Distance: 50-800km fiber: = 0.25 - 4ms
>>>>>>=C2=A0 =C2=A0- PoP to Internet Distance: 50km fiber= : 0.25 - 0.5ms
>>>>>>=C2=A0 =C2=A0- Total one-way delay: 4.3 - 11.1ms >>>>>>=C2=A0 =C2=A0- Theoretical minimum RTT: 8.6ms - 22.= 2ms, call it 15.4ms
>>>>>>
>>>>>> This includes no transmission delay, queuing delay= ,
>>>>>> processing/fragmentation/reassembly/etc, and no ti= me-division
>>>>> multiplexing.
>>>>>>
>>>>>> On Fri, Jul 16, 2021 at 10:09 AM David Lang <david@lang.hm> wrot= e:
>>>>>>
>>>>>>> I think it depends on if you are looking at da= tacenter-to-datacenter
>>>>>>> latency of
>>>>>>> home to remote datacenter latency :-)
>>>>>>>
>>>>>>> my rule of thumb for cross US ping time has be= en 80-100ms latency
>>>>> (but
>>>>>>> it's been
>>>>>>> a few years since I tested it).
>>>>>>>
>>>>>>> I note that an article I saw today said that E= lon is saying that
>>>>> latency
>>>>>>> will
>>>>>>> improve significantly in the near future, that= up/down latency is
>>>>> ~20ms
>>>>>>> and the
>>>>>>> additional delays pushing it to the 80ms range= are 'stupid packet
>>>>> routing'
>>>>>>> problems that they are working on.
>>>>>>>
>>>>>>> If they are still in that level of optimizatio= n, it doesn't surprise
>>>>> me
>>>>>>> that
>>>>>>> they haven't really focused on the bufferb= loat issue, they have more
>>>>>>> obvious
>>>>>>> stuff to fix first.
>>>>>>>
>>>>>>> David Lang
>>>>>>>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0On Fri, 16 Jul 2021, Wheelock, Ian= wrote:
>>>>>>>
>>>>>>>> Date: Fri, 16 Jul 2021 10:21:52 +0000
>>>>>>>> From: "Wheelock, Ian" <ian.wheelock@comm= scope.com>
>>>>>>>> To: David Lang <david@lang.hm>, David P. Reed <dpreed@deepplum.com&= gt;
>>>>>>>> Cc: "starlink@lists.bufferbloat.net"= ; <
>>>>> starlink@lists.bufferbloat.net>
>>>>>>>> Subject: Re: [Starlink] Starlink and buffe= rbloat status?
>>>>>>>>
>>>>>>>> Hi David
>>>>>>>> In terms of the Latency that David (Reed) = mentioned for California
>>>>> to
>>>>>>> Massachusetts of about 17ms over the public in= ternet, it seems a bit
>>>>> faster
>>>>>>> than what I would expect. My own traceroute vi= a my VDSL link shows
>>>>> 14ms
>>>>>>> just to get out of the operator network.
>>>>>>>>
>>>>>>>> https://www.wondernetwork.com=C2= =A0 is a handy tool for checking
>>>>> geographic
>>>>>>> ping perf between cities, and it shows a min o= f about 66ms for pings
>>>>>>> between Boston and San Diego
>>>>>>> https://wondernetwork= .com/pings/boston/San%20Diego (so about 33ms
>>>>> for
>>>>>>> 1-way transfer).
>>>>>>>>
>>>>>>>> Distance wise this is about 4,100 KM (2,50= 0 M), and @2/3 speed of
>>>>> light
>>>>>>> (through a pure fibre link of that distance) t= he propagation time is
>>>>> just
>>>>>>> over 20ms. If the network equipment between th= e Boston and San Diego
>>>>> is
>>>>>>> factored in, with some buffering along the way= , 33ms does seem quite
>>>>>>> reasonable over the 20ms for speed of light in= fibre for that 1-way
>>>>> transfer
>>>>>>>>
>>>>>>>> -Ian Wheelock
>>>>>>>>
>>>>>>>> From: Starlink <starlink-bounces@lists= .bufferbloat.net> on behalf
>>>>> of
>>>>>>> David Lang <david@lang.hm>
>>>>>>>> Date: Friday 9 July 2021 at 23:59
>>>>>>>> To: "David P. Reed" <dpreed@deepplum.com&g= t;
>>>>>>>> Cc: "starlink@lists.bufferbloat.net"= ; <
>>>>> starlink@lists.bufferbloat.net>
>>>>>>>> Subject: Re: [Starlink] Starlink and buffe= rbloat status?
>>>>>>>>
>>>>>>>> IIRC, the definition of 'low latency&#= 39; for the FCC was something like
>>>>>>> 100ms, and Musk was predicting <40ms. rough= ly competitive with
>>>>> landlines,
>>>>>>> and worlds better than geostationary satellite= (and many
>>>>>>>> External (mailto:david@lang.hm)
>>>>>>>>
>>>>>>>
>>>>> https://shared.outlook.inky.co= m/report?id=3DY29tbXNjb3BlL2lhbi53aGVlbG9ja0Bjb21tc2NvcGUuY29tL2I1MzFjZDA4O= TZmMWI0Yzc5NzdiOTIzNmY3MTAzM2MxLzE2MjU4NzE1NDkuNjU=3D#key=3D19e8545676e28e5= 77c813de83a4cf1dc
>>>>>>>=C2=A0 https://www.inky.com/banner-faq/<= /a>=C2=A0 https://www.inky.com
>>>>>>>>
>>>>>>>> IIRC, the definition of 'low latency&#= 39; for the FCC was something like
>>>>>>> 100ms, and
>>>>>>>> Musk was predicting <40ms.
>>>>>>>>
>>>>>>>> roughly competitive with landlines, and wo= rlds better than
>>>>> geostationary
>>>>>>>> satellite (and many wireless ISPs)
>>>>>>>>
>>>>>>>> but when doing any serious testing of late= ncy, you need to be wired
>>>>> to
>>>>>>> the
>>>>>>>> router, wifi introduces so much variabilit= y that it swamps the
>>>>> signal.
>>>>>>>>
>>>>>>>> David Lang
>>>>>>>>
>>>>>>>> On Fri, 9 Jul 2021, David P. Reed wrote: >>>>>>>>
>>>>>>>>> Date: Fri, 9 Jul 2021 14:40:01 -0400 (= EDT)
>>>>>>>>> From: David P. Reed <dpreed@deepplum.com>
>>>>>>>>> To: starlink@lists.bufferbloat.net
>>>>>>>>> Subject: [Starlink] Starlink and buffe= rbloat status?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Early measurements of performance of S= tarlink have shown
>>>>> significant
>>>>>>> bufferbloat, as Dave Taht has shown.
>>>>>>>>>
>>>>>>>>> But...=C2=A0 Starlink is a moving targ= et. The bufferbloat isn't a
>>>>> hardware
>>>>>>> issue, it should be completely manageable, sta= rting by simple
>>>>> firmware
>>>>>>> changes inside the Starlink system itself. For= example, implementing
>>>>>>> fq_codel so that bottleneck links just drop pa= ckets according to the
>>>>> Best
>>>>>>> Practices RFC,
>>>>>>>>>
>>>>>>>>> So I'm hoping this has improved si= nce Dave's measurements. How
>>>>> much has
>>>>>>> it improved? What's the current maximum pa= cket latency under full
>>>>>>> load,=C2=A0 Ive heard anecdotally that a frien= d of a friend gets 84 msec.
>>>>> *ping
>>>>>>> times under full load*, but he wasn't usin= g flent or some other
>>>>> measurement
>>>>>>> tool of good quality that gives a true number.=
>>>>>>>>>
>>>>>>>>> 84 msec is not great - it's margin= al for Zoom quality experience
>>>>> (you
>>>>>>> want latencies significantly less than 100 mse= c. as a rule of thumb
>>>>> for
>>>>>>> teleconferencing quality). But it is better th= an Dave's measurements
>>>>> showed.
>>>>>>>>>
>>>>>>>>> Now Musk bragged that his network was = "low latency" unlike other
>>>>> high
>>>>>>> speed services, which means low end-to-end lat= ency.=C2=A0 That got him
>>>>>>> permission from the FCC to operate Starlink at= all. His number was, I
>>>>>>> think, < 5 msec. 84 is a lot more than 5. (= I didn't believe 5,
>>>>> because he
>>>>>>> probably meant just the time from the ground s= tation to the terminal
>>>>>>> through the satellite. But I regularly get 17 = msec. between
>>>>> California and
>>>>>>> Massachusetts over the public Internet)
>>>>>>>>>
>>>>>>>>> So 84 might be the current status. Tha= t would mean that someone at
>>>>>>> Srarlink might be paying some attention, but i= t is a long way from
>>>>> what
>>>>>>> Musk implied.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> PS: I forget the number of the RFC, bu= t the number of packets
>>>>> queued on
>>>>>>> an egress link should be chosen by taking the = hardware bottleneck
>>>>>>> throughput of any path, combined with an end-t= o-end Internet
>>>>> underlying
>>>>>>> delay of about 10 msec. to account for hops be= tween source and
>>>>> destination.
>>>>>>> Lets say Starlink allocates 50 Mb/sec to each = customer, packets are
>>>>> limited
>>>>>>> to 10,000 bits (1500 * 8), so the outbound que= ues should be limited
>>>>> to
>>>>>>> about 0.01 * 50,000,000 / 10,000, which comes = out to about 250
>>>>> packets from
>>>>>>> each terminal of buffering, total, in the path= from terminal to
>>>>> public
>>>>>>> Internet, assuming the connection to the publi= c Internet is not a
>>>>> problem.
>>>>>>>> __________________________________________= _____
>>>>>>>> Starlink mailing list
>>>>>>>> Starlink@lists.bufferbloat.net
>>>>>>>>
>>>>>>>
>>>>> https://secure-web.cisco.com/1sNc_-1HhGCW7xdirt_lAoAy5Nn= 5T6UA85Scjn5BR7QHXtumhrf6RKn78SuRJG7DUKI3duggU9g6hJKW-Ze07HTczYqB9mBpIeALqk= 5drQ7nMvM8K7JbWfUbPR7JSNrI75UjiNXQk0wslBfoOTvkMlRj5eMOZhps7DMGBRQTVAeTd5vwX= oQtDgS6zLCcJkrcO2S9MRSCC4f1I17SzgQJIwqo3LEwuN6lD-pkX0MFLqGr2zzsHw5eapd-VBlH= u5reC4-OEn2zHkb7HNzS1pcueF6tsUE1vFRsWs2SIOwU5MvbKe3J3Q6NRQ40cHI1AGd-i/https= ://lists.bufferbloat.net/listinfo/starlink
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>> Starlink mailing list
>>>>>>> Starlink@lists.bufferbloat.net
>>>>>>> https://lists.bufferbloa= t.net/listinfo/starlink
>>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listin= fo/starlink
>>>>
>>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/s= tarlink
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starl= ink
>>
>_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--0000000000000dfcb905c76ff126--