SPRING (I thought) was just packet routing over a set of connected nodes that avoids creating routing 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 source routing options, explaining the advantages of using Source Routing of several kinds. So I'm pretty familiar with Source Routing in general as a concept. But though it does create a kind of short-term path stability as well as efficient node level switching, there are two things that affect congestion control that source routing doesn't deal with very well. TCP's congestion control requires congestion signals, which are an IP header function, not the switching layer undertneath. So how will SPRING identify congestion and report it? I assume that the entry and exit from the satellite mesh touches the IP header, and can also drop packets, allowing, in principle packet drop and ECN to be provided. However, intermediate SPRING nodes may develop congestion, so they need to signal congestion "up" to the endpoints 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. But if latency must be sustained as low, the edges of the satellite network must respond very quickly to the changes in capacity demand. [this is why I suggested that each end-to-end flow would be restricted to CBR, which underutilizes, potentially severely, the capacity of the network if low latency guarantees are required.] 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. Nailed up circuits in a dynamic satellite network can be made to work, but don't do well with highly dynamic traffic, like for example QUIC/HTTP/3. I'm assuming that the dreamers inspired by SpaceX's excited 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 than that). To me, SpaceX's satellite constellation is the modern Iridium. A concept car built 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 scrap). We'll learn from it, and NSF doesn't have the budget, nor does the Space Force (great TV series, hope the second season is produced). Iridium didn't have congestion 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 company 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. On Friday, June 12, 2020 11:30am, "Michael Richardson" <m...@sandelman.ca> said:
> > David P. Reed <dpr...@deepplum.com> wrote: > > 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. > > 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 suspect they > > haven't thought about anything other than a packet at a time, with no > > thought to reporting congestion by drops or ECN. > > Agreed. > > > 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. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > >
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
