Skip to content
Anton Roman edited this page Jan 19, 2022 · 5 revisions

ECN-aware WebRTC demo

Project goal

This project is aimed at implementing a functional WebRTC demo with Pion Webrtc stack and Janus Gateway

Main steps to get WebRTC stacks ECN-aware

1. Getting ECN info from the wire

1.1 Tentative roadmap to achieve ECN-awareness in the stack:

The following steps were defined as needed in the inital discussions:

  1. Detect if the network is ECN-aware.
  2. Get the ECN bits from the incoming RTP flows.
  3. Apply aggregation algortihm to CE marks before sending the event to upper layers.
  4. Sending of congestion notifications to upper layers.

1.2 Implementation proposal

2. Sending the congestion feedback to the sender

2.1 RTCP approaches

RFC8888 seems the right approach to send the congestion feedback information as RTCP. It has been designed to be used with Network-Assisted Dynamic Adaptation (NADA) RFC8698, Self-Clocked Rate Adaptation for Multimedia (SCReAM) RFC8298, Google Congestion Control [Google-GCC], and Shared Bottleneck Detection [RFC8382].

2.3 Out-of-band notifications

The alternative to notify both client and server applications using out-of-band approaches. This means using neither RTP nor RTCP but application protocols to let the sender send that there is congestion in the network so it can act accordingly.

3. Using the congestion feedback to adjust the sending bitrate

3.1 Usage of congestion events in BWE algorithms.

Since ECN marks can be considered as previous signal of queue congestion, it makes sense to consider the ECN marks as equivalent to packet losses in Band Width Estimation algorithms. Actually ECN is expected to be received when real congestion happen, packet losses can happen also due to connectivity problems in the air interface.

Google Congestion Control algortihm uses the

3.2 How to determine when there is congestion

Like packet losses the number of RTP packets received with ECN-CE marks gives us a measure of how congested are the queues in the intermediate routing elements since the Capacitiy of one of several of the intermediates links can not handle the amount of traffic sent. Opposite to packet losses which occur in congestion situations when the queues are full, packet losses can also happen due to other circunstances such as interferences in the air interface in WiFi or mobile networks. So the ECN-CE marks, which are deliberately included by the congested elements, is an unequivocous signal of congestion. It can have an influence in the packet-loss controller more quickly than packet losses.

As a first approach, an approximation of the GCC algorithm is going to be used to determine when the congestion notification requires a bitrate reduction to accomodate the used bitrate to the capacity available in the 5G network.

3.3 Actions at application-level