Re: [avtext] Question about draft-ietf-avtext-lrr

[Fred Baker <[e-mail]>]

Works for me.

> On Jun 1, 2017, at 9:31 AM, Jonathan Lennox <[e-mail]> wrote:
> 
> 
>> On May 31, 2017, at 7:08 PM, Fred Baker <[e-mail]> wrote:
>> 
>> 
>>> On May 31, 2017, at 3:04 PM, Jonathan Lennox <[e-mail]> wrote:
>>> 
>>>> 
>>>> On May 30, 2017, at 8:21 PM, Fred Baker <[e-mail]> wrote:
>>>> 
>>>> I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.
>>>> 
>>>> My judgement: the document is ready.
>>>> 
>>>> Understand that my expertise is neither in codecs nor RTCP, and I have not implemented the specification; there may be glaring issues in it from an implementor's perspective for all I know. I'm looking at the issues a network operator would face and need to deal with.
>>>> 
>>>> My biggest concern, from a network perspective, has to do with congestion. The draft discusses congestion in passing, and calls for "consideration" of the congestion issues and algorithms raised in RFC 5104. The word "consideration" gives me some pause; Admiral Farragut famously "considered" a minefield between his fleet and the harbor at Mobile Alabama, and gave the order "damn the torpedoes, full speed ahead".  I'd hope for a stronger word there. Also, the "consideration" in RFC 5104 is for congestion of the feedback path, but not the forward data path (which, if it becomes congested by having too many layers being sent, would reactively reduce its rate sometime later in response to loss or delay in transit). I'm more concerned about the latter, as I suspect an operator might be.
>>> 
>>> The cited Section 5 of RFC 5104 also talks about congestion on the forward path.  The relevant paragraph is:
>>> Thus, modified behaviour MUST respect the bandwidth limits that the
>>> application of congestion control provides.  For example, when a
>>> media sender is reacting to a FIR, the unusually high number of
>>> packets that form the decoder refresh point have to be paced in
>>> compliance with the congestion control algorithm, even if the user
>>> experience suffers from a slowly transmitted decoder refresh point.
>>> Do you feel that this needs to be called out more explicitly?
>> 
>> I'd like to see it more explicitly called out. I can readily imagine an implementor glossing over the statement in the text: "OK, I thought about it". I don't have a text suggestion.
> 
> 
> How’s this?
> 
> Suggested change:
> 
> Replace 
>   The sender MUST consider congestion control as outlined in section 5
>   of [RFC5104], which MAY restrict its ability to send a layer refresh
>   point quickly.
> 
> with
> 
>  The sender MUST respect bandwidth limits provided by the application of
>  congestion control, as described in Section 5 of [RFC5104].  As layer refresh
>  points will often be larger than non-refreshing frames, this may restrict a
>  sender’s ability to send a layer refresh point quickly.
> 
> (Also fixing Ben Campbell’s comment that the MAY in this paragraph shouldn’t be capitalized.)
> 
>