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

From: [email-masked]
Date: Mon, 21 Mar 2016 15:37:32 -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-12.txt
	Pages           : 17
	Date            : 2016-03-21

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

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

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: Tue, 22 Mar 2016 15:45:25 +0100

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Mar 2016 16:14:01 +0100

Thank you - yes, it was lost.

I've filed this suggestion as
https://github.com/rtcweb-wg/rtcweb-transport/issues/16

My queries are of course:

- Is the reference to [coupled] normative or informative?
- What is the expected timeline for emission of [coupled]?

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.

---

From: Michael Welzl <[email-masked]>
Date: Wed, 23 Mar 2016 09:40:44 +0100

> On 22 Mar 2016, at 16:14, Harald Alvestrand <[email-masked]> wrote:
> 

Thanks!

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

> The "e.g." in your first suggestion might be loose enough to warrant an

Well, I find it strange for I-D.ietf-tsvwg-rtcweb-qos to be normative and [coupled] to be informative.

Cheers,
Michael