Skip to main content

Last Call Review of draft-ietf-avtext-lrr-05

Request Review of draft-ietf-avtext-lrr
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-06-08
Requested 2017-05-25
Authors Jonathan Lennox , Danny Hong , Justin Uberti , Stefan Holmer , Magnus Flodman
I-D last updated 2017-06-07
Completed reviews Secdir Last Call review of -05 by Tero Kivinen (diff)
Opsdir Last Call review of -05 by Fred Baker (diff)
Genart Last Call review of -05 by Roni Even (diff)
Assignment Reviewer Fred Baker
State Completed
Request Last Call review on draft-ietf-avtext-lrr by Ops Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Has nits
Completed 2017-06-07
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.

However, that ultimately comes down to capacity planning and rate negotiation
in SIP or whatever.

Ship it, Danno.

The authors replied, and we agreed on a text change. -06 should be "ready" from
my perspective.

  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.


 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