Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
In Section 7. there is discussion that CCFB will replace the ECN FB format. I find that appropriate however there is one function in ECN FB format that is not discussed here. Section 7.2.1 in RFC 6679 states An immediate or early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD be generated on receipt of the first ECT- or ECN-CE-marked packet from a sender that has not previously sent any ECT traffic. Each regular RTCP report MUST also contain an ECN Summary Report (Section 5.2). Reception of subsequent ECN-CE-marked packets MUST result in additional early or immediate ECN feedback packets being sent unless no timely feedback is required. There are no specification in this document that says that on reception of ECN-CE marks the feedback packet should be sent using early or immediate. That might not be required given a correctly configured session, where reporting occur on the time scale. However, I think some discussion of the usage of early reporting for ECN-CE mark is needed if longer reporting intervals are used. Where there any discussion in the WG of this subject?
A. Section 3.1: The document in one paragraph states the below: The value of num_reports MAY be zero, indicating that there are no packet metric blocks included for that SSRC. When reading this I did wonder what value should be set. This is given almost at the end of the section in the below sentence. If no packets are received from an SSRC in a reporting interval, a report block MAY be sent with begin_seq set to the highest sequence number previously received from that SSRC and num_reports set to zero (or, the report can simply to omitted). I think it would be clearer if the recommendation for begin_seq when num_reports = 0 to be stated in the context of the first one. Then a more focused sentence for the second part can explain the context in that paragraph. B. Section 11: Since RTP is an unreliable transport, a sender can intentionally leave a gap in the RTP sequence number space without causing harm, to check that the receiver is correctly reporting losses. I think "without causing harm" is overstating it. I think without serious harm is more correct. Depending on jitter buffer and usage of NACK to report packet loss a gap in the sequence number can have cause retransmission requests. Also if the gap is in the wrong place in a packet sequence, for example in the middle of sequence of packets for a single video frame it could trigger a repair action despite all data have been received. I would state it is possible to insert gap with some consideration for the media so that minimal impact is had.
Section 1 control designs are not interoperable. To enable algorithm evolution as well as interoperability across designs (e.g., different rate adaptation algorithms), it is highly desirable to have generic congestion control feedback format. nit: singular/plural mismatch "format"/"to have generic". To help achieve interoperability for unicast RTP congestion control, this memo proposes a common RTCP feedback packet format that can be (side note) is there work underway for non-unicast RTP congestion control? Section 2 In addition the terminology defined in [RFC3550], [RFC3551], [RFC3611], [RFC4585], and [RFC5506] applies. [3551 and 3611 don't seem to have prominent dedicated "definitions" sections.] Section 3.1 o L (1 bit): is a boolean to indicate if the packet was received. 0 represents that the packet was not yet received and all the subsequent bits (ECN and ATO) are also set to 0. 1 represents that the packet was received and the subsequent bits in the block need to be parsed. (side note) it's tempting to parse this as the "loss bit", but then a value of true means not-lost and false means lost, which feels somewhat unnatural. That said, preserving all-bits-zero as "no data" is probably worth the tradeoff... sent previous reports for RTP packets included in both reports. If an RTP packet was reported as received in one report, that packet MUST also be reported as received in any overlapping reports sent later that cover its sequence number range. What should a recipient do if this invariant is violated? Tear down the RTP session as a protocol violation? Section 4 feedback, using a feedback interval range of 50-200ms. Applications need to negotiate an appropriate congestion control feedback interval at session setup time, based on the choice of congestion control algorithm, the expected media bit rate, and the acceptable feedback overhead. Are there protocol mechanisms standardized that can perform this negotiation? (I note that though we provide SDP signalling for the use of CCFB overall, we do not define SDP signalling for the feedback interval.) Section 7 provides duplicate information. Accordingly, when congestion control feedback is to be used with RTP and ECN, the SDP offer generated MUST include an "a=ecn-capable-rtp:" attribute to negotiate ECN support, along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" to indicate that the RTP Congestion Control Feedback Packet is to be used for feedback. The "a=rtcp-fb:" attribute MUST NOT include the "nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be used. Am I reading this correctly that a "mixed" deployment with Offerer that supports both mechanisms and an Answerer that only supports RFC 6679 will result in ECN not being used for the RTP session at all, even though 6679 is supported by both parties? Why does it not suffice to only constrain the Answer behavior? Section 8 control. TMMBR could, however, be viewed a complementary mechanism that can inform the sender of the receiver's current view of acceptable maximum bit rate. The Received Estimated Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb] provides similar feedback. The REMB I-D expired in 2014; is it still useful to reference it by name (as opposed to a representative of a class)? Contrast to draft-holmer-rmcat-transport-wide-cc-extensions, which expired in 2016, but we reference only as an example of the class of schemes that adds a transport-wide sequence number to each RTP packet. RTCP Extended Reports (XR): Numerous RTCP extended report (XR) blocks have been defined to report details of packet loss, arrival times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It is possible to combine several such XR blocks into a compound RTCP packet, to report the detailed loss, arrival time, and ECN marking marking information needed for effective sender-based congestion control. However, the result has high overhead both in terms of bandwidth and complexity, due to the need to stack multiple reports. If I am reading correctly, RFC 6679 only provides ECN counters, not necessarily at packet granularity, so it may not actually provide as much information as this mechanism. Section 9 Are the named individuals the members of the design team? If not, where can the membership of the design team be determined? Section 11 I look forward to the clarification regarding off-path attacks produced in response to the tsv-art review. In theory the exposure of (somewhat) fine-grained timing information at per-packet granularity could open up new attacks that look for side channels in processing of other protocols operating between the same endpoints, but I am not really convinced that millisecond-scale information presents enough exposure to merit mentioning here. congestion on the path. This will negatively impact the quality of experience of that receiver. Since RTP is an unreliable transport, a And potentially other entities using the bottleneck segment of that path? Also could potentially cause excessive resource consumption on the sender? sender can intentionally leave a gap in the RTP sequence number space without causing harm, to check that the receiver is correctly reporting losses. [I assume that recommended remediation measures in the face of such a lying peer are covered in the referenced documents already.] An on-path attacker that can modify RTCP congestion control feedback packets can change the reports to trick the sender into sending at either an excessively high or excessively low rate, leading to denial of service. The secure RTCP profile [RFC3711] can be used to authenticate RTCP packets to protect against this attack. I guess to try to do this off-path you'd need to guess the SSRCs and sequence-numbers (mod 2**16) in addition to transport ports, which quickly becomes infeasible if there's more than one stream, so it really is just an off-path threat. Section 12.1 It seems that we only list 3611 as normative for the terminology reference, but I didn't see any terminology usage that we clearly needed 3611 for.
Thanks to the SECDIR reviewer, Linda Dunbar.
It sounds like Colin is addressing the tsvart review, so thanks. In section 5, can you clarify (or provide a reference) how to detect RTCP packet loss? Is this simply a matter of receiving them at less than the configured rate?
[[ questions ]] [ section 3.1 ] * If L=0, do we need text about how to treat report entries with non-zero ECN and ATO fields? Separately, what's a good mnemonic for "L"? My instinct was to treat it as the "Loss" bit, but with the meaning the values 0 and 1 reversed that doesn't actually work very well. [[ nits ]] [ section 1 ] * "to have generic...format" -> "to have a generic...format", perhaps [ section 3.1 ] * "sent previous reports" -> "previous reports sent", perhaps? [ section 7 ] * "a=ecn-capaable-rtp:" -> "a=ecn-capable-rtp:" [ section 8 ] * "ECN marking marking information" -> "ECN marking information"
No objection, but I'm wondering how Rob knows that this isn't actually 5 1/2 bits?! :-P
Thank you for the work put into this document. Please find below a couple of non-blocking COMMENT points and nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 3.1 -- In "but overlapping reports MAY be sent (and need to be sent in cases" should the "need" be a "MUST" ? -- Section 5 -- In "then the sender SHOULD rapidly reduce", "sender" is somehow ambiguous: is it the feedback transmitter or the media source sender ? -- Section 6 -- The mandatory use of "*" appears strange to the non-SDP expert (like myself). Why transmitting something that is always identical? What is the value ? == NITS == -- Section 3.1 -- As some reader may also wonder like me, why the use of 'L' (at least I am puzzled)? why not giving one word mnemonic to explain the logic behind this choice ? -- Section 7 -- Is there a typo in ""a=ecn-capaable-rtp:"" ? it is probably redundant to again expand ECN.
Hi, Thanks for this document, I found it pretty easy to read, and it looks useful. One minor nit on your packet diagram: Due to where the '|' character is, it looks like the FMT-CCFB field is 5 and half bits long, which probably isn't intended! Regards, Rob