Re: [rtcweb] DSCP marking for STUN packets

[Justin Uberti <[e-mail]>]

On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault <
[e-mail]> 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).
>

We also need to consider the scenario of STUN consent checks, which will
need to get through reliably even when media marked with DSCP is already
flowing. In this case I think that using the highest DSCP value for STUN is
unavoidable.