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

[Colin Perkins <[e-mail]>]

Thanks, Gorry. These are all good points, that I’ll address in a revision.

Colin



> 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.
> ---
> 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.
> ---
> 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. 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?
> ---
> 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.
> ----
> 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.
> ---
> 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.
> ---
> SECTION 4:
> - I’d hoped to see here a sentence about once per RTT as being a sensible minimum frequency??
> - 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.
> ---
> 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.
> ---
> 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.
> ---
> NiTs:
> - is /point to point/ hyphenated?
> -- 
> G. Fairhurst, School of Engineering
> 
> 



-- 
Colin Perkins
https://csperkins.org/