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

[Marie-Jose Montpetit <[e-mail]>]

Thanks Spencer!

mjm

Marie-José Montpetit, Ph.D.
[e-mail]



From: Spencer Dawkins at IETF <[e-mail]>
<[e-mail]>
Reply: Spencer Dawkins at IETF <[e-mail]>
<[e-mail]>
Date: February 22, 2022 at 1:34:57 PM
To: Nicolas Kuhn <[e-mail]> <[e-mail]>
Cc: [e-mail]
<[e-mail]>
<[e-mail]>, nwcrg <[e-mail]>
<[e-mail]>, The IRSG <[e-mail]> <[e-mail]>
Subject:  Re: [irsg] [nwcrg] IRSG review request
draft-irtf-nwcrg-coding-and-congestion-09

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.