datatracker.ietf.org
Sign in
Version 5.6.2.p5, 2014-08-04
Report a bug

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

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

Summary: Needs a YES. Needs 5 more YES or NO OBJECTION positions to pass.

Adrian Farrel

Comment (2012-04-12 for -07)

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

Comment (2012-04-11 for -07)

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

Comment (2012-04-09 for -07)

I am also curious how this approach will interact with a PCN-conformant node
(as asked by Stephen).

Pete Resnick

Comment (2012-05-14 for -08)

[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.

Stephen Farrell

Comment (2012-04-08 for -07)

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]

Comment (2012-04-10 for -07)

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.