Explicit Congestion Notification (ECN) for RTP over UDP
RFC 6679

Note: This ballot was opened for revision 07 and is now closed.

(Wesley Eddy) Yes

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-04-10 for -07)
No email
send info
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.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2012-04-12 for -07)
No email
send info
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?

(Stephen Farrell) No Objection

Comment (2012-04-08 for -07)
No email
send info
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? 


- 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

(Brian Haberman) No Objection

Comment (2012-04-09 for -07)
No email
send info
I am also curious how this approach will interact with a PCN-conformant node (as asked by Stephen).

(Russ Housley) No Objection

Barry Leiba No Objection

Comment (2012-04-11 for -07)
No email
send info
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.

(Pete Resnick) (was Discuss, No Objection) No Objection

Comment (2012-05-14)
No email
send info
[DISCUSS issue on ABNF and comment about 3.1 addressed. Thanks.]


   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.

(Sean Turner) No Objection