Re: [Gen-art] [rmcat] Genart last call review of draft-ietf-rmcat-nada-11

[Alissa Cooper <[e-mail]>]

Joel, thank you for your review. Xiaoqing, thanks for updating the document. I entered a Yes ballot.

Best,
Alissa


> On Aug 25, 2019, at 9:34 AM, Joel M. Halpern <[e-mail]> wrote:
> 
> Thank you Xiaoqing.  The revised documents looks good to me.
> Yours,
> Joel
> 
> On 8/25/2019 12:33 AM, Xiaoqing Zhu (xiaoqzhu) wrote:
>> Hi Joel,
>> Just wanted to update that we've submitted the revised draft (-12) where changes as stated below for addressing your comments.
>> https://tools.ietf.org/html/draft-ietf-rmcat-nada-12
>> Thanks again for reviewing this draft and helping to improve it.
>> Best,
>> Xiaoqing
>> On 8/13/19, 10:31 AM, "rmcat on behalf of Joel M. Halpern" <[e-mail] on behalf of [e-mail]> wrote:
>>     Thank you.  Those changes will address my concerns very effectively.
>>     Yours,
>>     Joel
>>          On 8/13/2019 11:26 AM, Xiaoqing Zhu (xiaoqzhu) wrote:
>>     > Dear Joel,
>>     >
>>     > Many thanks for your review of this draft.  Please find our responses as below, tagged [Authors].
>>     >
>>     > Best,
>>     > Xiaoqing (on behalf of all authors)
>>     >
>>     > On 8/5/19, 5:17 PM, "Joel Halpern via Datatracker" <[e-mail]> wrote:
>>     >
>>     >      Reviewer: Joel Halpern
>>     >      Review result: Almost Ready
>>     >
>>     >      I am the assigned Gen-ART reviewer for this draft. The General Area
>>     >      Review Team (Gen-ART) reviews all IETF documents being processed
>>     >      by the IESG for the IETF Chair.  Please treat these comments just
>>     >      like any other last call comments.
>>     >
>>     >      For more information, please see the FAQ at
>>     >
>>     >      <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>     >
>>     >      Document: draft-ietf-rmcat-nada-11
>>     >      Reviewer: Joel Halpern
>>     >      Review Date: 2019-08-05
>>     >      IETF LC End Date: 2019-08-12
>>     >      IESG Telechat date: Not scheduled for a telechat
>>     >
>>     >      Summary: This document is almost ready for publication as an Experimental RFC
>>     >
>>     >      Major issues:
>>     >         It is unclear reading this RFC how the observation information is to be
>>     >         communicated from the receiver to the sender.  At first I thought it was to
>>     >         use the RTP Receiver report.  But there is no description of how to map the
>>     >         fields to that report.   Then section 5.3 describes requirements for a
>>     >         reporting mechanism, but does not seem to actually define one.   Thus, I am
>>     >         left unclear how independent interoperable implementations of this draft can
>>     >         be created.
>>     >
>>     > [Authors]  Thanks for raising this point. The feedback format is a topic covered
>>     > by another currently pending draft (https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-04),
>>     > which indeed aims at ensuring interoperability of independent implementations of
>>     > RMCAT congestion control solutions.  Therefore, in this draft we only specified what type
>>     > of information is needed (e.g., receiving rate) and the unit and bit budget it is expressed
>>     > in (e.g., in bps in 32 bits) in the feedback from the receiver.  We also pointed out in Sec. 6.4
>>     > that an alternative way to implement this draft would be to leverage feedback messages
>>     > that contain per-packet information (e.g., delay and loss info) and to move all the calculations
>>     > from the receiver to the sender.
>>     >
>>     > [Author] Given the above considerations, we refrained from specifying a specific feedback
>>     > format. However, we should perhaps add a reference pointing to the cc-feedback-message draft.
>>     > Will do that in the next revision.
>>     >
>>     >      Minor issues:
>>     >          The document has 7 front page authors.   The shepherd writeup does not
>>     >          comment on this. The shepherd writeup seems quite sparse.  II would have
>>     >          expected some reference to the experimental behavior described in the draft.
>>     >
>>     > [Authors] Thanks for raising the concern about long list of front page authors. We got some
>>     > additional guidance from the AD and will make some adjustments accordingly.
>>     >
>>     > [Authors] As for comments on the experimental behavior: we have presented in recent IETF meetings
>>     > on several sets of real-world evaluations of one implementation of NADA.  But, admittedly, the draft
>>     > is lagging behind in not yet adding pointers to those results. Your suggestion is a great one and we'll add
>>     > corresponding pointer (see links below) and related discussions in the next version.
>>     >
>>     > * https://datatracker.ietf.org/meeting/103/materials/slides-103-rmcat-nada-implementation-in-mozilla-browser-00
>>     > * https://datatracker.ietf.org/meeting/105/materials/slides-105-rmcat-nada-update-02.pdf
>>     >
>>     >
>>     >          This comment is just to confirm that I am reading the draft correctly.  It
>>     >          looks like when the observed delay cross the delay boundary, the reporting
>>     >          system reports using a smaller delay than actually approved (slightly more
>>     >          than 1/9th of observed delay when delay is 3*QTH).  I presume this is
>>     >          intentional, and that the various analysis pointed to evaluate the risks of
>>     >          such false reporting?
>>     >
>>     > [Authors]  Yes, your understanding is correct. The main motivation for this "delay warping"
>>     > In the presence of persistently high queuing delay *and* presence of loss is to help the flow to
>>     > sustain a more fair rate when competing against aggressive loss-based flows.  Will follow your
>>     > advice and add some discussions on the potential risks involved in performing this "delay warping".
>>     >
>>     >          Is it intentional in section 4.3 in the pseudo-code that the rate clipping
>>     >          (to keep the rate between RMIN and RMAX) is only applied to the gradual
>>     >          rate change, not to the accelerated rate change?  The later code says that
>>     >          the clipping is always applied, which is what I would expect.
>>     >
>>     > [Authors]  Thanks to the catch. The clipping is always applied.  Will fix the text accordingly.
>>     >
>>     >      Nits/editorial comments:
>>     >
>>     >
>>     > [Authors]  Thanks again for your above comments. Our next round of revision (version -12) will incorporate
>>     > changes as mentioned in our above response.
>>     >
>>          
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art