- Zaheduzzaman Sarker, Colin Perkins, Varun Singh, and Michael A. Ramalho, RTP Control Protocol (RTCP) Feedback for Congestion Control (.txt|.pdf), Internet Engineering Task Force, July 2019, Work in progress (draft-ietf-avtcore-cc-feedback-message-04.txt).
This version addresses feedback received during IETF-104, based on hackathon experience. It does not change the packet format or signalling in any way, but rather clarifies parts of the specification that were unclear. The specific changes are
- to add an example of use of the "a=rtcp-fb:" attribute;
- to clarify that congestion control feedback is sent for FEC and retransmission packets, if used;
- to clarify that congestion control feedback signalling is IDENTICAL-PER-PT when used with the SDP bundling extension;
- to clarify that if an SDP offer indicates support for several different ways of providing congestion control feedback, the receiver SHOULD pick its preferred mechanism and use it consistently;
- to clarify that feedback reports indicating that packets were lost are not explicit requests for retransmission;
- to clarify that large feedback packets might need to be split across multiple RTCP packets if the RTCP bandwidth fraction is misconfigured; and
- to add a section on the desired congestion response in cases where congestion control feedback packets are lost.
At this time there are not believed to be any open technical issues with the specification. The only non-technical issue outstanding is to add some further design rationale and a comparison with other approaches, in particular those that use a single sequence number space across flows, to highlight the benefits and trade-offs.
- Zaheduzzaman Sarker, Colin Perkins, Varun Singh, and Michael A. Ramalho, RTP Control Protocol (RTCP) Feedback for Congestion Control (.txt|.pdf), Internet Engineering Task Force, December 2018, Work in progress (draft-ietf-avtcore-cc-feedback-message-03.txt).
This version includes the following changes:
- Fixes the description of arithmetic on sequence numbers, which should be done modulo 65536 not 65535;
- Switch to using num_reports rather than end_seq + 1 in report blocks;
- Better explain the value of the ATO field, in particular what value to include for packets that are know to have arrived after the time instant denoted by the RTS field;
- Better explain the value of the RTS field;
- Note that if a packet was reported as received in a report, then that packet MUST also be reported as received in any overlapping reports sent later that cover its sequence number range;
- Don’t try to explain how to recover after an outage, since recovering state in that case is a general RTCP problem and not specific to this report block;
- Better explain how to report on duplicate packets;
- Clarify that the receiver has to report on every active SSRC since it can’t tell what SSRCs are being congestion controlled;
- Clarify that wild card payload types need to be used in the SDP signalling; and
- Explain relation to RFC 6679.
The first two changes are made to belatedly address feedback from the Montréal IETF. The other changes attempt to address feedback from Jonathan Lennox based on implementation experience during the hackathon at the Bangkok IETF meeting.
- Zaheduzzaman Sarker, Colin Perkins, Varun Singh, and Michael A. Ramalho, RTP Control Protocol (RTCP) Feedback for Congestion Control (.txt|.pdf), Internet Engineering Task Force, July 2018, Work in progress (draft-ietf-avtcore-cc-feedback-message-02.txt).
We've submitted an update to the RTCP congestion control feedback draft. This makes a number of technical changes, mostly to address feedback from Sergio Mena:
- Notes that the NTP-format timestamp in the reports is derived from the same clock as used for the timestamps in SR packets, not in SR/RR packets (RR packets don't have such a timestamp, only SR).
- Rather than reporting end_seq in the block, report end_seq + 1 to simplify implementations. This also allows a receiver to report the same value in the begin_seq and end_seq + 1fields, to indicate that no data was received.
- Clarify that reports MUST NOT include more than 16384 blocks.
- Update the IANA considerations to register an SDP attribute, and reference the RFC describing how that attribute is used to signal this format.
The remaining known open issue for the draft is whether it should report the beginning and ending sequence numbers or the beginning sequence number and a length.
- Zaheduzzaman Sarker, Colin Perkins, Varun Singh, and Michael A. Ramalho, RTP Control Protocol (RTCP) Feedback for Congestion Control (.txt|.pdf), Internet Engineering Task Force, March 2018, Work in progress (draft-ietf-avtcore-cc-feedback-message-01.txt).
We've submitted an update to the RTCP congestion control feedback draft. This makes a number of technical changes:
- Updates the unit of measurement of the arrival time offset field to use a 1024Hz clock, rather than a 1000Hz clock, to give exact offsets from the Report Timestamp.
- Clarify that if no packets are received from an SSRC in a reporting interval, then no report block is sent for that SSRC. Suggest that a regular SR/RR packet SHOULD be sent instead in this case, since the non-increased extended highest sequence number received field of that SR/RR packet will inform the sender that no packets have been received.
- Give guidance on what sequence number range should be included in each report. State that they should cover consecutive ranges, and not overlap, but state behaviour if they do overlap. State that reports more than one quarter of the sequence number space ahead or behind the previous report MUST be ignored.
- Expand guidance on feedback timing, and reference draft-ietf-rmcat-rtp-cc-feedback for details.
- Clarify that sequence number wrap-around should be accounted for, and note sequence number calculations use modulo arithmetic.
- Rather than leave the format and clock source used for the Report Timestamp (RTS) field unspecified, mandate that it uses the same clock as used for RTCP SR/RR NTP timestamp fields, and is formatted as the middle 32 bits of an NTP format timestamp (as described in Section 4 of RFC 3550).
In addition, there has significant editorial improvements and clarifications throughout. The draft will be discussed at the IETF 101 meeting in London, in a few weeks.
- Zaheduzzaman Sarker, Colin Perkins, Varun Singh, and Michael A. Ramalho, RTP Control Protocol (RTCP) Feedback for Congestion Control (.txt|.pdf), Internet Engineering Task Force, October 2017, Work in progress (draft-ietf-avtcore-cc-feedback-message-00.txt).
This has been adopted as working group draft. The content is identical to draft-dt-rmcat-feedback-message-04.
This draft replaces draft-dt-rmcat-feedback-message-04.