Research : Explicit Congestion Notification for RTP

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

Posted on in category ecn-for-rtp

We submitted a new version of the ECN for RTP draft today. This is a minor update, to address IESG review comments . The most significant change is a fix to the qdtext ABNF, to properly allow quoted values, but there are some minor clarifications throughout.

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

Posted on in category ecn-for-rtp

We submitted a new version of the ECN-for-RTP draft yesterday, to address review comments from our Area Director and the IANA. The changes in this version are:

  • Clarify the name of the STUN attribute (ECN-CHECK) per IANA comments
  • Remove reference to RTP no-op
  • Fix Block Length in Section 5.2
  • Clarify handling of counter wraps in Section 5.1
  • Clarify "other reactions" in Section 7.3.3
  • Make reference to RFC4566 normative
  • Fix editorial nits
Since there were no other IETF last call comments, this should now to ready for consideration by the IESG.

Last Call: Explicit Congestion Notification for RTP over UDP to Proposed Standard

Posted on in category ecn-for-rtp

The IESG has announced an IETF last call for comments on our draft about Explicit Congestion Notification (ECN) for RTP, before it is published as a Proposed Standard RFC. Any final comments on the draft are solicited. Substantive comments should be sent to the ietf@ietf.org mailing list by 2012-03-22; more minor comments should be sent to the authors.

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

Posted on in category ecn-for-rtp

A new version of the ECN-for-RTP draft is now available. The main changes are to add some discussion about the conservative nature of the rules for use of ECN with multicast groups, and to update the rules regarding timing of STUN connectivity checks. There are also a number of more minor editorial fixes. It's believed that this version addresses all the working group last call comments.

IETF 82 — Presentation on ECN for RTP

Posted on in category ecn-for-rtp

The slides for my presentation on ECN for RTP at the 82nd IETF meeting are available. The focus is on addressing the remaining open issues with the -05 draft, namely resolving interactions with ICE to avoid causing additional call setup time, and support for IP multicast.

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

Posted on in category ecn-for-rtp

A new version of our draft on ECN for RTP is now available. This revision addresses many of the working group last call comments. These were mostly minor clarifications and editorial corrections, but there were some significant issues raised:

  • When using STUN to determine is ECN is supported on the path, as part of an ICE exchange, the additional checks for ECN support happen after the regular ICE exchange, but before media flows. This is problematic if the call has been accepted, since it can cause media clipping. It is proposed to allow the media to start without using ECN, with the STUN checks to running in parallel (at a low rate), and then switching to using ECN if they succeed, to improve the user experience.
  • When using ECN-marked STUN packets to determine if ECN is supported on the path, the STUN checks may be lost. This could be due to congestion on the path, or because of a middlebox that is not ECN capable, and discards ECN-marked packets. Since the aim is to detect such middleboxes, lost ECN-marked STUN requests should be retransmitted up to four times, to give confidence that the loss is not just due to congestion.
  • Support for multicast RTP sessions using ECN, to clarify that when ECN for RTP is used with SSM groups using unicast feedback, ECN reports will go to the feedback target, which must then send them to the original media source.
  • It was noted that multicast sessions will only use ECN if every receiver, and the path to each, supports ECN. This is an obvious scalability problem for large multicast groups. The alternative, allowing groups where some receivers support ECN and some don't, has serious fairness issues, which we haven't yet solved. We propose to document this issue, and note that the current, very conservative, rules may be relaxed in a future version of the specification, but not to address this issue in the first version of the standard.

The draft will be discussed in the AVTCORE working group session at IETF 82 in Taipei.

IANA Registry for ICE Options

Posted on in category ecn-for-rtp

RFC 6336 is now out, defining the IANA Registry for ICE Options. This fixes an oversight in RFC 5245, which states that the registry for ICE options exists, but did not create it with IANA or specify the syntax of legal options. This is a necessary precursor to the ECN for RTP work, which needs to use an ICE option.

Explicit Congestion Notification for RTP over UDP/IP

Posted on in category ecn-for-rtp

ECN is getting attention as a method to minimise the impact of congestion on real-time multimedia traffic. When ECN is used, the network can signal to applications that congestion is occurring, whether that congestion is due to queuing at a congested link, limited resources and coverage on a radio link, or other reasons. This congestion signal allows applications to reduce their transmission rate in a controlled manner, rather than responding to uncontrolled packet loss, and so improves the user experience while benefiting the network.

The introduction of ECN into the Internet requires changes to both the network and transport layers. At the network layer, IP forwarding has to be updated to allow routers to mark packets, rather than discarding them in times of congestion. In addition, transport protocols have to be modified to inform that sender that ECN marked packets are being received, so it can respond to the congestion. TCP, SCTP, and DCCP have been updated to support ECN, but to date there is no specification how UDP-based transports, such as RTP, can use ECN. The aim of this project is to define such a specification.

This project is a collaboration between Ericsson Research and the University of Glasgow.

Standards Contributions