search

rtcweb-wg / rtcweb-transport

draft-ietf-rtcweb-transport
2 stars 2 forks source link

Mention coupled CC #16

Closed alvestrand closed 8 years ago

alvestrand commented 8 years ago

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!

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

fluffy commented 8 years ago

@alvestrand - what's your recommendation on this?

alvestrand commented 8 years ago

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

fluffy commented 8 years ago

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

alvestrand commented 8 years ago

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.