ietf
[Top] [All Lists]

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

2016-08-03 10:04:23
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 [mailto:tsv-art-bounces(_at_)ietf(_dot_)org] On Behalf Of Allison 
Mankin
Sent: Wednesday, August 03, 2016 9:55 AM
To: IETF Discussion; tsv-art(_at_)ietf(_dot_)org; 
draft-ietf-rtcweb-transports(_at_)tools(_dot_)ietf(_dot_)org; 
cullenfluffyjennings(_at_)gmail(_dot_)com; IESG
Cc: amankin(_at_)salesforce(_dot_)com
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

   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.