Re: [EToSat] about LOOPS(Localized Optimization of Path Segments) and etosat

[Carsten Bormann <[e-mail]>]

On Feb 11, 2019, at 17:20, Jeremy Harris <[e-mail]> wrote:
> 
> On 08/02/2019 10:23, Ludovic THOMAS wrote:
>> FWIU, solutions to improve the slow start without cutting a QUIC
>> connection will require cross-layer interactions.
> 
> Strawman: an advisory notification from the LOOPS endpoint,
> on connection startup, with bandwidth and delay data, intended
> for use by the TCP endpoint in setting an early value for CWND
> (or the bbr equivalent).  Possibly an ICMP?

Well, initial CWND must be chosen so that it doesn’t cause damage on any node on the entire end-to-end path.  A single LOOPS midpoint node can’t know all the information needed to provide such an assurance.

Getting ahead information from the path was thought through in RFC 4872 Quick-Start.
This spec is not very deployable today because it relies on IP options.
But even if that were not a problem, getting consensus from all the nodes on the path would still be hard, and would violate the deployment economy maxim of providing incremental benefit.
(LOOPS could actually help here by taking sub-paths managed by LOOPS out of the picture, but still the other nodes would have to deploy.)

TCP splitting for satellites works because the ramp-up in the low-RTT first (pre-satellite) path segment is independent from the ramp-up in the following ones; the splitting node simply promises to provide any buffer space needed (which, worst case, can cause buffer bloat).  We would need to provide LOOPS mid-point nodes with ways to manage congestion up to the receiving endpoint to achieve the same effect, and that is not possible without a close interaction with the end-to-end transport (or global deployment of mid-to-end LOOPS, which is not even on the agenda currently).

Grüße, Carsten