search

mengelbart / rtp-over-quic-draft

Other
14 stars 5 forks source link

How to maintain RTCP bandwidth limits? #226

Open aboba opened 1 month ago

aboba commented 1 month ago

The RTP specification includes mechanisms for estimating and limiting RTCP bandwidth usage.

Currently the RTP over QUIC (RoQ) specification does not discuss how to maintain RTCP bandwidth limits. In particular, if RTCP is transported over QUIC streams rather than datagrams, retransmission of RTCP would occur "under the covers", making it difficult to use the existing estimation and limitation mechanisms.

joerg-ott commented 1 month ago

It seems, there are two cases to consider: 1. unreliable datagrams and 2. reliable streams.

  1. This would work as normal RTCP packets without retransmissions, the data rate pushed to the network layer would be roughly the same and the computation could remain unchanged. We could consider the QUIC per datagram packet overhead but this is hard to estimate as there would be ACKs in the opposite direction (of unknown frequency) and we don't quite know the header overhead as this may or may not be shared with other frames.

It seems we need to define a reference point for RTCP rate calculation. RFC 3550 chooses to include UDP and IP headers but I am not so sure about RTP over TCP as RFC 4571 seems to be silent about this. We know we will run on top of UDP, so UDP and IP headers could also be included and so could be QUIC short headers and the fixed overhead of a datagram frame. The rest is too fuzzy to characterize but we could indicate this to be a lower bound and it would certainly reflect what can be attributed to sending datagrams.

  1. Using QUIC streams is somewhat like TCP. All bets are off as we have absolutely no idea how packetization will happen and what the associated overhead would be. Hence, we should probably define the reference point to be above QUIC and just count what goes in terms of RTCP packets. One could construct a "virtual RTCP rate" assuming the same overhead as for 1. to be consistent.

In either case, we may leverage information available from the QUIC stack, such as RTT and precise loss information. This just would mean that the mean RTCP packet size, avg_rtcp_size in RFC 3550, would be effectively smaller as fewer information needs to be conveyed inside RTCP.

One could think of QUIC stack implementations to assess and export their induced overhead at some granularity to obtain an overhead estimate from which one could compute a scaling factor for RTCP bandwidth. Not sure this is worth it.

Finally, the RTCP bandwidth is most crucial for distributed interval computation in groups, which we don't have at this point with TCP or with QUIC.

joerg-ott commented 1 month ago

The problem of unknown overhead would also apply for retransmissions in case of using QUIC streams, but I think the same considerations for a reference point would apply.