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

From: Vincent Roca <[email-masked]>
Date: Thu, 11 May 2017 16:22:58 +0200

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?

---

From: Emmanuel Lochin <[email-masked]>
Date: Thu, 11 May 2017 19:53:48 +0200

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:
> *Generic Robust Low Latency Tunnelling*
>
> *1- goals*
>
> *2- a few issues already solved*
> *
> *
> *2.1- use of FEC*
> *
> *
>     agnostic in order to be compatible with different types of FEC
>     schemes (sliding window codes or block codes).
> *2.2- "application payloads" are of variable size*
>
>
>     (P)MTU considerations are always key aspects with tunnels
>     (additional headers can lead to IP fragmentation,
>     under our control. From this perspective, padding each
>     « application payload » up to the (P)MTU (minus
>     length field and we pad the whole until it is multiple of the
>     symbol size. A small « application payload »
> *2.3- assignment of decoded "application payloads" to flows in 
> multi-flow configurations*
>
>     + application payload + padding) is FEC protected. After decoding
>     at a destination, the flow ID is recovered
>     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*
>
>
>     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*
>
> *3.3- exploiting several (high speed, low speed, or heterogeneous) paths*
>
>
> *3.4- exploiting in-network recoding*
>
>
> *3.5- exploiting feedbacks*
>
>
> *Something else?*
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> 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 +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30