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

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 8 Dec 2021 10:41:23 +0000

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 8 Dec 2021 23:10:57 +0000

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

Colin

> On 8 Dec 2021, at 10:41, Gorry Fairhurst <[email-masked]> 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.
> 
> [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
> - 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:

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 28 Dec 2021 16:57:26 +0000

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

> [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…

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

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

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

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.

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

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

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

> 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 ex…

Sure.

> 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 t…

Sure.

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 28 Dec 2021 17:56:10 +0000

> Thank you for the helpful comments. Some responses inline, and I’ve updated the draft to try to address your feedback.

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. I 
think the document is now good.

Best wishes,

Gorry