From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp88.iad3a.emailsrvr.com (smtp88.iad3a.emailsrvr.com [173.203.187.88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6B9653B29D for ; Thu, 11 Jun 2020 14:46:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1591901206; bh=PxRTK1xa6RQS9ZtjhODw+ec5IbWa13Zsj3sfvRmaf4A=; h=Date:Subject:From:To:From; b=NcHT66X7Er0TG0UkJGEM1oGDIbToFpBBa0JYW2UYuzgDXFkWtTDweVtnvYdSxlH4P WrjZbgDmPa6vaX/77Zxrg7+fu+7hJannw0I5eHelmMR9rkX1tT0NJdTyQ+oWby5741 tH+ugWQjD5HwIg6n8zGiQp0xqnGDJrGXEET14qas= Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E8B3C5472; Thu, 11 Jun 2020 14:46:45 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 11 Jun 2020 14:46:46 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app40.wa-webapps.iad3a (Postfix) with ESMTP id D1FB86007D; Thu, 11 Jun 2020 14:46:45 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 11 Jun 2020 14:46:45 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Thu, 11 Jun 2020 14:46:45 -0400 (EDT) From: "David P. Reed" To: "Jonathan Morton" Cc: "Dave Taht" , "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20200611144645000000_96152" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1591891396.41838464@apps.rackspace.com> Message-ID: <1591901205.85717618@apps.rackspace.com> X-Mailer: webmail/17.3.12-RC X-Classification-ID: 9ed1d06a-5927-4ef8-abd7-5d783f8a4423-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: Thu, 11 Jun 2020 18:46:46 -0000 ------=_20200611144645000000_96152 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AOn Thursday, June 11, 2020 12:14pm, "Jonathan Morton" said:=0A =0A=0A> > On 11 Jun, 2020, at 7:03 pm, David P. Reed =0A> wrote:=0A> >=0A> > So, what do you think the latency (in= cluding bloat in the satellites) will=0A> be? My guess is > 2000 msec, base= d on the experience with Apple on ATT Wireless=0A> back when it was rolled = out (at 10 am, in each of 5 cities I tested, repeatedly=0A> with smokeping,= for 24 hour periods, the ATT Wireless access network experienced=0A> ping = time grew to 2000 msec., and then to 4000 by mid day - true lag-under-load,= =0A> with absolutely zero lost packets!)=0A> >=0A> > I get that SpaceX is p= redicting low latency by estimating physical distance=0A> and perfect routi= ng in their LEO constellation. Possibly it is feasible to achieve=0A> this = if there is zero load over a fixed path. But networks aren't physical, thou= gh=0A> hardware designers seem to think they are.=0A> >=0A> > Anyone know A= NY reason to expect better from Musk's clown car parade?=0A> =0A> Speaking = strictly from a theoretical perspective, I don't see any reason why they=0A= > shouldn't be able to offer latency that is "normally" below 100ms (to a r= egional=0A> PoP, not between two arbitrary points on the globe). The satell= ites will be much=0A> closer to any given ground station than a GEO satelli= te, the latter typically=0A> adding 500ms to the path due mostly to physica= l distance. All that is needed is=0A> to keep queue delays reasonably under= control, and there's any number of AQMs that=0A> can help with that. Clear= ly ATT Wireless did not perform any bufferbloat=0A> mitigation at all.=0A> = =0A> I have no insight or visibility into anything they're *actually* doing= , though. =0A> Can anyone dig up anything about that?=0A> =0A> - Jonathan M= orton=0A> =0A> =0AThey seem to be radio silent on anything about their arch= itecture. Given that they are hardware guys for the most part, and given th= at even the bulk of IETF membership are clueless on the congestion control = topic, and given that LEO satellite constellation management for high-speed= packet networks has never been demonstrated at scale, that's why I'm predi= cting this issue.=0A =0A1. Why ATT's HSPA+ (4G) network back when iPhone wa= s introduced matters: ATT consistently denied, at the VP level, that there = was a problem. They blamed it at first on Apple! (John Donovan produced all= this blaming rhertoric.) What was new? HSPA+ was a packet network - prior = cellular was circuit-switched. Circuit switched networks don't introduce bl= oat into a circuit usualy - though Frame Relay could be set up so it stored= rather than dropped data providing "no loss" at the cost of delay. And the= actual suppliers of ATT's network were well-known companies (like Cisco an= d ALU) who denied that bufferbloat existed at all at IETF.=0AEventually, I = got access to talk to ATT's lower level Network Operations folks, who repli= cated my findings. But up to that point, I was a target of Donovan's smear = campaign secondary to Apple.=0A =0A2. Is there any research at all on conge= stion management with constantly changing routing, and its stability? Remem= ber, TCP is tuned tightly to assume that every packet takes the identical r= oute, and therefore it doesn't back off quickly. I believe there is no soli= d research on this.=0A =0ANow if the satellite manages each flow from sourc= e to destination as a "constant bitrate" virtual circuit, like Iridium did = (in their case 14.4 kb/sec was the circuit rate, great for crappy voice, ba= d for data), the Internet might work over a set of wired-up circuits (lke M= PLS) where the circuits would be frequently rebuilt (inside the satellite c= onstellation, transparent to the Internet) so queuing delay would be limite= d to endpoints of the CBR circuits.=0A =0ABut I doubt that is where they ar= e going. Instead, I suspect they haven't thought about anything other than = a packet at a time, with no thought to reporting congestion by drops or ECN= .=0A =0AAnd it's super 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. ------=_20200611144645000000_96152 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thursday, June 11, = 2020 12:14pm, "Jonathan Morton" <chromatix99@gmail.com> said:

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 10pt; overflow= -wrap: break-word;"> 

=0A
=0A

> > On 11 Jun, 2020, at 7:03 pm, David P. Reed <dpr= eed@deepplum.com>
> wrote:
> >
> > So, wha= t do you think the latency (including bloat in the satellites) will
&g= t; be? My guess is > 2000 msec, based on the experience with Apple on AT= T Wireless
> back when it was rolled out (at 10 am, in each of 5 ci= ties I tested, repeatedly
> with smokeping, for 24 hour periods, th= e ATT Wireless access network experienced
> ping time grew to 2000 = msec., and then to 4000 by mid day - true lag-under-load,
> with ab= solutely zero lost packets!)
> >
> > I get that Space= X is predicting low latency by estimating physical distance
> and p= erfect routing in their LEO constellation. Possibly it is feasible to achie= ve
> this if there is zero load over a fixed path. But networks are= n't physical, though
> hardware designers seem to think they are.> >
> > Anyone know ANY reason to expect better from M= usk's clown car parade?
>
> Speaking strictly from a theor= etical perspective, I don't see any reason why they
> shouldn't be = able to offer latency that is "normally" below 100ms (to a regional
&g= t; PoP, not between two arbitrary points on the globe). The satellites will= be much
> closer to any given ground station than a GEO satellite,= the latter typically
> adding 500ms to the path due mostly to phys= ical distance. All that is needed is
> to keep queue delays reasona= bly under control, and there's any number of AQMs that
> can help w= ith that. Clearly ATT Wireless did not perform any bufferbloat
> mi= tigation at all.
>
> I have no insight or visibility into = anything they're *actually* doing, though.
> Can anyone dig up any= thing about that?
>
> - Jonathan Morton
>
&g= t;

=0A

They seem to be radio silent on anything abo= ut their architecture. Given that they are hardware guys for the most part,= and given that even the bulk of IETF membership are clueless on the conges= tion control topic, and given that LEO satellite constellation management f= or high-speed packet networks has never been demonstrated at scale, that's = why I'm predicting this issue.

=0A

 

=0A

1. Why ATT's HSPA+ (4G) network back when iPhone was intro= duced matters: ATT consistently denied, at the VP level, that there was a p= roblem. They blamed it at first on Apple! (John Donovan produced all this b= laming rhertoric.) What was new? HSPA+ was a packet network - prior cellula= r was circuit-switched. Circuit switched networks don't introduce bloat int= o a circuit usualy - though Frame Relay could be set up so it stored rather= than dropped data providing "no loss" at the cost of delay. And the actual= suppliers of ATT's network were well-known companies (like Cisco and ALU) = who denied that bufferbloat existed at all at IETF.

=0A

Eventually, I got access to talk to ATT's lower level Network Operation= s folks, who replicated my findings. But up to that point, I was a target o= f Donovan's smear campaign secondary to Apple.

=0A

&= nbsp;

=0A

2. Is there any research at all on congest= ion management with constantly changing routing, and its stability? Remembe= r, TCP is tuned tightly to assume that every packet takes the identical rou= te, and therefore it doesn't back off quickly. I believe there is no solid = research on this.

=0A

 

=0A

Now if the satellite manages each flow from source to destination as a = "constant bitrate" virtual circuit, like Iridium did (in their case 14.4 kb= /sec was the circuit rate, great for crappy voice, bad for data), the Inter= net might work over a set of wired-up circuits (lke MPLS) where the circuit= s would be frequently rebuilt (inside the satellite constellation, transpar= ent to the Internet) so queuing delay would be limited to endpoints of the = CBR circuits.

=0A

 

=0A

= But I doubt that is where they are going. Instead, I suspect they haven't t= hought about anything other than a packet at a time, with no thought to rep= orting congestion by drops or ECN.

=0A

 

=0A=

And it's super 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.

=0A
 ------=_20200611144645000000_96152--