[Bloat] FW: [Dewayne-Net] Ajit Pai caves to SpaceX but is still skeptical of Musk's latency claims

[David P. Reed]

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

> > On 11 Jun, 2020, at 7:03 pm, David P. Reed <dpreed at deepplum.com>
> wrote:
> >
> > So, what do you think the latency (including bloat in the satellites) will
> be? My guess is > 2000 msec, based on the experience with Apple on ATT Wireless
> back when it was rolled out (at 10 am, in each of 5 cities I tested, repeatedly
> with smokeping, for 24 hour periods, the ATT Wireless access network experienced
> ping time grew to 2000 msec., and then to 4000 by mid day - true lag-under-load,
> with absolutely zero lost packets!)
> >
> > I get that SpaceX is predicting low latency by estimating physical distance
> and perfect routing in their LEO constellation. Possibly it is feasible to achieve
> this if there is zero load over a fixed path. But networks aren't physical, though
> hardware designers seem to think they are.
> >
> > Anyone know ANY reason to expect better from Musk's clown car parade?
> 
> Speaking strictly from a theoretical perspective, I don't see any reason why they
> shouldn't be able to offer latency that is "normally" below 100ms (to a regional
> 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 physical distance. All that is needed is
> to keep queue delays reasonably under control, and there's any number of AQMs that
> can help with that. Clearly ATT Wireless did not perform any bufferbloat
> mitigation at all.
> 
> I have no insight or visibility into anything they're *actually* doing, though. 
> Can anyone dig up anything about that?
> 
> - Jonathan Morton
> 
> 
They seem to be radio silent on anything about 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 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 predicting this issue.
 
1. Why ATT's HSPA+ (4G) network back when iPhone was 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 bloat 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 and ALU) who denied that bufferbloat existed at all at IETF.
Eventually, I got access to talk to ATT's lower level Network Operations folks, who replicated my findings. But up to that point, I was a target of Donovan's smear campaign secondary to Apple.
 
2. Is there any research at all on congestion management with constantly changing routing, and its stability? Remember, TCP is tuned tightly to assume that every packet takes the identical route, and therefore it doesn't back off quickly. I believe there is no solid research on this.
 
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 Internet might work over a set of wired-up circuits (lke MPLS) where the circuits would be frequently rebuilt (inside the satellite constellation, transparent to the Internet) so queuing delay would be limited to endpoints of the CBR circuits.
 
But I doubt that is where they are 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.
 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20200611/3f7a545d/attachment-0001.html>