- 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.