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

From: [email-masked]
Date: Mon, 06 Jun 2016 01:06:01 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF.

        Title           : Transports for WebRTC
        Author          : Harald Alvestrand
	Filename        : draft-ietf-rtcweb-transports-13.txt
	Pages           : 17
	Date            : 2016-06-06

Abstract:
   This document describes the data transport protocols used by WebRTC,
   including the protocols used for interaction with intermediate boxes
   such as firewalls, relays and NAT boxes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Welzl <[email-masked]>
Date: Mon, 6 Jun 2016 10:37:58 +0200

.... and my suggestions below are still not addressed.

Cheers,
Michael

> Begin forwarded message:
> 
> From: Michael Welzl <[email-masked]>
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-12.txt
> Date: 23 Mar 2016 09:40:44 CET
> To: Harald Alvestrand <[email-masked]>
> Cc: [email-masked]
> Resent-From: <[email-masked]>
> 
> 
>> On 22 Mar 2016, at 16:14, Harald Alvestrand <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 7 Jun 2016 10:39:54 +0200

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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 7 Jun 2016 11:13:02 +0200

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 <[email-masked]> wrote:
>