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.
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).
alvestrand
commented
7 years ago
From Michael Welzl on the rtcweb mailing list:
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:
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