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

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

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.