Re: New Version Notification for draft-michel-quic-fec-00.txt

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

And in nwcrg we had tried to avoid physical layer terms - I know channel is
still there but we are more talking about a “link”.

It’s nits.

Marie-José Montpetit, Ph.D.
[e-mail]



From: François Michel <[e-mail]>
<[e-mail]>
Reply: François Michel <[e-mail]>
<[e-mail]>
Date: November 4, 2022 at 4:39:22 AM
To: Nicolas Kuhn <[e-mail]> <[e-mail]>
Cc: [e-mail] <[e-mail]> <[e-mail]>, Olivier Bonaventure
<[e-mail]> <[e-mail]>,
Marie-Jose
Montpetit <[e-mail]> <[e-mail]>,
[e-mail] <[e-mail]>
<[e-mail]>, Samuel Hurst <[e-mail]>
<[e-mail]>
Subject:  Re: New Version Notification for draft-michel-quic-fec-00.txt

Hi Nico,

On 26/10/22 10:04, Nicolas Kuhn wrote:
> Dear François, all,
>
> Thank you for this document. This is very important for the
> lossy-GEO-satellite scenario, so thank you!
>
> I have some questions/comments on the document :
> - Taxonomy : you may want to refer to RFC8406 on the taxonomy related to
> coding
> - On the coding channel :
>   "A coding channel can be seen as a
>    communication channel between a QUIC receiver and a FEC decoder."
>   => This is in contradiction with the notion proposed in RFC 9265.
>   I think that the coding channel should be seen between the FEC-coder
> and the FEC-decoder.

True, I should avoid those ambiguities. :-)

> - The notion of APP_DATA in Figure 1 is not clear to me. IMHO the
> presentation on this should be improved.

I've put APP_DATA to represent any data sent by applications transiting
through streams or datagrams. We sould find a way to make it easy to
understand that the APP_DATA are part of the source symbols.

> - On DATAGRAMS : I agree that if a solution can also protect DATAGRAMS,
> this could help in lossy scenarios
> - "In this document,
>    we propose to consider whole frames as part of the source symbols."
>   => This is important and should be highlighted in the document. It
> may be worth expliciting what is meant by "whole frames" and maybe
> provide examples.
> - Alternative 1 vs Alternative 2 : alternative 2 has an impact on the
> QUIC packet scheduler. For this reason, I am not sure whether it is
> relevant.

(+Sam that might be interested as we had similar discussions on another
mail loop)
I also prefer a bit the concepts behind Alternative 1 but it may seem
harder to implement than Alternative 2 and introduces the concept of
wrapped frames that may be puzzling too. I guess time and implementations
may tell us which alternative is the best with running code.

>
> I hope this helps,

This helps ! Thank you for your comments.

Franz

> Kind regards,
>
> Nicolas
>
> On Fri, Oct 21, 2022 at 2:50 PM François Michel
> <[e-mail] <mailto:[e-mail]>>
wrote:
>
> Dear all,
>
> Here is a draft discussing the addition of Forward Erasure
> Correction to
> QUIC.
>
> We wrote this draft to discuss FEC in QUIC and experiment with people.
> It is inspired by our previous work at the nwcrg. We also have
> interesting real-network results that we would be happy to show to
> motivate the interest for this extension.
>
> The design is at an early stage and is intended to evolve. Do not
> hesitate to provide us with comments on the document or the
> extension in
> general.
>
> Regards,
>
> François
>
>
> -------- Message transféré --------
> Sujet : New Version Notification for draft-michel-quic-fec-00.txt
> Date : Fri, 21 Oct 2022 05:11:22 -0700
> De : [e-mail] <mailto:[e-mail]>
> Pour : François Michel <[e-mail]
> <mailto:[e-mail]>>, Francois Michel
> <[e-mail]
> <mailto:[e-mail]>>, Olivier Bonaventure
> <[e-mail]
> <mailto:[e-mail]>>, Olivier Bonaventure
> <[e-mail]
> <mailto:[e-mail]>>
>
>
> A new version of I-D, draft-michel-quic-fec-00.txt
> has been successfully submitted by François Michel and posted to the
> IETF repository.
>
> Name:           draft-michel-quic-fec
> Revision:       00
> Title:          Forward Erasure Correction for QUIC loss recovery
> Document date:  2022-10-21
> Group:          Individual Submission
> Pages:          14
> URL: https://www.ietf.org/archive/id/draft-michel-quic-fec-00.txt
> <https://www.ietf.org/archive/id/draft-michel-quic-fec-00.txt>> Status:
https://datatracker.ietf.org/doc/draft-michel-quic-fec
> <https://datatracker.ietf.org/doc/draft-michel-quic-fec>> Html:
> https://www.ietf.org/archive/id/draft-michel-quic-fec-00.html
> <https://www.ietf.org/archive/id/draft-michel-quic-fec-00.html>>
Htmlized:
> https://datatracker.ietf.org/doc/html/draft-michel-quic-fec
> <https://datatracker.ietf.org/doc/html/draft-michel-quic-fec>>
> Abstract:
>     This documents lays down the QUIC protocol design considerations
>     needed for QUIC to apply Forward Erasure Correction on the data
> sent
>     through the network.
>
>
>
>
> The IETF Secretariat
>
>