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

"Black, David" <> Wed, 03 August 2016 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBC3212D1B1; Wed, 3 Aug 2016 08:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=WL6SVh7y; dkim=pass (1024-bit key) header.b=Z5JXO0Ke
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LeY_EhI1c3OC; Wed, 3 Aug 2016 08:04:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B81B12B058; Wed, 3 Aug 2016 08:03:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=jan2013; t=1470236631; x=1501772631; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=W0+B0XG88NJHXvLRdFFNNKQNbatK5ceW2twFAAr1xrI=; b=WL6SVh7yVRl4V9isXlQJgDvZCIQQwi84CHRs5ZKoSxDPvAtxfjz12vFh FqijNGl9Nqu9Vkp711JVjkz75nj6tF+PKw44Dn3tHPkaQ8iqYxfd5O5YF +dfBedfkVAHfrf0FJMsZAlqRAsGji7Nkrt0aGwY2TEtq8BRK7qHST/yYb Q=;
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2016 20:03:49 +0500
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u73F3kJD007679 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Aug 2016 11:03:47 -0400
X-DKIM: OpenDKIM Filter v2.4.3 u73F3kJD007679
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1470236628; bh=6mXAgIIkK/faLckG/qGSaMyNIUQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Z5JXO0KeY/SrVPPJ0Sd4wAsfF+lhftUZNYiipVa1qi0BvZxNot0Fkv7cDvjmEd1TA O6Rsch++vrwuz4mHHcvubZwTVtn3HzMZI4Bu2HFjJaJJ2rXTY55FTARXVzB+jLlJQ8 qu3LjD7DbeBlq32GSvLV/JxG/b7O8i50kqZjSjdM=
X-DKIM: OpenDKIM Filter v2.4.3 u73F3kJD007679
Received: from ( []) by (RSA Interceptor); Wed, 3 Aug 2016 11:03:11 -0400
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u73F3Sqs005782 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 3 Aug 2016 11:03:28 -0400
Received: from ([fe80::849f:5da2:11b:4385]) by ([]) with mapi id 14.03.0266.001; Wed, 3 Aug 2016 11:03:27 -0400
From: "Black, David" <>
To: Allison Mankin <>, IETF Discussion <>, "" <>, "" <>, "" <>, IESG <>
Subject: RE: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports
Thread-Topic: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports
Thread-Index: AQHR7Y9r4XRzbcD7WUimeTP7mKL0wqA3UNNA
Date: Wed, 3 Aug 2016 15:03:28 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F622F20MX307CL04corpem_"
MIME-Version: 1.0
X-RSA-Classifications: public
Archived-At: <>
Cc: "Black, David" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Aug 2016 15:04:04 -0000

Hi Allison,

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

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 [] On Behalf Of Allison Mankin
Sent: Wednesday, August 03, 2016 9:55 AM
To: IETF Discussion;;;; IESG
Subject: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports

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