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

[Alissa Cooper <[e-mail]>]

> On Aug 4, 2016, at 2:19 AM, Mirja Kuehlewind <[e-mail]> wrote:
> 
> 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.

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

> 
> 
> 
>