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

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.

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
> 