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

[Gorry Fairhurst <[e-mail]>]

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