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

[Spencer Dawkins at IETF <[e-mail]>]

Colin,

On Tue, Feb 22, 2022 at 11:59 PM Nicolas Kuhn <[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/
>

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]> 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.
>>
>>
>>