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--