From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B3A993B2A4 for ; Wed, 31 Aug 2022 17:17:22 -0400 (EDT) Received: from app67.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 332B925290; Wed, 31 Aug 2022 17:17:22 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app67.wa-webapps.iad3a (Postfix) with ESMTP id 1FCD360172; Wed, 31 Aug 2022 17:17:22 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 31 Aug 2022 17:17:22 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Wed, 31 Aug 2022 17:17:22 -0400 (EDT) From: "David P. Reed" To: "David Lang" Cc: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20220831171722000000_84243" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <7q848925-o6qn-1934-n4s9-n493n9sp9op9@ynat.uz> References: <1661975488.138231368@apps.rackspace.com> <7q848925-o6qn-1934-n4s9-n493n9sp9op9@ynat.uz> X-Client-IP: 209.6.168.128 Message-ID: <1661980642.127124118@apps.rackspace.com> X-Mailer: webmail/19.0.18-RC X-Classification-ID: 130dd6a9-2be8-40b7-b9b3-6e5b4414c782-1-1 Subject: Re: [Starlink] Starlink "beam spread" 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: Wed, 31 Aug 2022 21:17:22 -0000 ------=_20220831171722000000_84243 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AA couple clarifications below on what I meant.=0A =0AOn Wednesday, Augus= t 31, 2022 4:28pm, "David Lang" said:=0A=0A=0A=0A> On Wed, = 31 Aug 2022, David P. Reed via Starlink wrote:=0A> =0A> > My point is that = the discussion here has focused entirely on achievable=0A> bitrate maximum,= with no load and no burstiness.=0A> =0A> well, to be fair, some of that is= in response to 'just looking at the bitrate,=0A> starlink cannot possibly = perform well' posts=0AWho said that? Well a couple of the people who respon= ded to my initial post about beam spread being the wrong way to look at thi= s seemed to decide they wanted to say that.=0A=0A> =0A> > This isn't fixed = by having more spatial control, to the extent that is=0A> > possible.=0A> = =0A> agreed, the spactial control discussion is just a response to 'it can'= t=0A> possibly...' posts=0AActually, the beam spread (the colorful plots an= d analysis discussing that that Dave Taht highlighted as being important), = is all about "spatial control". That was my original point.=0A =0A> =0A> > = It *is* fixable by suitable Automatic Queue Management in the=0A> > satelli= te path (which will be the "bottleneck link" between the home and the=0A> >= public Internet), plus suitable end-to-end protocol congestion management= =0A> that=0A> > responds to drops or ECN. (I don't know if the satellite lo= oks at the packet=0A> > hard enough and has enough state to set the ECN bit= or that it has enough=0A> > state to achieve bloom filter based fair queue= dropping).=0A> =0A> if the sats are going to have the ability to route thr= ough other satellites,=0A> they have to be looking at the packets, and once= you start doing that, looking=0A> at ECN should not be a significant load.= =0A =0AI agree, but to do good queue management (especially avoiding starva= tion of some flows) you need to decide what packets on which to set ECN. Th= at means you have to consider the current set of packets in some detail, wh= ich requires storing state about some number of IP flows. That's a lot more= processing than just looking at a bit. That's what I am referring to here,= and I assumed anyone who knows about ECN and AQM and how it works would un= derstand that.=0A =0AI'm not going to reason from "intersatellite" routing = being operational until they offer it in operation. It's feasible, sort of.= Laser beam aiming is quite different from phased array beam steering, and = though they may have tested it between two satellites, that makes it a "lin= k technology" not a network. (you can steer a laser beam by moving lightwei= ght mirrors, I know. But tracking isn't so easy when both satellites are mo= ving relative to each other - it seems like way beyond the technology base = that Starlink has put in its satellites so far. But who knows.=0A----------= ----=0AAs far as "intersatellite" routing being out there soon, well, there= 's no evidence it's happening soon. The one thing that may be an indication= is that Starlink is claiming it will have achieved extensive maritime cove= rage in 2023. Since that can't be achieved by placing ground stations over = all the oceans involved so that ships can get one "bounce" to some ground s= tation attached to fiber, I'm guessing they may be providing such service b= y some additional satellite based"backbone" in space.=0A =0AGiven the low d= ensity of ships, and the fact that ships currently happily tolerate long sp= ace delays in the ways they currently offer Internet service far at sea, us= ing "geosynchronous" two way systems positioned in fixed locations over the= oceans, it's possible that the Starlink constellation might be using some = "backbone" of another structure to get a one hop to groundstation repeater.= These wouldn't be LEO, and they might not even be Starlink owned. That's a= ll guesswork on my part.=0A =0AStarlink is very eager to provide coverage a= t sea because it is a huge marketing win, and probably doable without too m= uch effort. They announced a partnership with Royal Carribean a couple days= ago.=0A =0ASatellite "mesh routing" doesn't need to be made to work to pro= vide maritime service away from land. If there's not too much aggregate loa= d.=0A =0AWhat's interesting to me is that their coverage map definitely doe= sn't cover Africa, South America, Cuba, large parts of Asia, and it isn't p= lanned - if they had "mesh routing" working among satellites, those would b= e easy. But instead, they seem to be focused on the satellite one-bounce ar= chitecture (what the satellite industry calls "bent-pipe" however it is don= e).=0A =0AA reason we don't do dynamic mesh routing in the public internet = is that backbone concentration works very well as an engineering solution. = I suspect that the Starlink guys are taking the lower risk path.=0A=0A> =0A= > David Lang_______________________________________________=0A> Starlink ma= iling list=0A> Starlink@lists.bufferbloat.net=0A> https://lists.bufferbloat= .net/listinfo/starlink=0A> ------=_20220831171722000000_84243 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A couple clarification= s below on what I meant.

=0A

 

=0A

On Wednesday, August 31, 2022 4:28pm, "David Lang" <david@l= ang.hm> said:

=0A
=0A

> On Wed, 31 Aug 2022, David P. Reed via Starlink wrote= :
>
> > My point is that the discussion here has focuse= d entirely on achievable
> bitrate maximum, with no load and no bur= stiness.
>
> well, to be fair, some of that is in response= to 'just looking at the bitrate,
> starlink cannot possibly perfor= m well' posts

=0A

Who said that? Well a couple of th= e people who responded to my initial post about beam spread being the wrong= way to look at this seemed to decide they wanted to say that.

=0A


>
> > This isn't fixed by having more s= patial control, to the extent that is
> > possible.
> > agreed, the spactial control discussion is just a response to 'it = can't
> possibly...' posts

=0A

Actually, the= beam spread (the colorful plots and analysis discussing that that Dave Tah= t highlighted as being important), is all about "spatial control". That was= my original point.

=0A

 

=0A

>
> > It *is* fixable by suitable Automatic Queue Mana= gement in the
> > satellite path (which will be the "bottleneck = link" between the home and the
> > public Internet), plus suitab= le end-to-end protocol congestion management
> that
> > = responds to drops or ECN. (I don't know if the satellite looks at the packe= t
> > hard enough and has enough state to set the ECN bit or tha= t it has enough
> > state to achieve bloom filter based fair que= ue dropping).
>
> if the sats are going to have the abilit= y to route through other satellites,
> they have to be looking at t= he packets, and once you start doing that, looking
> at ECN should = not be a significant load.

=0A

 

=0A

I agree, but to do good queue management (especially avoiding = starvation of some flows) you need to decide what packets on which to set E= CN. That means you have to consider the current set of packets in some deta= il, which requires storing state about some number of IP flows. That's a lo= t more processing than just looking at a bit. That's what I am referring to= here, and I assumed anyone who knows about ECN and AQM and how it works wo= uld understand that.

=0A

 

=0A

I'm not going to reason from "intersatellite" routing being operatio= nal until they offer it in operation. It's feasible, sort of. Laser beam ai= ming is quite different from phased array beam steering, and though they ma= y have tested it between two satellites, that makes it a "link technology" = not a network. (you can steer a laser beam by moving lightweight mirrors, I= know. But tracking isn't so easy when both satellites are moving relative = to each other - it seems like way beyond the technology base that Starlink = has put in its satellites so far. But who knows.

=0A

--------------

=0A

As far as "intersatellite" routi= ng being out there soon, well, there's no evidence it's happening soon. The= one thing that may be an indication is that Starlink is claiming it will h= ave achieved extensive maritime coverage in 2023. Since that can't be achie= ved by placing ground stations over all the oceans involved so that ships c= an get one "bounce" to some ground station attached to fiber, I'm guessing = they may be providing such service by some additional satellite based"backb= one" in space.

=0A

 

=0A

Given the low density of ships, and the fact that ships currently happily = tolerate long space delays in the ways they currently offer Internet servic= e far at sea, using "geosynchronous" two way systems positioned in fixed lo= cations over the oceans, it's possible that the Starlink constellation migh= t be using some "backbone" of another structure to get a one hop to grounds= tation repeater. These wouldn't be LEO, and they might not even be Starlink= owned. That's all guesswork on my part.

=0A

 <= /p>=0A

Starlink is very eager to provide coverage at se= a because it is a huge marketing win, and probably doable without too much = effort. They announced a partnership with Royal Carribean a couple days ago= .

=0A

 

=0A

Satellite "m= esh routing" doesn't need to be made to work to provide maritime service aw= ay from land. If there's not too much aggregate load.

=0A

 

=0A

What's interesting to me is that th= eir coverage map definitely doesn't cover Africa, South America, Cuba, larg= e parts of Asia, and it isn't planned - if they had "mesh routing" working = among satellites, those would be easy. But instead, they seem to be focused= on the satellite one-bounce architecture (what the satellite industry call= s "bent-pipe" however it is done).

=0A

 

=0A=

A reason we don't do dynamic mesh routing in the publi= c internet is that backbone concentration works very well as an engineering= solution. I suspect that the Starlink guys are taking the lower risk path.=

=0A


>
> David Lang_______________= ________________________________
> Starlink mailing list
> = Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/list= info/starlink
>

=0A
 ------=_20220831171722000000_84243--