Mention coupled CC
Closed this issue · 4 comments
From Michael Welzl, rtcweb mailing list, March 2016:
Hi,
On 26 February, I sent an email to rtcweb in which I made some suggestions to this document. I see that these have not been incorporated, and my email has also never been answered (except that I-D.ietf-dart-dscp-rtp was replaced by RFC 7657, but that may not have been due to my email). I can understand that: probably my prior email just drowned in the WebRTC Audio Codec related thread. However I do think that these comments would be good to address, so I'm copying in the email again below.
Cheers,
Michael
Hi,
Overall, I like this document a lot - it makes for a very good read!
- but I think it would make sense for section 4.1 to explicitly point to draft-ietf-rmcat-coupled-cc (the next version of which is going to explain how weights much be set to adhere to the priority levels that are described in this section; it's easy, we just didn't have this text in there yet).
To be concrete, I suggest the following two changes:
When an WebRTC implementation has packets to send on multiple streams
that are congestion-controlled under the same congestion controller,
the WebRTC implementation SHOULD cause data to be emitted in such a
way that each stream at each level of priority is being given
approximately twice the transmission capacity (measured in payload
bytes) of the level below.
should be:
When a WebRTC implementation has packets to send on multiple streams
that are congestion-controlled under the same congestion controller
or multiple coupled congestion controllers (e.g. using the mechanism in
[draft-ietf-rmcat-coupled-cc]),
the WebRTC implementation SHOULD cause data to be emitted in such a
way that each stream at each level of priority is being given
approximately twice the transmission capacity (measured in payload
bytes) of the level below.
(note a fixed nit in there: the second word is "a" instead of "an")
and, perhaps even more importantly, a small change in section 4.2:
More advice on the use of DSCP code points with RTP is given in
[I-D.ietf-dart-dscp-rtp].
should be:
More advice on the use of DSCP code points with RTP as well as coupled
congestion control is given in [I-D.ietf-dart-dscp-rtp].
and in fact I-D.ietf-dart-dscp-rtp should now be RFC 7657.
Cheers,
Michael
@alvestrand - what's your recommendation on this?
@fluffy I regard the mention of coupled CC as mostly "pointless but harmless". The initial decision to mention a single controller was to mention only the most restricted case; if the chairs think extending this to coupled CC is OK, I don't have any strong reason to push back against it.
The extensive use of "common (coupled)" in RFC 7657 is (in my opinion) a mistake; these two are not the same thing, and I can't see that RFC 7657 is really clear about the difference.
individual contributor opinion only here as I the chairs would mostly be trying to figure out list consensus and that mostly seemed fine with current text ... I'm hesitant to introduce in the "coupled" term and ref to draft as it is not clear where all of RMCAT is going yet and it seems like we could have text that was broad enough to include draft-ietf-rmcat-coupled-cc with being explicitly tied to just that. So i'd probbably lean towards something like
More advice on the use of DSCP code points with RTP as well as
congestion control is given in [I-D.ietf-dart-dscp-rtp].
instead of
More advice on the use of DSCP code points with RTP as well as coupled
congestion control is given in [I-D.ietf-dart-dscp-rtp].
only difference is the removal of the word "coupled" at end of first line
I used "congestion control regime" tin section 4.1 - this seems to be wide enough to include both a single congestion controller and multiple coupled congestion controllers.
In section 4.2, I changed it to be "More advice on the use of DSCP code points with RTP and on the relationship between DSCP and congestion control is given in RFC 7657". This seems to achieve the point that you have to read RFC 7657 and references to get the right advice.