Re: [rtcweb] DSCP marking for STUN packets

[Justin Uberti <[e-mail]>]

On Tue, Mar 11, 2014 at 10:17 AM, Dave Taht <[e-mail]> wrote:

>
> On Mar 11, 2014 7:44 AM, "Harald Alvestrand" <[e-mail]> wrote:
> >
> > On 03/11/2014 03:02 PM, Simon Perreault wrote:
> >>
> >> Le 2014-03-10 16:57, James Polk a écrit :
> >>>
> >>> At 12:16 AM 3/10/2014, Justin Uberti wrote:
> >>>>
> >>>> I think that the existing guidance should be sufficient in
> >>>> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the
> >>>> same DSCP markings as any other ICE connectivity checks should be
> >>>> used; for ICE-for-SCTP checks, the same DSCP markings as media packets
> >>>> (i.e. the SCTP traffic) should be used.
> >>>>
> >>>> If multiplexing is being performed, the connectivity checks probably
> >>>> should use the highest DSCP value being used by the multiplexed media.
> >>>
> >>> why is (seemingly) everyone's default position "use the highest DSCP
> >>> available" for signaling packets?
> >>>
> >>> You just need to make sure the packets aren't starved or dropped by/at
> >>> congestion points.
> >>
> >> The underlying principle is that connectivity checks need to *check
> >> connectivity* (duh!). That's why you use the same DSCP as the media.
> >> Connectivity is affected by the DSCP. For example some DSCPs could be
> >> filtered, or could be placed in a low-priority queue and get dropped
> >> such that connectivity fails.
> >>
> >> >From this principle follows this conclusion: on a given 5-tuple, if
> your
> >> media uses different DSCPs, you need to check connectivity for all those
> >> DSCPs. That is, you would send multiple connectivity checks, one for
> >> each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we might
> >> need an alternative heuristic: try the lowest-priority DSCP, and assume
> >> that if that one works, the higher-priority ones should work as well.
> >> (Note that Justin suggested the contrary.)
> >>
> >> What you want to avoid is STUN packets getting through but not the
> >> corresponding media. That is an unworkable situation. The reverse is not
> >> ideal either (you think you have no connectivity when in fact you do),
> >> but at least ICE can work around it (by picking a different candidate).
> >
> >
> > This explanation makes sense for (ICE) connectivity checks.
> >
> > For other control information, especially information about delay, you
> want to have it delivered as fast as possible, and with as little loss as
> possible, because jitter in the return path will make the delay signal more
> noisy, and lost packets may cause drastic actions like those the
> circuit-breakers draft recommends.
> >
> > Whether that always translates to "the highest DSCP code point" is ....
> a good question.
>
> It doesn't.  Keith added af42 support to mosh last year and had several
> reports of packets being dropped with that marking. Worse the drops
> happened after 10 seconds of connectivity.
>
> Ecn markings on the other hand have thus far survived (if occasionally
> stomped on) across the open internet in that protocol.
>

This is a concern of mine as well, which is why we haven't yet flipped the
switch to turn DSCP on by default in Chrome. I think we'll need to do some
experimentation to see how often DSCP makes things worse.