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

[Colin Perkins <[e-mail]>]

Nicolas, Spencer,

Thank you for the fast update. I’ll start the IRSG final poll.

Colin


> On 23 Feb 2022, at 13:52, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> Colin, 
> 
> On Tue, Feb 22, 2022 at 11:59 PM Nicolas Kuhn <[e-mail] <mailto:[e-mail]>> wrote:
> Thank you for the quick feedback.
> Required updates can be seen in the 12th version : https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/>
> 
> I know these updates weren't required, but they match my suggestions 😉
> 
> Ready to launch, from my perspective. 
> 
> Best,
> 
> Spencer
>  
> Thanks a lot for your help,
> 
> Nicolas
> 
> On Tue, Feb 22, 2022 at 9:56 PM Colin Perkins <[e-mail] <mailto:[e-mail]>> wrote:
> 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] <mailto:[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.
>