Re: [EToSat] Packet lost on last mile network?

["Border, John" <[e-mail]>]

Sigh!  The “niche” perception is a constant battle for satellite networks.  There are millions of users but that is small when compared to the overall size of the Internet.  (This could spin into a digital divide discussion but that doesn’t seem appropriate for an IETF mailing list.)  One of the advantages of a satellite network is the management aspects since the remote site terminals are right next to the customers.  On the other, avoiding ossification takes conscious effort.

One of the reasons why we look at in the network solutions is that we are in the network.  Tuning user devices is often possible to improve performance.  But, except for customers with experts, it is generally not feasible.  What we are looking for is end to end mechanisms that can adapt themselves.  I think QUIC has better hooks to do this than TCP did.  But, we have the problem of incentivizing the developers of the “ends” to do it.  I have been thinking about that problem for a while now but I still don’t have any good answers…


John


From: EToSat <[e-mail]> On Behalf Of Christian Huitema
Sent: Wednesday, May 20, 2020 2:10 PM
To: Carsten Bormann <[e-mail]>
Cc: [e-mail]; Nitay Argov <[e-mail]>; Kuhn Nicolas <[e-mail]>
Subject: Re: [EToSat] Packet lost on last mile network?

**EXTERNAL EMAIL**




On 5/20/2020 9:56 AM, Carsten Bormann wrote:

And, if they are only deployed in a

fraction of the Wi-Fi network, then the transport folks will still need

an end-to-end solution.

They sure will.  But that never can be as good as local recovery.

In a nutshell, that's the entire discussion of end-to-end vs middle-boxes.

It is always possible to do a local optimization by adding some intelligence in the network. That's the case for pretty much all middle boxes, and it seems that the proxies envisaged in Loop fall into that category. But there are always downsides, such as management, flexibility, and most importantly ossification by old proxies prone to bit rot.

Given effort, it is almost always possible to find end-to-end solutions that are "good enough", getting you within 90% of the optimum or some such. FEC as tail probe would be one example of that. The end-to-end solutions also tend to get better over time, as implementers devise more clever algorithms and update the code. All it takes is some motivation that the effort is important.

An example of that would be support for cellular networks. Twenty years ago, this was a niche, and TCP was not optimized for it. Hence the deployment of middle-boxes in the cellular networks. But as this became an ever more important scenario, TCP improved, and QUIC will improve over that. The cellular middle-boxes become harder to justify, and will start moving from the "optimization" to the "hindrance" category.

Satellite networks are a peculiar case. They remain very much a niche application to this day, something like a communication media of last resort in places that fiber or cellular cannot reach. Given the niche status, it is unclear whether end-to-end transports will bother implementing optimized algorithms, even when these are available. But it is also unclear whether "mainline" networks will bother deploying middle-boxes solely for the benefit of the satellite niche, which kinds of rules out solutions like 'deploy a box in every Wi-Fi network'. 'Deploy a proxy at the ground station' might work, because the satellite operator has the right business incentives, but of course that requires nodes to still do something special for satellites, i.e., discover the proxy and use it. Not obvious.

Hence my effort to look at end-to-end solutions covering not just the satellite case, but also other long distance networks such as intercontinental connections. These are still niches today, given VPN, but they are still useful for P2P applications. Given enough niches, there might be enough motivation for doing the effort.

-- Christian Huitema