Subject: [rtcweb] Fix for DSCP bleaching issue suggested

From: Harald Alvestrand <[email-masked]>
Date: Tue, 2 Aug 2016 10:23:24 +0200

My proposed text for the DSCP blocking/bleaching issue is here:

https://github.com/rtcweb-wg/rtcweb-transport/pull/30

Note that this differs from what was said at the IETF meeting - after
considering, I didn't see a reason to recommend ICE restart.

The text does not contain MUST or SHOULD. This is implementation advice.
Is this approprate, given the current state of our knowledge of the issue?

Diff:

@@ -344,6 +344,18 @@
         of packets with certain DSCP markings. The detection of these
         conditions is implementation dependent.</t>

+        <t>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 for video in <xref
+        target="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 transport 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.</t>
+
         <t>All packets carrying data from the SCTP association
supporting the
         data channels MUST use a single DSCP code point. The code point
used
         SHOULD be that recommended by <xref

Comments welcome, especially if they come today! - the item is on
Thursday's telechat, and it would be nice to release a fixed version
well before the telechat.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Aug 2016 20:43:53 +1000

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.

On 2 August 2016 at 18:23, Harald Alvestrand <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 2 Aug 2016 18:00:24 +0200

> DSCP 0.  If DSCP M succeeds, then you could continue to use that; your
The particular case I'm worried about is video with AF42 on the level-0
frames and AF43 on the level-1 frames; the congestion control works
because AF43 is guaranteed to be delivered through the same queueing as
AF42, just with larger drop probability (I may have the language wrong
here).

So if AF43 isn't making it, you want to go to DSCP 0 for both
components, because otherwise they aren't in the same queue any more.

If I'm right, I may need to emphasize that point. (If I'm wrong, I need
to change my mind of course!)
> have negative effects on things like congestion controllers and loss
Yup. The effect should be less disruptive than an ICE restart, however.

-- 
Surveillance is pervasive. Go Dark.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 4 Aug 2016 11:23:44 +0200

> http://www.dictionary.com/browse/resent - I know what you mean, of course.

:-)
the word seems strangely appropriate :-)

> have negative effects on things like congestion controllers and loss

After chewing this over in my head for another day, I added two more
paragraphs and a bit. New text:

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 .
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.

I'll incorporate this in -15; if we need to tweak more, this needs to go
into -16 (if any).

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 4 Aug 2016 06:30:18 -0700

On Aug 2, 2016, at 01:23, Harald Alvestrand <[email-masked]> wrote:
> +        probes with DSCP 0,

[BA]Seems reasonable.

> and send ICE probes on all the DSCP code points

[BA] Not sure what "probe" means here - are you referring to keepalives and/or consent checks?

> +        with the initial media traffic; on failure, the initial data

[BA] Losing a single consent check does not tell you much, and if some consent checks with a marking were responded to, changing markings based on a subsequent loss is most probably a bad idea. Does "resent" refer to RFC 4588 (RTX)?

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 6 Aug 2016 07:59:06 +0200

Bernard, you reinforce my fear of on-the-fly protocol design!

The previous (pre-15) text tried to push all that stuff into
"implementors have to do something". As soon as advice gets more
specific, it also risks being wrong.

When writing "probe", I was thinking of STUN binding requests as used in
RFC 7675 consent (they solicit an identifiable answer, don't require
receiver state, and are supported by all conforming ICE
implementations). I didn't remember the name of the function while writing.

Finding that traffic sent with a specific DSCP code point has been
delivered (for instance by RTCP feedback) is also a clear indication
that this DSCP codepoint isn't blackholed; it should be mentioned.