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 |