Re: [rtcweb] DSCP marking for STUN packets

[Justin Uberti <[e-mail]>]

On Thu, Mar 13, 2014 at 5:40 AM, Magnus Westerlund <
[e-mail]> wrote:

> On 2014-03-12 17:05, Justin Uberti wrote:
> >
> > On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund
> > <[e-mail] <mailto:[e-mail]>>
> > wrote:
> >
>
> >
> >     Sorry, I don't understand your reasoning here. Is it to provide the
> >     lowest possible drop probability, i.e. using the AFx class that has
> >     least drop probability?
> >
> >
> > The idea is to have the same drop probability as the most critical media
> > that is flowing (e.g. voice), so that we don't end up in a situation
> > where media flows fine, but the media crowds out STUN consent check
> > packets, leading to call failure.
>
> Okay, that makes a certain sense. First of all this is not likely to
> have the "highest" DSCP value. In fact it might not have the lowest drop
> probability either. But, yes it might be prioritized over BE. This is
> assuming that this DSCP marking do work and doesn't prevent the 6-tuple
> to work. But lets take this as a separate issue.
>
> >
> >
> >     If there exist nodes that stomp on some DSCP markings, and not only
> >     remark them to Best Effort (BE), and instead drop then. Then, it is
> not
> >     obvious that that an AFx class is the most appropriate to use. In
> that
> >     case using BE might be more suitable for the consent freshness.
> >
> >
> > If nodes stomp on certain AF-marked packets, and this is widespread,
> > this essentially dooms use of DSCP at all, unless we want to build some
> > sophisticated detection and fallback mechanism. IOW, it's not clear to
> > me that marking packets as BE confers any value over not marking at all.
>
> BE is no marking at all, i.e. DSCP = 0. But, I wanted to be clear that I
> really meant best effort.
>
> But, the question is what we do about nodes that not simple down mark
> DSCP code points !=0. I see some potential solutions.
>
> 1) We recommend that one track the loss rates the different DSCP
> markings individually and in cases when loss rates for some markings
> doesn't match the expected relative behavior between different markings,
> then one stops using DSCP markings and send everything as BE.
>
> 2) One expands the initial STUN exchange to a second round after
> nomination to verify the DSCP code points that one intended to use is
> not being blocked.
>
> The alternative to do something is to ignore the issue. It might be
> small enough that it isn't significant. I don't have data on this. If
> someone has any data source it would be appreciated if they share.
>
>
We could perform an experiment to determine how often this occurs in real
life. I was thinking about having clients send STUN requests with different
DSCP markings to a STUN server, and then analyzing the success rate. Open
to other ideas though.