Re: [rtcweb] DSCP marking for STUN packets

Magnus Westerlund <> Thu, 13 March 2014 12:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BFDFF1A0981 for <>; Thu, 13 Mar 2014 05:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SixH6_u7QPzl for <>; Thu, 13 Mar 2014 05:41:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1EE6C1A0978 for <>; Thu, 13 Mar 2014 05:41:06 -0700 (PDT)
X-AuditID: c1b4fb25-b7f038e000005d01-41-5321a75b4cf4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D5.7A.23809.B57A1235; Thu, 13 Mar 2014 13:41:00 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Thu, 13 Mar 2014 13:40:59 +0100
Message-ID: <>
Date: Thu, 13 Mar 2014 13:40:59 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Justin Uberti <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+JvjW7McsVgg0uXOC22ThWyWPuvnd2i e+l/FgdmjwWbSj2WLPnJ5LHug3kAcxSXTUpqTmZZapG+XQJXxuv1TUwFM8Ur/qzkb2BcJ9TF yMkhIWAi0fTiLjOELSZx4d56ti5GLg4hgUOMEjOvHmSFcJYzSnRv2AlWxSugLXF/w1cwm0VA VWLj7R3sIDabgIXEzR+NbCC2qECwxM4Dvxkh6gUlTs58wgJiiwioSTyctYsVxGYWiJBY3v8M rF5YwFhi6d/9zBDL+pgllk2ZC9bMKRAocWLDayCbA+g8cYmexiCIXk2J1u2/2SFseYnmrbPB 7hECuq2hqYN1AqPQLCSrZyFpmYWkZQEj8ypG9tzEzJz0cqNNjMDAPbjlt+oOxjvnRA4xSnOw KInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUUBXqd/Xqfj9ceG6kO1ch0/wPc2M E7e6zXPc9e+vVVmRfK2+6yPUA/XnHptqeL9kR1b/l/XWRQKnHzrEX3ty3qBwU+lModQZwYvm 3Kq50OjuFVG/J2Gja2eF14lwfgtdhRpPRVYudbNHM+MSboi0G8n/mPCJ9yp3su7xjp/zL126 0jOXZyqrEktxRqKhFnNRcSIATPt7IioCAAA=
Cc: "" <>
Subject: Re: [rtcweb] DSCP marking for STUN packets
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Mar 2014 12:41:10 -0000

On 2014-03-12 17:05, Justin Uberti wrote:
> On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund
> < <>>
> 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.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: