Re: [nwcrg] RG Last Call for "Coding and congestion control in transport"

[roca <[e-mail]>]

Dear Nicolas and Authors,

Thank you for this update, I’m happy with your modifications.
With Marie-Jose we think the new version of this document is now available for next step and we’ll submit it to IRSG soon.

Cheers, 

     Marie-Jose and Vincent


> Le 25 juin 2021 à 13:45, Kuhn Nicolas <[e-mail]> a écrit :
> 
> Dear Vincent,
>  
> Thank you for your comments.
> We have uploaded an updated version of the draft : https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/>
>  
> Please see inline for how your comments have been (we hope!) addressed in this update.
>  
> Cheers,
>  
> Nico
>  
> De : roca <[e-mail] <mailto:[e-mail]>> 
> Envoyé : vendredi 11 juin 2021 16:46
> À : [e-mail] <mailto:[e-mail]>
> Cc : roca <[e-mail] <mailto:[e-mail]>>; Marie-Jose Montpetit <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Objet : Re: RG Last Call for "Coding and congestion control in transport"
>  
> Dear authors,
>  
> I’ve read your updated I-D which I find in pretty good shape. 
> I only have a few minor comments below.
>  
> For me, the I-D is ready for IRSG review, once these comments are fixed.
> However I’d like to have another opinion on the topic.
>  
> Sorry for the delay in reading it (RGLC finished 11 days ago).
>  
> Cheers,   Vincent
>  
>  
> Clarification:
>  
> ** Section 2.3:
> - 1st paragraph:
> The use of multipath can indeed be associated to the case where there are multiple application streams, to split different streams to different paths, but not necessarily. The way it's written suggests me multipath is useless unless there are several application streams.
> I'm pretty sure this is not what you mean.
> [NK] The text has been updated as follows :
> <-
> The application layer may be composed of several streams above FEC
>    and transport layers instances.  The transport layer may exploit a
>    multipath mechanism.  The different streams could exploit different
>    paths between the sender and the receiver or not.  This section
>    describes what is in the scope of this document in regards with
>    multi-streams applications and multipath transport protocols.
> ->
>    The application layer can be composed of several streams above FEC
>    and transport layers instances.  The transport layer can exploit a
>    multipath mechanism.  The different streams could exploit different
>    paths between the sender and the receiver.  Moreover, a single-stream
>    application could also exploit a multipath transport mechanism.  This
>    section describes what is in the scope of this document in regards
>    with multi-streams applications and multipath transport protocols.
>  
> - fig 4 and 5: could you write in the figures what is in scope and what is not. It's hard to follow from the text.
> - What are the motivations for considering or not each possibility? It's not clear to me after reading this section.
>  
> [NK] This section has been updated with new figures and cases number to clarify what is discussed and what is not.
> “  Cases
>    IV, V and VI of Figure 5 are related to how multiple streams are
>    managed by a single transport or FEC layer: this does not directly
>    concerns the interaction between FEC and the transport and is out of
>    the scope of this document.”
>  
> ** Section 9, security considerations:
> What about manipulating feedback signals in order to compromize FEC rate adaptation? These feedback packets could be dropped or modified by an attacker. This is a way to trigger a DoS that specifically uses the technics described in this document that should be discussed briefly IMHO.
>  
> [NK] We have added the following in the security section
> “ FEC and CC schemes can contribute to DoS attacks.  Moreover, the
>    transmission of signaling messages from the client to the server
>    should be protected and reliable otherwise an attacker may compromise
>    FEC rate adaptation.  Indeed, an attacker could either modify the
>    values indicated by the client or drop signaling messages.”
>  
> Minor comments:
>  
> ** suggestion: "recovered" instead of "repaired" in 2.1. (repaired suggests there could be an error I think).
>  
> [NK] We have made an editorial check on the usage of recovered/repaired.
>  
> ** fig 1: I'm a bit surprised by the arrows:
>    |      |           source and/or  ---->|      |
>    |      | -----    repair symbols  ---->|      |
>  
> Why not the following:
>    |      |           source and/or       |      |
>    |      | -----    repair symbols  ---->|      |
> or even:
>    |      | -----     source and/or  ---->|      |
>    |      | -----    repair symbols  ---->|      |
>  
> [NK] Thanks.
>  
>  
>  
> Le 10 mai 2021 à 10:48, Vincent Roca <[e-mail] <mailto:[e-mail]>> a écrit :
>  
> Dear all,
>  
> Following the recent update of the I-D (thank you!), we would like to officially start a RG Last Call for:
>             "Coding and congestion control in transport"
>             https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/>
>  
> The call will end on Monday May 31st (3 weeks).
> 
> Please read it and provide feedback on the mailing list. Thanks in advance.
>  
> Regards,
>  
>     Marie-Jose and Vincent