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"
<[email protected] on behalf of [email protected]> 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" <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
