Subject: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports

From: Allison Mankin <[email-masked]>
Date: Wed, 3 Aug 2016 09:54:41 -0400

Hi,

I've reviewed this draft (draft-ietf-rtcpweb-transports-14.txt) as part of
the TSV Area Review Team, paying special attention to transport-related
concerns. Please take these as any other IETF last call comments.

Summary: this draft specifies the mandatory transport protocols (and
transport features) associated with the use of WebRTC media.  It does not
appear to pose any transport-related danger, except perhaps that a
reviewer's head aches over the number of RFCs that are needed to get media
bits from point A to point B, but this is not a fault of the draft.  The
draft is broadly ready for publication as a PS, however there are a few
issues for the Transport Area.

Section 3.4:

   If TCP connections are used, RTP framing according to [RFC4571
<https://tools.ietf.org/html/rfc4571>] MUST
   be used, both for the RTP packets and for the DTLS packets used to
   carry data channels.

About the passage above, RFC4571 doesn't talk about DTLS.  It looks like
this passage also needs a reference to whatever of the specs defines
framing for DTLS?

Section 4.1  Local Prioritization

This section describes the resource allocations that are expected for
prioritized different streams when there is congestion.  There are two
highly relevant congestion control documents that are approved (or nearly
so), and I can't see that the  RTCWB WG considered them from my quick
review of mailing list discussions, but it would be a good idea for this
draft to call them out:

draft-ietf-avtcore-rtp-circuit-breakers-17 - this has enough positions to
pass and is waiting for an AD followup (looks like for the IANA re-review
after a version change).  It puts some additional considerations on flows
that are likely to be relevant to the flows in the present draft.

draft-ietf-rmcat-cc-requirements-09 - this is in the RFC Editor queue and
seems to be waiting for the rtcweb-overview draft, to which it normatively
refers.  I think it would be better if the rmcat draft referenced
rtcweb-transpoarts, and if rtcweb-transports would check on its alignment
with the rmcat requirements in the congestion control remarks in section
4.1.

Section 4.2 Usage of Quality of Service - DSCP and Multiplexing

I will just flag here that I reviewed the mailing list and it seems that
there was a lot of TSV review of the DSCP material here already, and a
consensus reached.

---

From: "Black, David" <[email-masked]>
Date: Wed, 3 Aug 2016 15:03:28 +0000

Hi Allison,

> I will just flag here that I reviewed the mailing list and it seems that there was a lot of TSV review of the
> DSCP material here already, and a consensus reached.

That’s correct - there is also one remaining DSCP issue, namely what to do if use of a non-zero DSCP causes traffic to be black-holed (which could happen in the middle of a WebRTC session, e.g., due to a routing change) . This was discussed in the Berlin RTCWEB meeting and a resolution was agreed to for WebRTC, so there should be a revised version of this rtcweb-transports draft coming soon that specifies what to do.  See the Berlin RTCWEB  minutes for details but the high-level summary is to monitor for black-holing and restart ICE with all-zero DSCP usage in the WebRTC session if black-holing occurs.

Thanks, --David

From: Tsv-art [mailto:[email-masked]] On Behalf Of Allison Mankin
Sent: Wednesday, August 03, 2016 9:55 AM
To: IETF Discussion; [email-masked]; [email-masked]; [email-masked]; IESG
Cc: [email-masked]
Subject: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports

Hi,
I've reviewed this draft (draft-ietf-rtcpweb-transports-14.txt) as part of the TSV Area Review Team, paying special attention to transport-related concerns. Please take these as any other IETF last call comments.
Summary: this draft specifies the mandatory transport protocols (and transport features) associated with the use of WebRTC media.  It does not appear to pose any transport-related danger, except perhaps that a reviewer's head aches over the number of RFCs that are needed to get media bits from point A to point B, but this is not a fault of the draft.  The draft is broadly ready for publication as a PS, however there are a few issues for the Transport Area.
Section 3.4:

   If TCP connections are used, RTP framing according to [RFC4571<https://tools.ietf.org/html/rfc4571>] MUST

   carry data channels.
About the passage above, RFC4571 doesn't talk about DTLS.  It looks like this passage also needs a reference to whatever of the specs defines framing for DTLS?
Section 4.1  Local Prioritization
This section describes the resource allocations that are expected for prioritized different streams when there is congestion.  There are two highly relevant congestion control documents that are approved (or nearly so), and I can't see that the  RTCWB WG considered them from my quick review of mailing list discussions, but it would be a good idea for this draft to call them out:

draft-ietf-avtcore-rtp-circuit-breakers-17 - this has enough positions to pass and is waiting for an AD followup (looks like for the IANA re-review after a version change).  It puts some additional considerations on flows that are likely to be relevant to the flows in the present draft.

draft-ietf-rmcat-cc-requirements-09 - this is in the RFC Editor queue and seems to be waiting for the rtcweb-overview draft, to which it normatively refers.  I think it would be better if the rmcat draft referenced rtcweb-transpoarts, and if rtcweb-transports would check on its alignment with the rmcat requirements in the congestion control remarks in section 4.1.
Section 4.2 Usage of Quality of Service - DSCP and Multiplexing
I will just flag here that I reviewed the mailing list and it seems that there was a lot of TSV review of the DSCP material here already, and a consensus reached.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Aug 2016 11:00:57 +0100

> On 3 Aug 2016, at 14:54, Allison Mankin <[email-masked]> wrote:
> 
> Hi,
> 
> ] MUST

This is listed as “MUST implement” in draft-ietf-rtcweb-rtp-usage-26, which is referenced from Section 3.5 of the rtcweb-transport draft. 

Colin

> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

-- 
Colin Perkins
https://csperkins.org/

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 4 Aug 2016 14:03:51 +0200

Hi Colin,

see below.

> Am 04.08.2016 um 12:00 schrieb Colin Perkins <[email-masked]>:
> 
> 

rtcweb-transport says 
"For transport of media, secure RTP is used.  The details of the profile of RTP used are described in "RTP Usage“ [I-D.ietf-rtcweb-rtp-usage]."

Given that this doc is called "Transports for WebRTC“, I would appreciate if it says slightly more about the recommendations given in rtcweb-rtp-usage, especialy regarding congestion control.

What’s about the following?

"For transport of media, secure RTP is used.  The details of the profile of RTP used are described in "RTP Usage“ [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see [draft-ietf-rmcat-cc-requirements-09] for further guidance).“

Mirja

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Aug 2016 13:07:27 +0100

Hi,

> On 4 Aug 2016, at 13:03, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Colin,
> 
> see below.
> 

No objection, but it’s not my draft to make the change. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 7 Aug 2016 23:30:37 +0200

> No objection, but it’s not my draft to make the change. 

This works for me. New section entitled "Congestion control".
It needs to also mention that SCTP is already congestion-controlled.

---

From: Allison Mankin <[email-masked]>
Date: Sun, 7 Aug 2016 18:22:44 -0400

All sounds good to me. Thank you, Harald and Colin.

On Aug 7, 2016 17:30, "Harald Alvestrand" <[email-masked]> wrote:

> >> "For transport of media, secure RTP is used.  The details of the
> profile of RTP used are described in "RTP Usage“
> [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker
> [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see
> [draft-ietf-rmcat-cc-requirements-09] for further guidance).“
> >

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 8 Aug 2016 18:47:28 +0200

Hi all,

thanks! Having a new section is even better! This could be used to cover all transmissions performed by rtcweb (not only RTP-based media)!

Mirja

> Am 08.08.2016 um 00:22 schrieb Allison Mankin <[email-masked]>:
>