Research : Explicit Congestion Notification for RTP

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.