DSCP bleaching

[alvestrand]

From Magnus Westerlund in IETF LC:

1. Section 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 (https://irtf.org/anrw/2016/anrw16-final17.pdf) 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?

[alvestrand]

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.

[alvestrand]

From Martin Thomson:

http://www.dictionary.com/browse/resent - 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.