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

[Nicolas Kuhn <[e-mail]>]

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/

Thanks a lot for your help,

Nicolas

On Tue, Feb 22, 2022 at 9:56 PM Colin Perkins <[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]> wrote:
>
> Hi, Nicolas,
>
> On Tue, Feb 22, 2022 at 1:03 AM Nicolas Kuhn <[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/
>>
>
> 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.
>
>
>