Draft: rtcweb-transports

Commentary: Note that this differs from what was said at the IETF meeting - after considering , I did n't see a reason to recommend ICE restart . The text does not contain MUST or SHOULD . This is implementation advice . 
 FWIW ... This looks good to me 
 Per  , need to be explicit that switching to DSCP 0 needs doing for the media type as a whole , because the DSCP codepoints in a transport are chosen for compatibility on classes ( AF4x for instance ) . 
 From Magnus Westerlund in IETF LC : 4.2 : The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings . The detection of these conditions is implementation dependent . As raised on the TSVWG and RTCWEB mailing list recently in regards to draft - ietf - tsvwg - rtcweb - qos there have been a recent study ( ) showing that non zero DSCP values resulted in consistent failures in 10 - 13 % of the tested paths . So I think it worth considering if this text needs to be sharpen , and possibly actually point to a solution that needs to be specified ? 
 Resolution in WG in Berlin : " We will treat DSCP - induced path failure parallel with other types of path failure , and resolve it by using an ICE restart " . Note : There is a problem with multiple DSCP codepoints on a single transport , where one might be blocked and another might get through . In this case , the ICE probes ( using one DSCP code point ) may succeed while others fail . This is complex , and should be warned about - likely mode of solution is ICE restart with DSCP markings turned off , but detection requires watching the multiple DSCP - codepoint - using channels for differential failures . See minutes for details . 
 From   : - I know what you mean , of course . Presumably if DSCP 0 passes , but probes with DSCP N fails , only traffic that was intended to be sent with DSCP N would be sent with DSCP 0 . If DSCP M succeeds , then you could continue to use that ; your text implies otherwise . You might like to point out that switching DSCP marking mid - flow can have negative effects on things like congestion controllers and loss recovery .
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.  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.