David P. Reed <dpr...@deepplum.com> wrote:
> SPRING (I thought) was just packet routing over a set of connected
> nodes that avoids creating routing tables. I.e. Source Packet RoutING.
I'm no expert on SPRING. I read enough to understand that I didn't care
about the debate in 6man (during RFC8200). I now just kill-file the thread.
So, yes it is, but I think it is loose source routing, so the micro-jumps can
take redundant paths. I could be wrong.
I think that the win for the silicon vendors is that everything is now IPv6
forwarding engine: no more MPLS, VLANs, IPv4, etc.
> 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.
I think that because SPRING does not (according to how some want to use it),
introduce a layer of tunnelling, the ECN bits are exactly where they need to
be. As long as the SPRING header is correctly undone at the edge (filling
the correct destination address back in), then the end node sees exactly what
we expect.
> 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.]
Agreed.
> 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.
They claim they will be able to play p2p first person shooters.
I don't know if this means e2e games, or ones that middlebox everything into
a server in a DC. That's what I keep asking.
> 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).
Agreed.
> 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.
Right, if you overprovision the network, and under-utilize it with CBR links,
then clearly you can get quality, at a high cost.
I don't think you can make a lot of money at this, because ultimately
terrestrial providers came in and ate that lunch.
--
] 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 [
signature.asc
Description: PGP signature
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
