Re: [nwcrg] nwcrg Digest, Vol 43, Issue 11

[Marie-Jose Montpetit <[e-mail]>]

Interesting topic. See my comments inline.


> On May 11, 2017, at 1:59 PM, [e-mail] wrote:
> 
> Send nwcrg mailing list submissions to
> 	[e-mail]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.irtf.org/mailman/listinfo/nwcrg
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
> 
> You can reach the person managing the list at
> 	[e-mail]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nwcrg digest..."
> Today's Topics:
> 
>   1. Closeup on a "Generic Robust Low Latency Tunnelling"
>      (Vincent Roca)
>   2. Re: Closeup on a "Generic Robust Low Latency Tunnelling"
>      (Emmanuel Lochin)
> 
> From: Vincent Roca <[e-mail]>
> Subject: [nwcrg] Closeup on a "Generic Robust Low Latency Tunnelling"
> Date: May 11, 2017 at 10:22:58 AM EDT
> To: [e-mail]
> 
> 
> 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.
And the current taxonomy document will help with definitions of terms like symbol and payload :-)
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-taxonomy/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-taxonomy/>
> 
> 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
Is this like a coded QIC? Then we should at least add compatibility with encryption and IPSEC. 
>  
> 
> 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.
Agree. There should be one I-D per available code when they are not already covered by FECFRAME.
> 
> 
> 	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.
Would be interesting to see the losses associated with padding. Maybe short packets could be coded together (with a potential hit on performance).
> 
> 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.
I am aware of work there. I will leave the authors to respond.

> 	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?
Where is storage addressed? And of course what I mentioned above for encryption.

This work/document(s) would be a very good output for the group.

mjm
> 
> 
> 
> 
> From: Emmanuel Lochin <[e-mail]>
> Subject: Re: [nwcrg] Closeup on a "Generic Robust Low Latency Tunnelling"
> Date: May 11, 2017 at 1:53:48 PM EDT
> To: [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] <mailto:[e-mail]>
>> https://www.irtf.org/mailman/listinfo/nwcrg <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 <http://www.isae-supaero.fr/>
> Tel [phone] - Fax [phone]
> 
> 
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg