Re: [nwcrg] Closeup on a "Generic Robust Low Latency Tunnelling"

[Emmanuel Lochin <[e-mail]>]

Hi Vincent, all,

This is indeed a good idea and following your draft, there are plenty of 
things to discuss for each item. I am interested in all points raised 
but first by 3.1, 3.2 and 3.3.
Considering only 3.2 (otherwise this email could be too long too read ;) 
I am currently working on this with Tetrys/Tunnel. In particular, there 
are a bunch of results from the QoS epoch, used by ISP (e.g. the 
well-known core scheduling defined in RFC5865), allowing to schedule, 
and mark a given traffic to separate flows that have different QoS 
requirements. I reckon that scheduling and differentiating flows (e.g. 
differentiate video from VoIP from bulk data) is mandatory to correctly 
protect them before tunneling. It would be a good thing to discuss and 
share our experience on this.
So yes... I'm strongly interested.

Emmanuel



On 11/05/2017 16:22, Vincent Roca wrote:
> Hello everybody,
>
> In the high level overview of potential work items that could be 
> addressed in our RG, I mentioned:
>
>> Use-cases where end-to-end coding or network coding can be beneficial:
>>
>> […]
>> - Robust, low latency tunnels: this could be the basis of a generic 
>> protocol
>
> Here are some more details. As usual, everything is open to discussions.
> And if you’re interested, it would be great to create a dedicated team 
> and work
> jointly on some of the topics.
>
> Since I’m familiar with FECFRAME, you’ll find a few references. But 
> the goal here
> is really to have something more versatile.
>
> Cheers,
>
>   Vincent
>
> ------
>
> *Generic Robust Low Latency Tunnelling*
>
> *1- goals*
>
>     Provide a solution for robust, low latency transport of one or
>     several flows over several types of
>     communication links (physical or virtual/overlay). Can be
>     regarded as a « robust virtual link » or
>     « robust tunnel » depending on how it is used.
>
>     Various possibilities:
>     - may be unicast or multicast, potentially targeting massive delivery
>     - may include feedbacks or not
>     - may include in-network recoding or not
>
>
> *2- a few issues already solved*
> (inspired from FECFRAME, RFC 6363. Do other efficient approaches exist?)
> *
> *
> *2.1- use of FEC*
> *
> *
>
>     Sliding window linear coding schemes are good target FEC codes.
>     Yet the solution must be FEC Scheme
>     agnostic in order to be compatible with different types of FEC
>     schemes (sliding window codes or block codes).
>     Move all FEC considerations in specific I-Ds.
>
>
>
> *2.2- "application payloads" are of variable size*
>
>
>     (P)MTU considerations are always key aspects with tunnels
>     (additional headers can lead to IP fragmentation,
>     usually considered harmful). If the « application payload » size
>     is managed elsewhere, the symbol size is
>     under our control. From this perspective, padding each
>     « application payload » up to the (P)MTU (minus
>     various protocol headers) and having symbols of that maximum size
>     is sub-optimal because:
>     (1) all repair packets have that size even if « application
>     payloads » are very short;
>     (2) with high speed links that permit very large MTUs, it becomes
>     prohibitive.
>
>     FECFRAME / FEC Schemes provide a solution for that: use small
>     fixed size symbols and create a
>     mapping between « application payloads »  and symbols. To the
>     « application payload » we add a
>     length field and we pad the whole until it is multiple of the
>     symbol size. A small « application payload »
>     might correspond to a single source symbol while a large one may
>     correspond to multiple ones.
>
>     NB: a small symbol size is a good technique for asymptotically
>     good block codes like LDPC or Raptor
>     codes, but counter productive with sliding window codes (it
>     increases the linear system size).
>     NB: FEC Schemes also enable several repair symbols to be carried
>     in a single repair packet, with a single
>     repair header in that case. So this is not too much penalising
>     from this point of view.
>     NB: « application payloads » are called ADUs in RFC 6363.
>
>
>
> *2.3- assignment of decoded "application payloads" to flows in 
> multi-flow configurations*
>
>     With multiple flows multiplexed in the same tunnel, the problem is
>     to assign a decoded payload to the
>     right flow (UDP port numbers/IP addresses used to map application
>     payloads to flows are not necessarily
>     recovered depending on how tunnelling is applied).
>
>     FECFRAME provides a simple generic solution: each « application
>     payload » is prepended with a flow
>     identifier (1 byte) before doing the mapping to source symbols.
>     This (flow ID + length
>     + application payload + padding) is FEC protected. After decoding
>     at a destination, the flow ID is recovered
>     and the application payload assigned to the flow it belongs to.
>
>     NB: the flow ID + length + application payload + padding (called
>     ADUI in RFC 6363) is used for FEC
>     encoding but never sent in the tunnel. Only the « application
>     payload » plus a dedicated header/trailer
>     is sent.
>
>
>
> *3- a few open questions (potentially to be extended)*
> *
> *
> **NB: FECFRAME does not address the following items (out of scope).
> *
> *
> *3.1- congestion control and fairness requirements*
>
>
>     This is a tough question and may be the most complex and
>     controversial one.
>
>     Another requirement is not to mask congestion signals while
>     recovering from packet losses. It requires a
>     close integration between FEC decoder and congestion control/rate
>     adaptation component… Not very difficult.
>
> *3.2- flow scheduling when several flows share the same tunnel*
>
>     Flows may have different requirements in terms of time and robustness.
>
>     How to serve them within a single, shared tunnel?
>
>
> *3.3- exploiting several (high speed, low speed, or heterogeneous) paths*
>
>
>     A multipath capable solution is a plus and the use of FEC coding
>     will help a lot. There’s probably
>     interesting packet scheduling research to carry out. How should
>     the traffic be scheduled on the various
>     paths. How can it compare to MPTCP where FEC coding is absent?
>
>     An open question: in case of very high speed paths, can it compete
>     with simpler solutions where only
>     source packets are exchanged? Said differently, to which point is
>     FEC coding compatible with
>     very high speed transfers? With what compromise?
>
> *3.4- exploiting in-network recoding*
>
>
>     To what extent is it needed? Are there additional requirements?
>
>
> *3.5- exploiting feedbacks*
>
>
>     When is it required and for what purpose? What type of feedbacks?
>     Can it be a key differentiator
>     between proposals?
>     It is at least a key differentiator with FECFRAME (no feedback at
>     all in the core protocol).
>
>
> *Something else?*
>
>
>
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg

-- 
Emmanuel LOCHIN
Professeur ISAE

ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr
Tel [phone] - Fax [phone]