Re: [nwcrg] [irsg] IRSG review request draft-irtf-nwcrg-coding-and-congestion-09

[Colin Perkins <[e-mail]>]

Hi,

Thanks, Spencer and the authors for progressing this so quickly. Authors, are you able to do a very quick update to address these nits? Then I’ll start the final IRSG poll.

Colin



> On 22 Feb 2022, at 18:34, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> Hi, Nicolas, 
> 
> On Tue, Feb 22, 2022 at 1:03 AM Nicolas Kuhn <[e-mail] <mailto:[e-mail]>> wrote:
> Dear Spencer, all, 
> 
> Thank you so much for this review that contributes a lot, not only on the readability but also on structural aspects. 
> I hope we addressed your comments in the updated version of this draft 
> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/>
> 
> Thanks for the speedy response! I have a couple of items below, but this document is ready to move to the next step. 
> 
> Best,
> 
> Spencer
>  
> 
> This text is super helpful,
> 
>    We consider an end-to-end unicast data transfer with FEC coding in
>    the application (above the transport), within the transport or
>    directly below the transport.  A typical scenario for the
>    considerations in this document is a client browsing the web or
>    watching a live video.
> 
> but might be even more super helpful if it had pointers to the document sections that apply to each architecture. I was thinking about something like 
> 
>    We consider three architecture for end-to-end unicast data transfer:
> 
> Gerk. This should be "three architectures" - sorry! 
>  
> 
>    - with FEC coding in the application (above the transport) (Section 3), 
>    - within the transport (Section 4), or
>    - directly below the transport (Section 5).  
>  
>  
> Isn’t the observation about TCP in this text
> 
>    o  'network information' (input control plane for the transport
>       including CC): refers not only to the network information that is
>       explicitly signaled from the receiver, but all the information a
>       congestion control obtains from a network (e.g., TCP can estimate
>       the latency and the available capacity at the bottleneck).
> 
> true for any transfer protocol?
> 
> [NK] I have removed the TCP example to make it more generic.
> 
> This is now 
> 
>    *  'network information' (input control plane for the transport
>       including CC): refers not only to the network information that is
>       explicitly signaled from the receiver.
> 
> and would be clearer if a bit less text was removed. So, 
> 
>    o  'network information' (input control plane for the transport
>       including CC): refers not only to the network information that is
>       explicitly signaled from the receiver, but all the information a
>       congestion control obtains from a network.
> 
> One note on the new 2.3,
> 
>    The transport layer may provide an unreliable transport service (e.g.
>    UDP or DCCP [RFC4340]) or a partially reliable transport service
>    (e.g.  SCTP with the partial reliability extension [RFC3758] or QUIC
>    with the unreliable datagram extension [I-D.ietf-quic-datagram]).
>    Depending on the amount of redundancy and network conditions, there
>    could be cases where it becomes impossible to carry traffic.  This is
>    further discussed in Section 3 where "FEC above CC" case is assessed
>    and in Section 4 nor in Section 5 where "FEC in CC" and "FEC below
>                     ^^^ I think this should be "and", to match the rest of the sentence. 
>    CC" are assessed.