Subject: [rtcweb] Mirja Kühlewind's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Thu, 04 Aug 2016 02:19:53 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-rtcweb-transports-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks, I think this is a very useful and well written document. Sorry
for my late discuss but I don't think this is anything complicated to
address.
Based on the TSV review I agree that this document should say more about
congestion control. While the TSV reviewer (Thanks Allison!) only
proposes to refer draft-ietf-avtcore-rtp-circuit-breakers-17 and
draft-ietf-rmcat-cc-requirements-09, I would even prefer to have a
normative sentence that says that congestion control MUST be implemented
for all traffic flows. 
Please also provide the update on DSCP  black-holing (in the middle of a
flow) as mentioned by David Black.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 4 Aug 2016 06:51:01 -0700

> On Aug 4, 2016, at 2:19 AM, Mirja Kuehlewind <[email-masked]> wrote:
> 

The new text about this is:

A particularly hard problem is when one media transport uses multiple
   DSCP code points, where one may be blocked and another may be
   allowed.  This is allowed even within a single media flow for video
   in [I-D.ietf-tsvwg-rtcweb-qos <https://tools.ietf.org/html/draft-ietf-rtcweb-transports-15#ref-I-D.ietf-tsvwg-rtcweb-qos>].  Implementations need to diagnose
   this scenario; one possible implementation is to send initial ICE
   probes with DSCP 0, and send ICE probes on all the DSCP code points
   that are intended to be used once a candidate pair has been selected.
   If one or more of the DSCP-marked probes fail, the sender will switch
   the media type to using DSCP 0.  This can be carried out
   simultaneously with the initial media traffic; on failure, the
   initial data may need to be resent.  This switch will of course
   invalidate any congestion information gathered up to that point.

   Failures can also start happening during the lifetime of the call;
   this case is expected to be rarer, and can be handled by the normal
   mechanisms for transport failure, which may involve an ICE restart.

   Note that when a DSCP code point causes non-delivery, one has to
   switch the whole media flow to DSCP 0, since all traffic for a single
   media flow needs to be on the same queue for congestion control
   purposes.  Other flows on the same transport, using different DSCP
   code points, don't need to change.

Alissa