Re: [rmcat] Feedback from WGLC for draft-ietf-rmcat-rtp-cc-feedback-07

[Colin Perkins <[e-mail]>]

> On 28 Dec 2021, at 17:56, Gorry Fairhurst <[e-mail]> wrote:
> On 28/12/2021 16:57, Colin Perkins wrote:
>> Hi Gorry,
>> 
>> Thank you for the helpful comments. Some responses inline, and I’ve updated the draft to try to address your feedback.
>> 
>> Cheers,
>> Colin
> 
> Thanks for doing this - these all seem reasonable updates! I note you dodged the provacative probe into "a sensible minimum frequency", which I think ought to have been asked, but your answer was sufficient.

Thanks – that’s an interesting problem, but outside the scope of what this draft can address, except as general guidance. 

Colin



> I think the document is now good.
> 
> Best wishes,
> 
> Gorry
> 
>> 
>> 
>>> On 8 Dec 2021, at 10:41, Gorry Fairhurst <[e-mail]> wrote:
>>> 
>>> I read  draft-ietf-rmcat-rtp-cc-feedback-07 in response to a WGLC request. I think this provides useful information to help guide developers and configuation of systems and would support publication.
>>> 
>>> I expect the calculations should be explicitly reviewed by a relevant expert, but have no doubts about them myself. I reviewed previous versions and I do have  comments, which all appear to be editorial - rather than questioning the advice.
>>> 
>>> Sorry for the delay in submitting this review.
>>> 
>>> Best wishes,
>>> 
>>> Gorry
>>> 
>>> ---
>>> 
>>> TEXT:
>>> To ensure the
>>>    stability of the network in the face of this use, WebRTC systems need
>>>    to use some form of congestion control for their RTP-based media
>>>    traffic.
>>> 
>>> - This seems true, but it doesn’t say where this is said.
>>> [RFC2914] describes the best current practice for congestion control in the Internet, and [RFC8085] provides specific guidelines for traffic using datagram protocols. I think we need to assert more stronly that CC is important.
>> The WebRTC specifications make this assertion, but I’m happy to repeat it here. I added some words to the Introduction about the importance of effective congestion control to the user experience and for protecting the network, and cited those RFCs.
>> 
>>> ---
>>> MULTICAST?
>>> - Multicast is ignored, but was mentioned in RFC8085, and I think some statement should be made including or excluding this from this ID's scope.
>> This is unicast only. I assumed some words to the Introduction to clarify.
>> 
>> I also added some words to the Introduction stating what RTCP extensions are assumed to be available.
>> 
>>> ---
>>> TEXT:
>>> Traditional congestion control protocols, such as TCP, send acknowledgements with every packet (or, at least, every   couple of packets).
>>> - This seems true -the word couple can mean 2 - and the receiver is required to ACK for 2*MSS, which is subtly different.
>> I adjusted the wording to try to make this more precise.
>> 
>>> However, my point isn’t really this. What matters is what the sender *receives* and due to GRO, etc and ACK manipulation in the network, the observed frequency of TCP ACKs can be much less than the TCP stack sends. Stretch ACKs are in fact common, covering several consecutive segments. I wonder if we need slightly more careful wording?
>> I added a mention of stretch-ACKs, primarily as a motivating example for sending less frequent congestion feedback for non-TCP transports.
>> 
>>> ---
>>> TEXT:
>>> As long
>>>    as feedback is sent frequently enough that the control loop is
>>>    stable, and the sender is kept informed when data leaves the network
>>>    (to provide an equivalent to ACK clocking in TCP), it is not
>>>    necessary to report on every packet at the instant it is received
>>>    (indeed, it is unlikely that a video codec can react instantly to a
>>>    rate change anyway, and there is little point in providing feedback
>>>    more often than the codec can adapt).
>>> - I agree, but one of the concerns could be that other flows that share a common bottleneck may have a different RTT. That implies the need to be responsive to the needs of these flows. Whereas an application could itself be stable when operating with occasional feedback of many RTTs, that could induce starvation of other flows. It is impossible to react to any remote feedback in less than a RTT of course, so steps to send much more frequently might have little benefit from this perspective.
>> I don’t disagree, but there are some difficult trade-offs here. TCP’s RTT dependence and the stretch-ACK issue mentioned above lead to unfairness between TCP flows that’s of the order of the unfairness likely caused by infrequent RTCP feedback. Further, for low rate multimedia flows, sending feedback sufficiently often to allow fairness with TCP on the forward path will generate feedback traffic of comparable rate, but non-congestion controlled, on the reverse path. I added a paragraph to discuss the issue, noting that potential unfairness needs to be balanced against feedback overheads.
>> 
>>> ----
>>> GENERAL COMMENT:
>>> This analysis considers the needed RTCP bandwidth, but could easily also note the RTCP rate/RTT, which can also be important.
>>> I proposed the following text for QUIC, which might also be useful here in some form, basically saying that “volume of feedback data” is not the only constraint - for some types of network, the rate of feedback also impacts the efficiency fo the overall system, perhaps something like:
>>> “Generating and processing acknowledgments consumes resources at a sender and receiver.  Acknowledgments also incur forwarding costs and
>>> contribute to link utilization, which can impact performance over some types of network, which can be congested by the rate of feedback as well as the volume of feedback bytes.”
>>> - Of course, a sender or receiver is usually unaware of how the path network segments actually behave.
>> There’s also the impact of packet delivery time due to the presence of potentially large feedback packets on the link. Added, in modified form.
>> 
>>> ---
>>> GENERAL COMMENT:
>>> Some analysis in the past has suggested feedback at least twice per RTT. Arguments for more than once per RTT include, as I recall:
>>> * Some robustness to loss. Loss is often a feature of congestion, and some network segments experience congestion of the medium - and hence can show loss in both directions.
>>> * Better RTT estimation, since CC responsiveness can be linked to RTT, this can help detect a change in RTT.
>> I added a mention of these issues to the end of Section 2, noting again that there’s a trade-off to make.
>> 
>>> ---
>>> SECTION 4:
>>> - I’d hoped to see here a sentence about once per RTT as being a sensible minimum frequency??
>> I’m not convinced that is a sensible minimum frequency, balancing feedback overhead against congestion control effectiveness. It’s certainly possible, and perhaps desirable, in some cases. In other cases, the overhead of sending such frequent feedback would outweigh the benefit.
>> 
>>> - When mentioning effective control, this may be a good place to remind why CC is important e.g.  Section 3.1 of [RFC8085] provides some guidelines.
>> Happy to point to that guidance.
>> 
>>> ---
>>> GENERAL COMMENT:
>>> I did not see any mention of other control packets that would be sent: NAPT keep alive or STUN/TURN, DNS, etc etc; not that these in any way change the results, but it could be nice to note they exist.
>> Sure.
>> 
>>> ---
>>> ROHC/IPHC:
>>> With the “advent” (subtle Christmas reference) off QUIC, I’ve been recommending satellite systems to generally use ROHC/IPHC to compress return path traffic. This can have a significant effect on the volume of feedback bytes for smaller packets. It may be worth noting here.
>> Sure.