Skip to main content

Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avtcore-ecn-for-rtp-08

Revision differences

Document history

Date Rev. By Action
2012-06-14
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-06-14
08 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2012-06-05
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-05-17
08 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2012-05-17
08 (System) IANA Action state changed to In Progress
2012-05-16
08 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2012-05-16
08 Amy Vezza IESG has approved the document
2012-05-16
08 Amy Vezza Closed "Approve" ballot
2012-05-16
08 Amy Vezza Ballot approval text was generated
2012-05-16
08 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2012-05-16
08 Robert Sparks Ballot writeup was changed
2012-05-14
08 Pete Resnick
[Ballot comment]
[DISCUSS issue on ABNF and comment about 3.1 addressed. Thanks.]

10.1:

  This attribute defines the ability to negotiate the use of ECT …
[Ballot comment]
[DISCUSS issue on ABNF and comment about 3.1 addressed. Thanks.]

10.1:

  This attribute defines the ability to negotiate the use of ECT (ECN
  capable transport) for RTP flows running over UDP/IP.  This attribute
  should be put in the SDP offer if the offering party wishes to
  receive an ECT flow.  The answering party should include the
  attribute in the answer if it wish to receive an ECT flow.  If the
  answerer does not include the attribute then ECT MUST be disabled in
  both directions.

I don't think it's a good idea to put protocol instructions into the IANA template. These are all already documented earlier in this document. Just put a pointer to [This document, section 6.1] and skip the last 3 sentences above. You don't want people trying to implement from the registry.
2012-05-14
08 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss
2012-05-14
08 Magnus Westerlund New version available: draft-ietf-avtcore-ecn-for-rtp-08.txt
2012-04-12
07 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation
2012-04-12
07 Pete Resnick
[Ballot discuss]
6.1:

      qdtext        = %x20-21 / %x23-7E / %x80-FF
                  …
[Ballot discuss]
6.1:

      qdtext        = %x20-21 / %x23-7E / %x80-FF
                      ; any 8-bit ASCII except <">

That makes me worried. You do not provide an escaping mechanism such that someone could put a quote in their quoted text. You do not specify the interpretation of the stuff from 0x80 through 0xFF (UTF-8? ISO-8859-1? uninterpreted octet?), and worse you call it "8-bit ASCII" which does not have a clear meaning. You also leave out 0x7F (not mentioned in the comment), and I have a guess as to why (it's not printable), but you don't say why. I understand you want this to be extensible, but I don't think the above is fully baked. Perhaps explain what you want to allow and I can recommend some alternatives.
2012-04-12
07 Pete Resnick
[Ballot comment]
3.1: I don't understand what the 2119 words add. These are requirements for the protocol designers, not requirements for the protocol implementers.

10.1: …
[Ballot comment]
3.1: I don't understand what the 2119 words add. These are requirements for the protocol designers, not requirements for the protocol implementers.

10.1:

  This attribute defines the ability to negotiate the use of ECT (ECN
  capable transport) for RTP flows running over UDP/IP.  This attribute
  should be put in the SDP offer if the offering party wishes to
  receive an ECT flow.  The answering party should include the
  attribute in the answer if it wish to receive an ECT flow.  If the
  answerer does not include the attribute then ECT MUST be disabled in
  both directions.

I don't think it's a good idea to put protocol instructions into the IANA template. These are all already documented earlier in this document. Just put a pointer to [This document, section 6.1] and skip the last 3 sentences above. You don't want people trying to implement from the registry.
2012-04-12
07 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to Discuss from No Objection
2012-04-12
07 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms
2012-04-12
07 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2012-04-12
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-04-12
07 Adrian Farrel
[Ballot comment]
I don't object to the publication of this document, but it does bother
me how much effort, time, and pages go into describing …
[Ballot comment]
I don't object to the publication of this document, but it does bother
me how much effort, time, and pages go into describing a protocol
extension that no-one is apparently bothered to implement. What is the
value of a standards track RFC in this case? How can we know whether the
document or the protocol are right?
2012-04-12
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-04-11
07 Wesley Eddy [Ballot Position Update] New position, Yes, has been recorded for Wesley Eddy
2012-04-11
07 Pete Resnick
[Ballot comment]
3.1: I don't understand what the 2119 words add. These are requirements for the protocol designers, not requirements for the protocol implementers.

6.1: …
[Ballot comment]
3.1: I don't understand what the 2119 words add. These are requirements for the protocol designers, not requirements for the protocol implementers.

6.1:

      qdtext        = %x20-21 / %x23-7E / %x80-FF
                      ; any 8-bit ASCII except <">

That makes me worried. You do not provide an escaping mechanism such that someone could put a quote in their quoted text. You do not specify the interpretation of the stuff from 0x80 through 0xFF (UTF-8? ISO-8859-1? uninterpreted octet?), and worse you call it "8-bit ASCII" which does not have a clear meaning. You also leave out 0x7F (not mentioned in the comment), and I have a guess as to why (it's not printable), but you don't say why. I understand you want this to be extensible, but I don't think the above is fully baked. Perhaps explain what you want to allow and I can recommend some alternatives.

10.1:

  This attribute defines the ability to negotiate the use of ECT (ECN
  capable transport) for RTP flows running over UDP/IP.  This attribute
  should be put in the SDP offer if the offering party wishes to
  receive an ECT flow.  The answering party should include the
  attribute in the answer if it wish to receive an ECT flow.  If the
  answerer does not include the attribute then ECT MUST be disabled in
  both directions.

I don't think it's a good idea to put protocol instructions into the IANA template. These are all already documented earlier in this document. Just put a pointer to [This document, section 6.1] and skip the last 3 sentences above. You don't want people trying to implement from the registry.
2012-04-11
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-04-11
07 Barry Leiba
[Ballot comment]
Some non-blocking comments -- though I would *really* like to see the IANA Considerations comment addressed.

---
Section 3:
  ECN support is …
[Ballot comment]
Some non-blocking comments -- though I would *really* like to see the IANA Considerations comment addressed.

---
Section 3:
  ECN support is more important for RTP sessions than, for instance, is
  the case for TCP.  This is because the impact of packet loss in real-
  time audio-visual media flows is highly visible to users.  Effective
  ECN support for RTP flows running over UDP will allow real-time
  audio-visual applications to respond to the onset of congestion

I'm not clear about what the first sentence is comparing, because RTP doesn't compare to TCP.  Do you mean that ECN support is more important for RTP sessions over UDP than for RTP sessions over TCP?  I don't think so.  Do you mean that it's more important for RTP sessions than for *other applications over TCP*?  I think that's it.  But then what does TCP have to do with it?  It seems that the point is that RTP is more sensitive to congestion issues that other applications are, regardless of the underlying transport protocol.  In any case, please clarify that sentence.

---
Section 3.1:
Do we really need 2119 language in the requirements?  I rather think that requirements would generate 2119 language in the protocol.

---
Section 9:
You explain that the situation with existing APIs is such that it makes "this specification difficult to implement portably."  And that's all you say.  Any words of wisdom here?  Advice to implementors about how to handle the situation?

---
Section 10.1:
  Following the guidelines in [RFC4566], the IANA is requested to
  register one new SDP attribute:

I see a lot of SDP Parameters registries and tables, and it's not at all clear to me which one this gets registered in.  Maybe it's clear to IANA, and maybe this is fine, but maybe also it should be made clearer here.  Can you give the exact name of the registry and the table within the registry, to avoid mistakes?

In general, the different subsections of Section 10 are inconsistent in how (and how specifically) they name the registries and tables you intend to update.  I like the way 10.6 does it -- no chance for confusion at all there.
2012-04-11
07 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2012-04-10
07 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from No Record
2012-04-10
07 Stewart Bryant
[Ballot comment]
Given that this

1) This is of interest to 3GPP
2) MPLS-TP seems to be a popular choice in Mobile wireless backhaul.
3) …
[Ballot comment]
Given that this

1) This is of interest to 3GPP
2) MPLS-TP seems to be a popular choice in Mobile wireless backhaul.
3) Most service provider core networks use MPLS

Should there not be a reference to RFC5129, and a note that ECN needs to be propagated from the tunnel to the payload?

I am not sure how common MPLS ECN is, but it is not mentioned anywhere in the MPLS-TP specifications.
2012-04-10
07 Stewart Bryant Ballot comment text updated for Stewart Bryant
2012-04-09
07 Brian Haberman [Ballot comment]
I am also curious how this approach will interact with a PCN-conformant node (as asked by Stephen).
2012-04-09
07 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2012-04-09
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-04-09
07 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-04-08
07 Stephen Farrell
[Ballot comment]
I've a couple of general comments and some nits. The former:

- 55 pages to discuss two bits? something wrong there;-)

- last …
[Ballot comment]
I've a couple of general comments and some nits. The former:

- 55 pages to discuss two bits? something wrong there;-)

- last para of section 3 (before 3.1), but a general question: you say ECN
is set before congestion results in packet drops but I thought that was
the point of PCN (the WG) which is just finishing. Are these things all
sensible together? I assume a receiver/sender here can be within a PCN
"domain" or whatever's the right term. Does all the ECN logic here work
if the bits are actually set by a PCN conformant node?

- Section 11: I don't get this sentence: "Secure RTP (SRTP) [RFC3711] does
satisfy the requirement to protect this mechanism despite only providing
authentication if a entity is within the security context or not." What's
it mean?

nits:

- 2nd last para of section 3, maybe s/differences will/differences/
since you've presumably now figured it out?

- p12, 2nd last para typo: s/mechanism/mechamisms/ in 2nd sentence. the
leap-of-faith and ICE-based methods could do with references maybe

- 3.3, 1st sentence seems odd, isn't it a tautology?

- last para on p13, is that a 2119 MUST? looks like one

- s/the are/they are/ on p36

- section 11 s/inferring/interfering/ in 3rd last para, and
2012-04-08
07 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2012-04-05
07 Robert Sparks State changed to IESG Evaluation from Waiting for AD Go-Ahead
2012-04-01
07 Suresh Krishnan Request for Last Call review by GENART Completed. Reviewer: Suresh Krishnan.
2012-03-30
07 Robert Sparks Ballot has been issued
2012-03-30
07 Robert Sparks [Ballot Position Update] New position, Yes, has been recorded for Robert Sparks
2012-03-30
07 Robert Sparks Created "Approve" ballot
2012-03-30
07 Robert Sparks Placed on agenda for telechat - 2012-04-12
2012-03-30
07 Colin Perkins New version available: draft-ietf-avtcore-ecn-for-rtp-07.txt
2012-03-22
06 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-03-21
06 Amanda Baber
IANA has a question about the sixth of the seven actions requested by
this document.

Upon approval of this document, IANA will perform the following …
IANA has a question about the sixth of the seven actions requested by
this document.

Upon approval of this document, IANA will perform the following actions:

ACTION 1:

IANA will register the following media-level only attribute at
http://www.iana.org/sdp-parameters

ecn-capable-rtp [this document]


ACTION 2:

IANA will make the following assignment in the FMT Values for RTPFB
Payload Types registry at
http://www.iana.org/assignments/rtp-parameters

Name: RTCP-ECN-FB
Long name: RTCP ECN Feedback
Value: TBA
Reference: [this document]


ACTION 3:

IANA will make the following assignment in the "ack" and "nack"
Attribute Values registry at
http://www.iana.org/assignments/sdp-parameters

Value name: ecn
Long name: Explicit Congestion Notification
Usable with: nack
Reference: [this document]


ACTION 4:

IANA will register the following RTCP XR Block Type at
http://www.iana.org/assignments/rtcp-xr-block-types

ECN Summary Report [this document]


ACTION 5:

IANA will register the following RTCP XR SDP Parameter at
http://www.iana.org/assignments/rtcp-xr-sdp-parameters

Parameter name XR block (block type and name) Reference
-------------- ------------------------------ ---------
ecn-sum TBA2 ECN Summary Report Block [this document]


ACTION 6:

IANA will register the following STUN attribute in the 0x8000-0xFFFF
range at http://www.iana.org/assignments/stun-parameters

ECN-CHECK (?) [this document]

QUESTION: is this the right name? The exact name you want isn't
specified in section 7.2.2. All current STUN attributes are listed in
all-caps, no-spaces format. Please add the name you want IANA to
register to the IANA Considerations section.


ACTION 7:

IANA will register the following ICE Option at
http://www.iana.org/assignments/ice

rtp+ecn [this document]
2012-03-14
06 Martin Stiemerling Request for Last Call review by TSVDIR is assigned to Colin Perkins
2012-03-14
06 Martin Stiemerling Request for Last Call review by TSVDIR is assigned to Colin Perkins
2012-03-09
06 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2012-03-09
06 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2012-03-08
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Catherine Meadows
2012-03-08
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Catherine Meadows
2012-03-08
06 Cindy Morgan Last call sent
2012-03-08
06 Cindy Morgan
State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: …
State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Explicit Congestion Notification (ECN) for RTP over UDP) to Proposed Standard





The IESG has received a request from the Audio/Video Transport Core

Maintenance WG (avtcore) to consider the following document:

- 'Explicit Congestion Notification (ECN) for RTP over UDP'

  as a Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-03-22. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  This memo specifies how Explicit Congestion Notification (ECN) can be

  used with the Real-time Transport Protocol (RTP) running over UDP,

  using RTP Control Protocol (RTCP) as a feedback mechanism.  It

  defines a new RTCP Extended Report (XR) block for periodic ECN

  feedback, a new RTCP transport feedback message for timely reporting

  of congestion events, and a Session Traversal Utilities for NAT

  (STUN) extension used in the optional initialization method using

  Interactive Connectivity Establishment (ICE).  Signalling and

  procedures for negotiation of capabilities and initialization methods

  are also defined.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/ballot/





No IPR declarations have been submitted directly on this I-D.





2012-03-08
06 Robert Sparks Last call was requested
2012-03-08
06 Robert Sparks Ballot approval text was generated
2012-03-08
06 Robert Sparks State changed to Last Call Requested from AD Evaluation
2012-03-08
06 Robert Sparks Last call announcement was generated
2012-03-08
06 Robert Sparks Ballot writeup was changed
2012-03-08
06 Robert Sparks Ballot writeup was generated
2012-03-07
06 Roni Even IETF state changed to Submitted to IESG for Publication from WG Document
2012-03-07
06 Roni Even publication request
2012-03-07
06 Robert Sparks State changed to AD Evaluation from Publication Requested
2012-03-07
06 Cindy Morgan
(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
    …
(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd is Roni Even. I have reviewed the document, and
believe it is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document is the result of an effort done by key WG members. It went
through Working Group last call and people had enough time to review it. The
document shepherd feels comfortable with the review it got.

Note that the document started at AVT before it was moved to the new AVTCore
WG.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No Concerns. No IPR disclosure related to this document or the previous
individual draft and AVT version was filed.

(1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The document has strong consensus the members of the AVTCore WG.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits?(See the Checklist and idnits
        ).Boilerplate checks are not enough;
        this check needs to be thorough. Has the document met all formal review
        criteria it needs to, such as the MIB Doctor, media type and URI type
        reviews?

There is one warning that is relevant:

== There are 3 instances of lines with private range IPv4 addresses in
  the document.  If these are generic example addresses, they should
  be changed to use any of the ranges defined in RFC 5735 (or
  successor): 192.0.2.x, 198.51.100.x or 203.0.113.x.

They are intentional as we have an SDP example of an end-point that is NATed
with the address 10.0.1.4. Both the o= and the ICE candidate list thus
contains such an 10.0.1.4 address. Thus I don't see an issue of using
private address ranges in the example.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

References are split. There are no normative references to documents which
are not in RFC state

(1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA consideration section exists and is inline with the body of the
document.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The document shepherd verified that the SDP signaling examples  in section
12 are correct.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

    "This memo specifies how Explicit Congestion Notification (ECN) can be
  used with the Real-time Transport Protocol (RTP) running over UDP,
  using RTP Control Protocol (RTCP) as a feedback mechanism.  It
  defines a new RTCP Extended Report (XR) block for periodic ECN
  feedback, a new RTCP transport feedback message for timely reporting
  of congestion events, and a Session Traversal Utilities for NAT
  (STUN) extension used in the optional initialization method using
  Interactive Connectivity Establishment (ICE).  Signalling and
  procedures for negotiation of capabilities and initialization methods
  are also defined."

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

    There were no controversy about the proposed solution and there was
    consensus on all discussion points

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?


The document shepherd is not aware of current implementations. There was
interest in this work by other standard bodies like 3GPP and ITU-T SG16 who
need to reference it.

The SDP attributes and ICE options defined in the document were sent to
review in MMUSIC on September 30, 2011


2012-03-07
06 Cindy Morgan Note added 'Roni Even (even.roni@huawei.com) is the document shepherd.'
2012-03-07
06 Cindy Morgan Intended Status changed to Proposed Standard
2012-03-07
06 Cindy Morgan IESG process started in state Publication Requested
2012-03-07
06 (System) Earlier history may be found in the Comment Log for draft-ietf-avt-ecn-for-rtp
2012-02-17
06 (System) New version available: draft-ietf-avtcore-ecn-for-rtp-06.txt
2011-10-31
05 (System) New version available: draft-ietf-avtcore-ecn-for-rtp-05.txt
2011-07-11
04 (System) New version available: draft-ietf-avtcore-ecn-for-rtp-04.txt
2011-07-11
03 (System) New version available: draft-ietf-avtcore-ecn-for-rtp-03.txt
2011-06-20
06 Roni Even will go through pre-WGLC review
2011-06-20
06 Roni Even Annotation tag Other - see Comment Log set.
2011-05-31
02 (System) New version available: draft-ietf-avtcore-ecn-for-rtp-02.txt
2011-03-14
01 (System) New version available: draft-ietf-avtcore-ecn-for-rtp-01.txt
2011-01-28
00 (System) New version available: draft-ietf-avtcore-ecn-for-rtp-00.txt