From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp99.iad3a.emailsrvr.com (smtp99.iad3a.emailsrvr.com [173.203.187.99]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D782C3B29E for ; Fri, 12 Jun 2020 15:50:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1591991430; bh=LYkfUvlxfGW1fC+kfK5KNLUGg+RpNjWrawbKXC+Z1uY=; h=Date:Subject:From:To:From; b=v94wtEnx6AZMoK65J09X9+6A3vxKOTiw8znN8GkVbi+rJ541mHvwMnKkVs12bYWqr 4nU1PiQ4EodHV0nYdatC0Go6dBBbPlc1mtiAeCdqYRyKGrrE6YZrzhmFA2a6p/c4yZ PzsDunOCiC1afTnJ89vZmIKNR5PCjsI6YYU6FEUc= Received: from app53.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3EA0757F2; Fri, 12 Jun 2020 15:50:30 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app53.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 12 Jun 2020 15:50:30 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app53.wa-webapps.iad3a (Postfix) with ESMTP id 26078E009F; Fri, 12 Jun 2020 15:50:30 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Fri, 12 Jun 2020 15:50:30 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Fri, 12 Jun 2020 15:50:30 -0400 (EDT) From: "David P. Reed" To: "Michael Richardson" Cc: "Jonathan Morton" , "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20200612155030000000_56796" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <10734.1591975855@localhost> References: <1591891396.41838464@apps.rackspace.com> <1591901205.85717618@apps.rackspace.com> <10734.1591975855@localhost> Message-ID: <1591991430.15324444@apps.rackspace.com> X-Mailer: webmail/17.3.12-RC X-Classification-ID: c3879e9b-c017-41e0-b987-32e53a41f695-1-1 Subject: Re: [Bloat] FW: [Dewayne-Net] Ajit Pai caves to SpaceX but is still skeptical of Musk's latency claims X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 19:50:30 -0000 ------=_20200612155030000000_56796 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ASPRING (I thought) was just packet routing over a set of connected nodes= that avoids creating routing tables. I.e. Source Packet RoutING.=0ANow I h= appen to have written one of the earliest papers on source routing, and als= o authored the IP source routing options, explaining the advantages of usin= g Source Routing of several kinds. So I'm pretty familiar with Source Routi= ng in general as a concept.=0ABut though it does create a kind of short-ter= m path stability as well as efficient node level switching, there are two t= hings that affect congestion control that source routing doesn't deal with = very well.=0A =0ATCP's congestion control requires congestion signals, whic= h are an IP header function, not the switching layer undertneath. So how wi= ll SPRING identify congestion and report it? I assume that the entry and ex= it from the satellite mesh touches the IP header, and can also drop packets= , allowing, in principle packet drop and ECN to be provided. However, inter= mediate SPRING nodes may develop congestion, so they need to signal congest= ion "up" to the endpoints somehow, or avoid congestion entirely by never ov= er-allocating the nodes on a path. That requires global knowledge in SPRIN= G, and would be a "control plane" function.=0ABut if latency must be sustai= ned as low, the edges of the satellite network must respond very quickly t= o the changes in capacity demand. [this is why I suggested that each end-to= -end flow would be restricted to CBR, which underutilizes, potentially seve= rely, the capacity of the network if low latency guarantees are required.]= =0A =0AMaybe Musk's crew don't have ANY intention of providing low latency,= or they will go for slowly varying CBR routes that only admit packets at t= he rate pre-committed for each path.=0A =0ANailed up circuits in a dynamic = satellite network can be made to work, but don't do well with highly dynami= c traffic, like for example QUIC/HTTP/3. I'm assuming that the dreamers ins= pired by SpaceX's excited believers figure that "everything" will just be f= ast and low latency (I call 15 msec RTT withing the NA continent low latenc= y, some expect lower than that).=0A =0ATo me, SpaceX's satellite constellat= ion is the modern Iridium. A concept car built by a billionaire.who hopes i= t will work out. (Motorola's Iridium was a billionaire's dream, which event= ually didn't succeed, and was sold for scrap). We'll learn from it, and NSF= doesn't have the budget, nor does the Space Force (great TV series, hope t= he second season is produced).=0A =0AIridium didn't have congestion control= problems - it had battery issues so it didn't work on the dark side of ear= th very well - bot worked for a few very expensive phone calls at a time. B= ut coultn't recoup its investment, helping Motorola as a company fail. Bets= are great, but counting on a roulette wheel to produce 00 and pay out in o= ne spin - yeah, I'd bet rive bucks.=0A =0A =0AOn Friday, June 12, 2020 11:3= 0am, "Michael Richardson" said:=0A=0A=0A=0A> =0A> David = P. Reed wrote:=0A> > Now if the satellite manages eac= h flow from source to destination as a=0A> > "constant bitrate" virtual cir= cuit, like Iridium did (in their case=0A> > 14.4 kb/sec was the circuit rat= e, great for crappy voice, bad for=0A> > data), the Internet might work ove= r a set of wired-up circuits (lke=0A> > MPLS) where the circuits would be f= requently rebuilt (inside the=0A> > satellite constellation, transparent to= the Internet) so queuing delay=0A> > would be limited to endpoints of the = CBR circuits.=0A> =0A> That's what I think they will do.=0A> But, it might = be SPRING rather than MPLS.=0A> =0A> > But I doubt that is where they are g= oing. Instead, I suspect they=0A> > haven't thought about anything other th= an a packet at a time, with no=0A> > thought to reporting congestion by dro= ps or ECN.=0A> =0A> Agreed.=0A> =0A> > And it's super easy to build up seco= nds of lag on TCP if you don't=0A> > signal congestion. TCP just keeps open= ing its window, happy as a clam.=0A> =0A> --=0A> ] Never tell me the odds! = | ipv6 mesh networks [=0A> ] Michael Richardson, Sandelman Software Works |= IoT architect [=0A> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=0A> =0A> ------=_20200612155030000000_56796 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

SPRING (I thought) was= just packet routing over a set of connected nodes that avoids creating rou= ting tables. I.e. Source Packet RoutING.
Now I happen to have written = one of the earliest papers on source routing, and also authored the IP sour= ce routing options, explaining the advantages of using Source Routing of se= veral kinds. So I'm pretty familiar with Source Routing in general as a con= cept.

=0A

But though it does create a kind of short-= term path stability as well as efficient node level switching, there are tw= o things that affect congestion control that source routing doesn't deal wi= th very well.

=0A

 

=0A

= TCP's congestion control requires congestion signals, which are an IP heade= r function, not the switching layer undertneath. So how will SPRING identif= y congestion and report it? I assume that the entry and exit from the satel= lite mesh touches the IP header, and can also drop packets, allowing, in pr= inciple packet drop and ECN to be provided. However, intermediate SPRING no= des may develop congestion, so they need to signal congestion "up" to the e= ndpoints somehow, or avoid congestion entirely by never over-allocating the= nodes on a path.  That requires global knowledge in SPRING, and would= be a "control plane" function.

=0A

But if latency m= ust be sustained as low,  the edges of the satellite network must resp= ond very quickly to the changes in capacity demand. [this is why I suggeste= d that each end-to-end flow would be restricted to CBR, which underutilizes= , potentially severely, the capacity of the network if low latency guarante= es are required.]

=0A

 

=0A

Maybe Musk's crew don't have ANY intention of providing low latency, or= they will go for slowly varying CBR routes that only admit packets at the = rate pre-committed for each path.

=0A

 

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 10pt; overflow= -wrap: break-word;">Nailed up circuits in a dynamic satellite network can b= e made to work, but don't do well with highly dynamic traffic, like for exa= mple QUIC/HTTP/3. I'm assuming that the dreamers inspired by SpaceX's excit= ed believers figure that "everything" will just be fast and low latency (I = call 15 msec RTT withing the NA continent low latency, some expect lower th= an that).

=0A

 

=0A

To m= e, SpaceX's satellite constellation is the modern Iridium. A concept car bu= ilt by a billionaire.who hopes it will work out. (Motorola's Iridium was a = billionaire's dream, which eventually didn't succeed, and was sold for scra= p). We'll learn from it, and NSF doesn't have the budget, nor does the Spac= e Force (great TV series, hope the second season is produced).

=0A

 

=0A

Iridium didn't have conges= tion control problems - it had battery issues so it didn't work on the dark= side of earth very well - bot worked for a few very expensive phone calls = at a time. But coultn't recoup its investment, helping Motorola as a compan= y fail. Bets are great, but counting on a roulette wheel to produce 00 and = pay out in one spin - yeah, I'd bet rive bucks.

=0A

=  

=0A

 

=0A

On Frid= ay, June 12, 2020 11:30am, "Michael Richardson" <mcr@sandelman.ca> sa= id:

=0A
=0A

>
> David P. Reed <dpreed@deepplum.com> wrote:
&= gt; > Now if the satellite manages each flow from source to destination = as a
> > "constant bitrate" virtual circuit, like Iridium did (i= n their case
> > 14.4 kb/sec was the circuit rate, great for cra= ppy voice, bad for
> > data), the Internet might work over a set= of wired-up circuits (lke
> > MPLS) where the circuits would be= frequently rebuilt (inside the
> > satellite constellation, tra= nsparent to the Internet) so queuing delay
> > would be limited = to endpoints of the CBR circuits.
>
> That's what I think = they will do.
> But, it might be SPRING rather than MPLS.
>=
> > But I doubt that is where they are going. Instead, I suspe= ct they
> > haven't thought about anything other than a packet a= t a time, with no
> > thought to reporting congestion by drops o= r ECN.
>
> Agreed.
>
> > And it's supe= r easy to build up seconds of lag on TCP if you don't
> > signal= congestion. TCP just keeps opening its window, happy as a clam.
> =
> --
> ] Never tell me the odds! | ipv6 mesh networks [> ] Michael Richardson, Sandelman Software Works | IoT architect [> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
= >
>

=0A
 ------=_20200612155030000000_56796--