Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-13.txt

Sorry!  Sure enough, I only searched for "coupled" to see if this was addressed   :)
My bad.

I agree with how you did this, it's fine. Thanks!

Cheers,
Michael

> On 07 Jun 2016, at 10:39, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> Den 06. juni 2016 10:37, skrev Michael Welzl:
>> .... and my suggestions below are still not addressed.
> 
> 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
> 
> I have to spin a new version anyway, since the TSVWG and RTCWEB chairs
> requested a comment on interactive vs non-interactive video:
> 
> https://github.com/rtcweb-wg/rtcweb-transport/issues/19
> 
> but unless I get more advice on this one, I'll leave it as-is.
> 
> 
>> 
>> Cheers,
>> Michael
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: Michael Welzl <michawe@ifi.uio.no>
>>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-12.txt
>>> Date: 23 Mar 2016 09:40:44 CET
>>> To: Harald Alvestrand <harald@alvestrand.no>
>>> Cc: rtcweb@ietf.org
>>> Resent-From: <michawe@ifi.uio.no>
>>> 
>>> 
>>>> On 22 Mar 2016, at 16:14, Harald Alvestrand <harald@alvestrand.no> wrote:
>>>> 
>>>> Thank you - yes, it was lost.
>>>> 
>>>> I've filed this suggestion as
>>>> https://github.com/rtcweb-wg/rtcweb-transport/issues/16
>>> 
>>> Thanks!
>>> 
>>> 
>>>> My queries are of course:
>>>> 
>>>> - Is the reference to [coupled] normative or informative?
>>> 
>>> Seeing that you made I-D.ietf-tsvwg-rtcweb-qos a normative reference, I'd say this one should be normative too. For streams that are known to share a bottleneck (e.g. between the same hosts and multiplexed), this *always* works, not only when routers on your path happen to support it.
>>> 
>>> 
>>>> - What is the expected timeline for emission of [coupled]?
>>> 
>>> I think we're quite close to the finish line. (I'll follow up with a private email)
>>> 
>>> 
>>>> I see that RFC 7657 got published with [coupled] as an informative
>>>> reference.
>>>> The "e.g." in your first suggestion might be loose enough to warrant an
>>>> informative reference.
>>> 
>>> Well, I find it strange for I-D.ietf-tsvwg-rtcweb-qos to be normative and [coupled] to be informative.
>>> 
>>> Cheers,
>>> Michael
>>> 
>>> 
>>> 
>>>> 
>>>> Den 22. mars 2016 15:45, skrev Michael Welzl:
>>>>> 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!
>>>>> 
>>>>> - but I think it would make sense for section 4.1 to explicitly point to draft-ietf-rmcat-coupled-cc (the next version of which is going to explain how weights much be set to adhere to the priority levels that are described in this section; it's easy, we just didn't have this text in there yet).
>>>>> 
>>>>> 
>>>>> 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
>>>>> 
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 