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

> On 30. sep. 2016, at 11.41, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> Wanting to ask ....
> 
> do you have commitment from some of the browser vendors that they intend
> to add -coupled to their congestion control code?

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.

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

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

> 
> 
> Den 28. sep. 2016 09:35, skrev Michael Welzl:
>> 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 <ietf@kuehlewind.net> 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
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 