Re: [rtcweb] DSCP marking for STUN packets

On Mar 11, 2014 7:44 AM, "Harald Alvestrand" <harald@alvestrand.no> 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.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb