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

Hi all,

We have uploaded an initial version to state about problems and opportunities for LOOPS. It is mainly focusing on the usage scenario about using cloud based nodes to build overlay based WAN path to achieve higher reliability and performance.
Local in-network recovery is a main element of LOOPS. 
EToSat might have similar requirements for some intermediate network nodes to provide LOOPS like functions.

You may find the relevant information below.

Thanks,
Yizhou

Name:		draft-li-tsvwg-loops-problem-opportunities
Revision:	00
Title:		LOOPS (Localized Optimization of Path Segments) Problem Statement and Opportunities
Document date:	2019-03-05
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-li-tsvwg-loops-problem-opportunities-00.txt
Status:         https://datatracker.ietf.org/doc/draft-li-tsvwg-loops-problem-opportunities/
Htmlized:       https://tools.ietf.org/html/draft-li-tsvwg-loops-problem-opportunities-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-tsvwg-loops-problem-opportunities

Abstract:
   Various overlay tunnels are used in networks including WAN,
   enterprise campus and others.  End to end paths are partitioned into
   multiple segments using overlay tunnels to achieve better path
   selection, lower latency and so on.  Traditional end-to-end transport
   layers respond to packet loss slowly especially in long-haul
   networks: They either wait for some signal from the receiver to
   indicate a loss and then retransmit from the sender or rely on
   sender's timeout which is often quite long.

   LOOPS (Localized Optimization of Path Segments) attempts to provide
   non end-to-end local based in-network recovery to achieve better data
   delivery by making packet loss recovery faster.  In an overlay
   network scenario, LOOPS can be performed over the existing, or
   purposely created, overlay tunnel based path segments.

   This document illustrates the slow packet loss recovery problems
   LOOPS tries to solve in some use cases and analyzes the impacts when
   local in-network recovery is employed as a LOOPS mechanism.

-----Original Message-----
From: EToSat [mailto:etosat-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: Tuesday, February 12, 2019 3:50 PM
To: Jeremy Harris <jgh@wizmail.org>
Cc: etosat@ietf.org
Subject: Re: [EToSat] about LOOPS(Localized Optimization of Path Segments) and etosat

On Feb 11, 2019, at 17:20, Jeremy Harris <jgh@wizmail.org> 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

_______________________________________________
EToSat mailing list
EToSat@ietf.org
https://www.ietf.org/mailman/listinfo/etosat