Explicit Congestion Notification (ECN) for RTP over UDP
Note: This ballot was opened for revision 07 and is now closed.
(Robert Sparks; former steering group member) Yes
(Wesley Eddy; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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?
(Barry Leiba; former steering group member) No Objection
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.
(Brian Haberman; former steering group member) No Objection
I am also curious how this approach will interact with a PCN-conformant node (as asked by Stephen).
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) (was Discuss, No Objection) No Objection
[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.
(Ralph Droms; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
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
(Stewart Bryant; former steering group member) No Objection
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.