Subject: Re: [rtcweb] Mirja Kühlewind's No Objection on draft-ietf-rtcweb-transports-15: (with COMMENT)

From: Michael Welzl <[email-masked]>
Date: Wed, 28 Sep 2016 09:35:40 +0200

Dear all,

Sorry for re-opening this discussion at such a late stage, but, by way of agreeing with Mirja's comment below that the document should say more about congestion control, I still find it very strange that the text does not cite draft-ietf-rmcat-coupled-cc.

Mirja mentions draft-ietf-rmcat-cc-requirements-09, and I agree that this should be cited, but this requirements document is also generic and does not provide much concrete guidance on how to implement things - so I'd say it's not enough.

draft-ietf-rmcat-coupled-cc-03 is now in WGLC and has so far only received editorial comments. We have lots of proof that this mechanism works very well; whenever it's known that flows share a bottleneck (as is the case for all rtcweb streams between the same hosts), this allows to precisely divide bandwidth among flows based on priorities, and it yields overall lower latency due to reduced on-the-wire competition (well in line with the first requirement laid out in draft-ietf-rmcat-cc-requirements-09). Using the DSCP may protect against other traffic but it's also just hoping for routers to do the right thing. I think that possibilities should be laid out to people intending to implement rtcweb.

Maybe the goal was to avoid a dependency on specific RMCAT congestion controls; I can understand that, but the algorithm in draft-ietf-rmcat-coupled-cc, while containing sections explaining how to apply it to NADA and GCC, is pretty generic and can be quite easily adapted for other controls (as we've successfully done). Accordingly, the draft presents the algorithm as the generic thing that it is.

I brought this missing citation issue up in the past, and it was addressed, but IMO very weakly:

***
> The issue is addressed, but not as you suggested - after taking advice
> from the chairs, I did not reference "coupled" directly, instead
> choosing to reference RFC 7657 and mentioning that it contained advice
> on congestion control.
> 
> I also changed one occurence of "the same congestion controller" to "the
> same congstion control regime", so that this document was neutral about
> whether there was one or multiple congestion controllers.
> 
> Details at https://github.com/rtcweb-wg/rtcweb-transport/issues/16
***

Specifically, let us consider this statement at this URL:

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

Why is it pointless to tell folks who implement rtcweb protocols that this is a possible mechanism to use, and point them directly at it?
I also don't understand the "mistake" about the extensive use of "common (coupled)" in RFC 7657: the outcome is almost identical (again, we have lots of graphs using various congestion controls to prove my point), so what's the problem?

To me, it's very strange and inconsistent that draft-ietf-rtcweb-transports-15 points at draft-ietf-tsvwg-rtcweb-qos for concrete implementation guidance, but doesn't point at draft-ietf-rmcat-coupled-cc for the same; it talks about the possibility of having "multiple streams that are congestion-controlled under the same congestion control regime" but it doesn't give any hint about how to do that (which is what a pointer to draft-ietf-rmcat-coupled-cc would achieve).

Cheers,
Michael

> On 04 Aug 2016, at 15:58, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-rtcweb-transports-15: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for updating!
> 
> Leaving it to this comment:
> Based on the TSV review I agree that this document (named "Transports for
> WebRTC") should say more about congestion control. The TSV reviewer
> (Thanks Allison!) proposes to refer
> draft-ietf-avtcore-rtp-circuit-breakers-17 and
> draft-ietf-rmcat-cc-requirements-09. I would even appreciate to have a 
> sentence that says that congestion control and a circuit breaker is
> mandated in draft-ietf-rtcweb-rtp-usage-26.
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 30 Sep 2016 11:41:48 +0200

Wanting to ask ....

do you have commitment from some of the browser vendors that they intend
to add -coupled to their congestion control code?

That would go a long way towards allaying my fear that this would be
another RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" requirement.

---

From: Michael Welzl <[email-masked]>
Date: Fri, 30 Sep 2016 12:31:21 +0200

> On 30. sep. 2016, at 11.41, Harald Alvestrand <[email-masked]> wrote:
> 
> Wanting to ask ....
> 

No committment, but I did have some hope that you guys at Google would be interested?
Stefan was interested in coupling the data channel with the media channel, which is probably a straightforward way of adapting our coupling algorithm.

We’re going to work on this code ourselves; we already have preliminary code on coupling + shared bottleneck detection in Chromium, but this is work in progress that was interrupted for a year due to a contract that let us focus on coupling TCP for a while (which also works very well, BTW; we’ll provide an update at ICCRG in Seoul). So we’re (well: Safiqul is) just about to get back to it.

> another RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" requirement.

I think what I’m asking for is a far cry from a MUST.
It’s merely about putting a reference there such that implementers see both possibilities (coupling and/or dscp), not only one (dscp).

Cheers,
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 30 Sep 2016 12:59:51 +0200

> It’s merely about putting a reference there such that implementers see both possibilities (coupling and/or dscp), not only one (dscp).

The DSCP section would be the wrong section for it anyway.

References to -coupled should be in the "local prioritization" section
(4.1).

My worry about -coupled in the previous round is that it's a *specific*
instance of coupled congestion controllers (and experimental-track).

We don't yet know if it's *the* way.

That said, I personally wouldn't worry too much about mentioning it, but
it's a post-IESG change without IESG buy-in, so I'll want more
authorization to do that.

Harald

---

From: Michael Welzl <[email-masked]>
Date: Fri, 30 Sep 2016 14:28:20 +0200

> On 30. sep. 2016, at 12.59, Harald Alvestrand <[email-masked]> wrote:
> 

I agree. I didn’t mean for this to be in the same section.

> We don't yet know if it's *the* way.

Understood - but:

1) draft-ietf-rmcat-coupled-cc doesn’t say that the algorithm in it is *the* way. I believe it correctly acknowledges that you could e.g. also have a single congestion control instance for everything ("congestion manager” style coupling). Both implementations have their pro’s and con’s - our algorithm is easier in some ways, e.g. for turning on and off (which is useful when coupling flows to multiple destinations).

2) as I said, we have lots of indications that this algorithm works for *many* controllers with only minimal changes.

Some details:
We successfully used it with NADA and GCC ( http://heim.ifi.uio.no/michawe/research/publications/noms2016.pdf ), but also TFRC and RAP  ( http://heim.ifi.uio.no/michawe/research/publications/csws14.pdf ), LEDBAT ( slide 31: http://heim.ifi.uio.no/michawe/research/publications/caia2014.pdf ), also LEDBAT combined with another congestion control (don’t remember which, maybe RAP), and most recently TCP. TCP is perhaps an extreme case because it has so many states. If you ignore all this and just blindly apply our algorithm, you get pretty much the behavior of E-TCP, which isn’t bad ( http://www.isi.edu/div7/publication_files/effects_of_ensemble.pdf ). We have improved on it by correctly incorporating the states - this makes things better, but note that all of this is better than simply leaving flows as they are and let them compete against each other, in particular when the goal is to minimize latency.

I’d find it pretty strange if this isn’t enough reason to justify a mention of this possibility and a reference.

> authorization to do that.

Sure

cheers,
Michael