Re: [rtcweb] DSCP marking for STUN packets

[Simon Perreault <[e-mail]>]

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

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca