Subject: Re: [nwcrg] Coding for QUIC: Source Symbols Identifier

From: François Michel <[email-masked]>
Date: Sun, 13 May 2018 19:20:20 +0000

Thank you for your answer and sorry for my late response.

2018-04-30 12:34 GMT+02:00 Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>:
>
> Our goal is to allow any FEC scheme to be accommodated hence the “negotiation phase” that we use to determine the actual scheme.  BTW XOR was used at the beginning of QUIC but if you look at the loss patterns over the Internet, XORs are extremely ineffective and cost a lot of capacity. One may say XORs are not FEC either. We are looking at block and window (fixed and sliding). Your suggestion of a convolutional-like code is welcome. You should look at the RLC FECFRAME: https://tools.ietf.org/html/draft-ietf-tsvwg-fecframe-ext-01. In the RG we have 2 drafts that describe some network level code (Tetrys and RLNC) with RLNC having the feature of in-network re-encoding so not e2e FEC.

I completely agree. I mentioned XOR as an example of block codes that would benefit from interleaving. If interleaving is considered, then maybe only relying on a sequence number and the encoding window could be problematic. I am thus wondering if it would not be interesting to let the underlying FEC Scheme define the source symbol ID on its own instead of considering it as a sequence number in the protocol, as it is currently defined in the draft 00. If we refer to FECFRAME and its related FEC Schemes, we can see that the Reed Solomon FEC Scheme encodes its block number into the Source FEC Payload ID, for example (RFC6865). However, I agree that using sliding-window codes looks promising and in this case, a simple sequence number is enough.

>
> As for the identification of raw QUIC packets we are moving to a stream-based and not packet based scheme to be more efficient. FECFRAME in one of our inspiration and Vincent Roca was the driver behind it’s development.

Allright, a stream frames-based FEC can indeed be interesting to define FEC-protected and non FEC-protected QUIC streams, in addition mitigate/avoid packet fragmentation.

>
> We are planning a major design effort starting this week and will update the document accordingly.  We can continue the discussion in the mean time.
>

This is the reason why I sent my first mail, the idea is to have public discussions about coding-for-quic in order to allow anybody interested to participate, as QUIC is quite a hot topic.

Thank you,

François

________________________________
From: Marie-Jose Montpetit <[email-masked]>
Sent: 30 April 2018 12:34:17
To: François Michel
Cc: [email-masked]
Subject: Re: [nwcrg] Coding for QUIC: Source Symbols Identifier

Our goal is to allow any FEC scheme to be accommodated hence the “negotiation phase” that we use to determine the actual scheme.  BTW XOR was used at the beginning of QUIC but if you look at the loss patterns over the Internet, XORs are extremely ineffective and cost a lot of capacity. One may say XORs are not FEC either. We are looking at block and window (fixed and sliding). Your suggestion of a convolutional-like code is welcome. You should look at the RLC FECFRAME: https://tools.ietf.org/html/draft-ietf-tsvwg-fecframe-ext-01. In the RG we have 2 drafts that describe some network level code (Tetrys and RLNC) with RLNC having the feature of in-network re-encoding so not e2e FEC.

As for the identification of raw QUIC packets we are moving to a stream-based and not packet based scheme to be more efficient. FECFRAME in one of our inspiration and Vincent Roca was the driver behind it’s development.

We are planning a major design effort starting this week and will update the document accordingly.  We can continue the discussion in the mean time.

mjm

> On Apr 30, 2018, at 5:17 AM, François Michel <[email-masked]> wrote:
>
> Hi,
>
> My name is François Michel. I am from Belgium and I am currently working on an implementation (and design) concerning the use of QUIC for real-time communications, where coding can improve the performances significantly.
>
> As there is now a direction to take with the coding-for-quic draft, I think it would be interesting to begin public discussions on the mailing list about its concretisation into the QUIC protocol.
>
> One first aspect that could be discussed is the field used to identify the Source Symbols (i.e. raw QUIC packets) mentioned in the section 2.1 of the draft.
>
> I think that the format of this field could benefit from not being too specific to some kind of FEC Scheme. In my opinion, a field that works for different kinds of Block and Convolutional FEC Schemes is a nice way to go: the specification could offer a 32 or 64-bits field without specifying it furthermore and let the underlying FEC Scheme use it to encode some scheme-specific values. This is the approach taken by FECFRAME, where the precise format of the FEC Payload ID is defined by the FEC Scheme and not the framework.
>
> For example, Block FEC Schemes could thus encode a Source Block ID in this field (that would allow a simple FEC Scheme like XOR to perform interleaving and thus handle loss bursts), and some PRNG-based FEC Schemes could encode their seed in it as well.
>
> It would be great to hear your opinion about this topic and discuss to move towards the new version of the draft.
>
>
> Regards,
>
> François
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg