From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 3E73F3B29E for ; Fri, 16 Jul 2021 19:04:41 -0400 (EDT) Received: by mail-io1-xd29.google.com with SMTP id z11so12555839iow.0 for ; Fri, 16 Jul 2021 16:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nathan.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F4HrLmZVjVgPDblYLJVjtJrCE9YmWovZfas44thS3Tw=; b=zbrVzwT1DwVQcn33+Q+G0lCR5eGz2GPaCRjdxBOKVRep43oQ6jEE+nR3bXoOe64/v8 3GSJm9Cx5hKvwsdnxpj3W1YMmwon5saeVjT+kcPo5eCLbC5jEyYxOEKubcYnPf7cCO94 YqJS+eAgxwSYGrSFhFsNlEpDDvFRKuJIE+euk1gu6IpjaKxjk6rqjIhXKdtyYOtmEo34 QtxpA+79b3GL4/dqeNV7lP8I9WHTXnb8TG3LobGhW2rv8LHlS8T17flAWpXjtxC2Z7JU 1ZSVuS0AhXBAb4GKvfJrUEBe/OzmXIrYrYiN2phn+zqQzxBEqXllZ4HaQTboqDIr0h7q t5dg== 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=F4HrLmZVjVgPDblYLJVjtJrCE9YmWovZfas44thS3Tw=; b=L47Pcb/l6de37FN59BDMAM6enzWw3Ai5W1lmXYLpS6yN3iuqBeknHmPPcg4+9dJJ2G ZTneUFH+gNfeKLTbu8HoskNjTncqozWKkqtg2DnlXnVVkDVCucuAe/xpzCQ9I3onX3rp e7MZR18C9Z78FDLheO+6dZqBJ6lnmBYf8Sj8hu8VT3P54J3SJj5i1yDFpeSRwS2AkTO1 saby0mM5LpKtHL/CS7Ail2BsbTnKZNUxoc0DAx36gzJvz6p9OdERlDif+F2O9YT655SY NOc5pUvMW8NsUdBI/JpRfDVRgMAeCjx7v5RuVHavX72Tjy6yzFKIcRHxQptE/XM/Iydf TZsA== X-Gm-Message-State: AOAM530dVeUagjx+VArrN6OilbqOjnJQ5z9nRK/hKZqbgXv4ldev5Lav o8upmKH00nkbNkaFuq51C45fnQgnq1iCbuNRs1RqYw== X-Google-Smtp-Source: ABdhPJwKkuOORfPvsBFwUJvAoeckKh6EpJ+PVGqObSH62V2a8vD7VZZVnrBl4QB3uM5nqqxeAHZJDn4gWgdjqawyNu8= X-Received: by 2002:a02:8521:: with SMTP id g30mr10889113jai.113.1626476680466; Fri, 16 Jul 2021 16:04:40 -0700 (PDT) MIME-Version: 1.0 References: <1625856001.74681750@apps.rackspace.com> <33ae5470-a05a-484e-adc6-4baca6ede9ad@Spark> In-Reply-To: From: Nathan Owens Date: Fri, 16 Jul 2021 16:04:29 -0700 Message-ID: To: Jeremy Austin Cc: "David P. Reed" , Mike Puchol , "starlink@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary="000000000000c6658a05c7459c22" 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: Fri, 16 Jul 2021 23:04:41 -0000 --000000000000c6658a05c7459c22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Check out the NASA TBIRD mission coming up, 2x 100GbE coherent optics and an EDFA, beaming back to a 12in telescope on earth =E2=80=94 hopefully it w= orks! Basically all COTS components. On Fri, Jul 16, 2021 at 3:40 PM Jeremy Austin wrote: > I agree that RF is constrained in total capacity compared to optical > frequencies. At the risk of showing my ignorance by quoting from Wikipedi= a, > =E2=80=9CAtmospheric and fog attenuation, which are exponential in nature= , limit > practical range of FSO devices to several kilometres.=E2=80=9D > > Is there a safe and legal FSO mechanism that works over these distances > through atmosphere shell-to-ground? And the power requirements suitable f= or > a StarLink-sized single, solar-powered system? > > Optics through a vacuum (or near vacuum) are a totally different story. > Intra-satellite links make perfect sense once the cost comes down. > > Willing to be corrected but skeptical of the sky-to-ground link budget, > > Jeremy Austin > > On Fri, Jul 16, 2021 at 1:40 PM Mike Puchol wrote: > >> If we understand shell as =E2=80=9Cgroup of satellites at a certain alti= tude >> range=E2=80=9D, there is not much point in linking between shells if you= can link >> within one shell and orbital plane, and that plane has at least one >> satellite within range of a gateway. I could be proven wrong, but IMHO t= he >> first generation of links are meant of intra-plane, and maybe at a stret= ch >> cross-plane to the next plane East or West. >> >> The only way to eventually go is optical links to the ground too, as RF >> will only get you so far. At that stage, every shell will have its own >> optical links to the ground, with gateways placed in areas with little >> average cloud cover. >> >> Best, >> >> Mike >> On Jul 16, 2021, 23:30 +0200, David Lang , wrote: >> >> at satellite distances, you need to adjust your vertical direction >> depending on >> how far away the satellite you are talking to is, even if it's at the sa= me >> altitude >> >> the difference between shells that are only a few KM apart is less than >> the >> angles that you could need to satellites in the same shell further away. >> >> David Lang >> >> On Fri, 16 Jul 2021, Mike Puchol wrote: >> >> Date: Fri, 16 Jul 2021 22:57:14 +0200 >> From: Mike Puchol >> To: David Lang >> Cc: Nathan Owens , >> "starlink@lists.bufferbloat.net" , >> David P. Reed >> Subject: Re: [Starlink] Starlink and bufferbloat status? >> >> Correct. A mirror tracking head that turns around the perpendicular to >> the satellite path allows you to track satellites in the same plane, in >> front or behind, when they change altitude by a few kilometers as part o= f >> orbital adjustments or collision avoidance. To have a fully gimbaled hea= d >> that can track any satellite in any direction (and at any relative >> velocity!) is a totally different problem. I could see satellites linked= to >> the next longitudinal plane apart from those on the same plane, but >> cross-plane when one is ascending and the other descending is way harder= . >> The next shells will be at lower altitudes, around 300-350km, and they h= ave >> also stated they want to go for higher shells at 1000+ km. >> >> Best, >> >> Mike >> On Jul 16, 2021, 20:48 +0200, David Lang , wrote: >> >> I expect the lasers to have 2d gimbles, which lets them track most thing= s >> in >> their field of view. Remember that Starlink has compressed their orbital >> planes, >> they are going to be running almost everything in the 550km range >> (500-600km >> IIRC) and have almost entirely eliminated the ~1000km planes >> >> David Lang >> >> On Fri, 16 Jul 2021, >> Mike Puchol wrote: >> >> Date: Fri, 16 Jul 2021 19:42:55 +0200 >> From: Mike Puchol >> To: David Lang >> Cc: Nathan Owens , >> "starlink@lists.bufferbloat.net" , >> David P. Reed >> Subject: Re: [Starlink] Starlink and bufferbloat status? >> >> True, but we are then assuming that the optical links are a mesh between >> satellites in the same plane, plus between planes. From an engineering >> problem point of view, keeping optical links in-plane only makes the sys= tem >> extremely simpler (no full FOV gimbals with the optical train in them, f= or >> example), and it solves the issue, as it is highly likely that at least = one >> satellite in any given plane will be within reach of a gateway. >> >> Routing to an arbitrary gateway may involve passing via intermediate >> gateways, ground segments, and even using terminals as a hopping point. >> >> Best, >> >> Mike >> On Jul 16, 2021, 19:38 +0200, David Lang , wrote: >> >> the speed of light in a vaccum is significantly better than the speed of >> light >> in fiber, so if you are doing a cross country hop, terminal -> sat -> sa= t >> -> sat >> -> ground station (especially if the ground station is in the target >> datacenter) >> can be faster than terminal -> sat -> ground station -> cross-country >> fiber, >> even accounting for the longer distance at 550km altitude than at ground >> level. >> >> This has interesting implications for supplementing/replacing undersea >> cables as >> the sats over the ocean are not going to be heavily used, dedicated grou= nd >> stations could be setup that use sats further offshore than normal (and >> are >> shielded from sats over land) to leverage the system without interfering >> significantly with more 'traditional' uses >> >> David Lang >> >> On Fri, 16 Jul 2021, Mike Puchol wrote: >> >> Date: Fri, 16 Jul 2021 19:31:37 +0200 >> From: Mike Puchol >> To: David Lang , Nathan Owens >> Cc: "starlink@lists.bufferbloat.net" , >> David P. Reed >> Subject: Re: [Starlink] Starlink and bufferbloat status? >> >> Satellite optical links are useful to extend coverage to areas where you >> don=E2=80=99t have gateways - thus, they will introduce additional laten= cy compared >> to two space segment hops (terminal to satellite -> satellite to gateway= ). >> If you have terminal to satellite, two optical hops, then final satellit= e >> 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 the >> best-case math for "bent pipe" in Seattle area, which is as good as it g= ets. >> >> 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 terminal to >> terminal >> routing in orbit, there is the potential for the theoretical minimum to >> tend >> lower, giving some headroom for other overhead but still being in the 20= ms >> range. >> >> David Lang >> >> On Fri, 16 Jul 2021, Nathan Owens wrote: >> >> Elon said "foolish packet routing" for things over 20ms! Which seems cra= zy >> if you do some basic math: >> >> - Sat to User Terminal distance: 550-950km air/vacuum: 1.9 - 3.3ms >> - 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 routin= g' >> 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 >> Cc: "starlink@lists.bufferbloat.net" >> Subject: Re: [Starlink] Starlink and bufferbloat status? >> >> Hi David >> In terms of the Latency that David (Reed) mentioned for California 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 shows 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 of light >> >> (through a pure fibre link of that distance) the propagation time is jus= t >> 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-way >> transfer >> >> >> -Ian Wheelock >> >> From: Starlink on behalf of >> >> David Lang >> >> Date: Friday 9 July 2021 at 23:59 >> To: "David P. Reed" >> Cc: "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=3DY29tbXNjb3BlL2lhbi53aGVlbG9j= a0Bjb21tc2NvcGUuY29tL2I1MzFjZDA4OTZmMWI0Yzc5NzdiOTIzNmY3MTAzM2MxLzE2MjU4NzE= 1NDkuNjU=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 Bes= t >> 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. *pi= ng >> 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 experience (you >> >> want latencies significantly less than 100 msec. as a rule of thumb for >> teleconferencing quality). But it is better than Dave's measurements >> showed. >> >> >> Now Musk bragged that his network was "low latency" unlike other 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 h= e >> probably meant just the time from the ground station to the terminal >> through the satellite. But I regularly get 17 msec. between California a= nd >> 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 from 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 are >> limited >> to 10,000 bits (1500 * 8), so the outbound queues 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 public Internet is not a proble= m. >> >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> >> >> https://secure-web.cisco.com/1sNc_-1HhGCW7xdirt_lAoAy5Nn5T6UA85Scjn5BR7Q= HXtumhrf6RKn78SuRJG7DUKI3duggU9g6hJKW-Ze07HTczYqB9mBpIeALqk5drQ7nMvM8K7JbWf= UbPR7JSNrI75UjiNXQk0wslBfoOTvkMlRj5eMOZhps7DMGBRQTVAeTd5vwXoQtDgS6zLCcJkrcO= 2S9MRSCC4f1I17SzgQJIwqo3LEwuN6lD-pkX0MFLqGr2zzsHw5eapd-VBlHu5reC4-OEn2zHkb7= HNzS1pcueF6tsUE1vFRsWs2SIOwU5MvbKe3J3Q6NRQ40cHI1AGd-i/https://lists.bufferb= loat.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 >> > -- > > > > > > > Jeremy Austin > > Sr. Product Manager > > *Preseem | Aterlo Networks* > > Book a Call: https://app.hubspot.com/meetings/jeremy548 > > > > > 1 833 773 7336 x718 <1+833+773+7336+718> > jeremy@preseem.com > preseem.com > > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --000000000000c6658a05c7459c22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Check out the NASA TBIRD mission coming up, 2x 100GbE coh= erent optics and an EDFA, beaming back to a 12in telescope on earth =E2=80= =94 hopefully it works! Basically all COTS components.=C2=A0

=
On Fri, Ju= l 16, 2021 at 3:40 PM Jeremy Austin <jeremy@aterlo.com> wrote:
I agree that RF is constrained in total capacity compared to optical fr= equencies. At the risk of showing my ignorance by quoting from Wikipedia, = =E2=80=9C= Atmospheric and fog attenuation, which are exponential in nature, limit pra= ctical range of FSO devices to several kilometres.=E2=80=9D

Is there a safe and legal FSO mechanism that = works over these distances through atmosphere shell-to-ground? And the powe= r requirements suitable for a StarLink-sized single, solar-powered system?<= /span>

Optics through a vacuum (or = near vacuum) are a totally different story. Intra-satellite links make perf= ect sense once the cost comes down.=C2=A0

<= /div>
Willing to be corrected but skeptical of the sky-to-ground li= nk budget,

Jeremy Austin

On Fri, Jul 16, 2021 at 1:40 PM Mike Puchol <mike@starlink.sx> wrote:
If we understand shell as =E2=80=9Cgroup of satellites at= a certain altitude range=E2=80=9D, there is not much point in linking betw= een shells if you can link within one shell and orbital plane, and that pla= ne has at least one satellite within range of a gateway. I could be proven = wrong, but IMHO the first generation of links are meant of intra-plane, and= maybe at a stretch cross-plane to the next plane East or West.

The only way to eventually go is optical links to the ground too, as RF wil= l only get you so far. At that stage, every shell will have its own optical= links to the ground, with gateways placed in areas with little average clo= ud cover.

Best,

Mike
On Jul 16, 2021, 23:30 +0200, David Lang = <david@lang.hm>= ;, wrote:
at satellite di= stances, you need to adjust your vertical direction depending on
how far away the satellite you are talking to is, even if it's at the s= ame
altitude

the difference between shells that are only a few KM apart is less than the=
angles that you could need to satellites in the same shell further away.
David Lang

On Fri, 16 Jul 2021, Mike Puchol wrote:

Date: Fri, 16 Jul 2021 22:57:14 +0200
From: Mike Puchol <mike@starlink.sx>
To: David Lang <david= @lang.hm>
Cc: Nathan Owens <= nathan@nathan.io>,
"s= tarlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>= ,
David P. Reed <= dpreed@deepplum.com>
Subject: Re: [Starlink] Starlink and bufferbloat status?

Correct. A mirror tracking head that turns around the perpendicular to the = satellite path allows you to track satellites in the same plane, in front o= r behind, when they change altitude by a few kilometers as part of orbital = adjustments or collision avoidance. To have a fully gimbaled head that can = track any satellite in any direction (and at any relative velocity!) is a t= otally different problem. I could see satellites linked to the next longitu= dinal plane apart from those on the same plane, but cross-plane when one is= ascending and the other descending is way harder. The next shells will be = at lower altitudes, around 300-350km, and they have also stated they want t= o go for higher shells at 1000+ km.

Best,

Mike
On Jul 16, 2021, 20:48 +0200, David Lang <david@lang.hm>, wrote:
I expect the lasers to have 2d gimbles, which let= s them track most things in
their field of view. Remember that Starlink has compressed their orbital pl= anes,
they are going to be running almost everything in the 550km range (500-600k= m
IIRC) and have almost entirely eliminated the ~1000km planes

David Lang

On Fri, 16 Jul 2021,
Mike Puchol wrote:

Date: Fri, 16 Jul 2021 19:42:55 +0200
From: Mike Puchol <mike@starlink.sx>
To: David Lang <david= @lang.hm>
Cc: Nathan Owens <= nathan@nathan.io>,
"s= tarlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>= ,
David P. Reed <= dpreed@deepplum.com>
Subject: Re: [Starlink] Starlink and bufferbloat status?

True, but we are then assuming that the optical links are a mesh between sa= tellites in the same plane, plus between planes. From an engineering proble= m point of view, keeping optical links in-plane only makes the system extre= mely simpler (no full FOV gimbals with the optical train in them, for examp= le), and it solves the issue, as it is highly likely that at least one sate= llite in any given plane will be within reach of a gateway.

Routing to an arbitrary gateway may involve passing via intermediate gatewa= ys, ground segments, and even using terminals as a hopping point.

Best,

Mike
On Jul 16, 2021, 19:38 +0200, David Lang <david@lang.hm>, wrote:
the speed of light in a vaccum is significantly b= etter than the speed of light
in fiber, so if you are doing a cross country hop, terminal -> sat ->= sat -> sat
-> ground station (especially if the ground station is in the target dat= acenter)
can be faster than terminal -> sat -> ground station -> cross-coun= try fiber,
even accounting for the longer distance at 550km altitude than at ground le= vel.

This has interesting implications for supplementing/replacing undersea cabl= es as
the sats over the ocean are not going to be heavily used, dedicated ground<= br> stations could be setup that use sats further offshore than normal (and are=
shielded from sats over land) to leverage the system without interfering significantly with more 'traditional' uses

David Lang

On Fri, 16 Jul 2021, Mike Puchol wrote:

Date: Fri, 16 Jul 2021 19:31:37 +0200
From: Mike Puchol <mike@starlink.sx>
To: David Lang <david= @lang.hm>, Nathan Owens <nathan@nathan.io>
Cc: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net= >,
David P. Reed <= dpreed@deepplum.com>
Subject: Re: [Starlink] Starlink and bufferbloat status?

Satellite optical links are useful to extend coverage to areas where you do= n=E2=80=99t have gateways - thus, they will introduce additional latency co= mpared to two space segment hops (terminal to satellite -> satellite to = gateway). If you have terminal to satellite, two optical hops, then final s= atellite 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 IMH= O.

Best,

Mike
On Jul 16, 2021, 19:29 +0200, Nathan Owens <nathan@nathan.io>, wrote:
As there are more satellites, the up down time wi= ll 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 termi= nal 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 the best= -case math for "bent pipe" in Seattle area, which is as good as i= t gets.

On Fri, Jul 16, 2021 at 10:24 AM David Lang <<= a href=3D"mailto:david@lang.hm" target=3D"_blank">david@lang.hm> wro= te:
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 rat= her
then the ~7ms you list, and with laser relays in orbit, and terminal to ter= minal
routing in orbit, there is the potential for the theoretical minimum to ten= d
lower, giving some headroom for other overhead but still being in the 20ms<= br> range.

David Lang

=C2=A0 On Fri, 16 Jul 2021, Nathan Owens wrote:

Elon said "foolish packet routing" for = things over 20ms! Which seems crazy
if you do some basic math:

=C2=A0 =C2=A0- Sat to User Terminal distance: 550-950km air/vacuum: 1.9 - 3= .3ms
=C2=A0 =C2=A0- Sat to GW distance: 550-950km air/vacuum: 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 time-division multiplexing.=

On Fri, Jul 16, 2021 at 10:09 AM David Lang <david@lang.hm> wrote:

I think it depends on if you are looking at datac= enter-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 routi= ng'
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


=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@commscope.com>
To: David Lang <david= @lang.hm>, 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 California 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 shows 14ms
just to get out of the operator network.

https://www.won= dernetwork.com=C2=A0 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 of 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-way transfe= r

-Ian Wheelock

From: Starlink <starlink-bounces@lists.bufferbloat.net> on behal= f of
David Lang <david@lan= g.hm>
Date: Friday 9 July 2021 at 23:59
To: "David P. Reed" <dpreed@deepplum.com>
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 lik= e
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=3DY29tbXNjb3BlL2lhbi53aGVlbG9j= a0Bjb21tc2NvcGUuY29tL2I1MzFjZDA4OTZmMWI0Yzc5NzdiOTIzNmY3MTAzM2MxLzE2MjU4NzE= 1NDkuNjU=3D#key=3D19e8545676e28e577c813de83a4cf1dc
=C2=A0 https= ://www.inky.com/banner-faq/=C2=A0 https://www.inky.com

IIRC, the definition of 'low latency' for the FCC was something lik= e
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
<= /blockquote> 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 <dpreed@deepplum.com>
To: sta= rlink@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...=C2=A0 Starlink is a moving target. The bufferbloat isn't a hardw= are
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,=C2=A0 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 measure= ment
tool of good quality that gives a true number.

84 msec is not great - it's marginal for Zoom quality experience (you
want latencies significantly less than 100 msec. as a rule of thumb for
teleconferencing quality). But it is better than Dave's measurements sh= owed.

Now Musk bragged that his network was "low latency" unlike other = high
speed services, which means low end-to-end latency.=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, becau= se 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<= br> 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 from 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 are limited=
to 10,000 bits (1500 * 8), so the outbound queues 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 public Internet is not a problem.<= br>
_______________________________________________ Starlink mailing list
Starlin= k@lists.bufferbloat.net

https://secure-web.ci= sco.com/1sNc_-1HhGCW7xdirt_lAoAy5Nn5T6UA85Scjn5BR7QHXtumhrf6RKn78SuRJG7DUKI= 3duggU9g6hJKW-Ze07HTczYqB9mBpIeALqk5drQ7nMvM8K7JbWfUbPR7JSNrI75UjiNXQk0wslB= foOTvkMlRj5eMOZhps7DMGBRQTVAeTd5vwXoQtDgS6zLCcJkrcO2S9MRSCC4f1I17SzgQJIwqo3= LEwuN6lD-pkX0MFLqGr2zzsHw5eapd-VBlHu5reC4-OEn2zHkb7HNzS1pcueF6tsUE1vFRsWs2S= IOwU5MvbKe3J3Q6NRQ40cHI1AGd-i/https://lists.bufferbloat.net/listinfo/starli= nk

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


_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--


=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0= =C2=A0=C2=A0
<= /td>

=C2=A0 =C2=A0 =C2=A0Jeremy Austin

=C2=A0 =C2=A0 =C2=A0 Sr. Product Manager

=C2=A0 =C2=A0 =C2=A0=C2=A0Preseem | Aterlo Networks

=C2=A0 =C2=A0 =C2=A0 Book a Call:=C2= =A0https://app.hubspot.com/meeting= s/jeremy548=C2=A0

=




<= td style=3D"padding:0px;font-family:Arial">jeremy@preseem.com
1 833 773 7336 x718
<= tbody style=3D"font-family:Arial">
<= /td>		preseem.com

=C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

=
_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--000000000000c6658a05c7459c22--