Explicit Congestion Notification for RTP

IETF 82: presentation on ECN for RTP

Posted on 14 November 2011 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 13 November 2011 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 20 July 2011 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 19 June 2009 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