Re: [rtcweb] DSCP marking for STUN packets

Magnus Westerlund <> Wed, 12 March 2014 08:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 919D31A0913 for <>; Wed, 12 Mar 2014 01:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iWzD9_GaZLul for <>; Wed, 12 Mar 2014 01:03:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F7961A0910 for <>; Wed, 12 Mar 2014 01:03:27 -0700 (PDT)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-92-532014c9d36b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9C.9F.04853.9C410235; Wed, 12 Mar 2014 09:03:21 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Mar 2014 09:03:20 +0100
Message-ID: <>
Date: Wed, 12 Mar 2014 09:03:20 +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 <>, Simon Perreault <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvje5JEYVgg4Y2MYutU4Us1v5rZ7fo XvqfxYHZY8GmUo8lS34yeaz7YB7AHMVlk5Kak1mWWqRvl8CVMf+tS8FBpYrHT6YxNjC+lupi 5OCQEDCR6Prh2sXICWSKSVy4t56ti5GLQ0jgBKNEy+Eb7CAJIYHljBILH4eC2LwC2hILNi9m A7FZBFQltjT9B7PZBCwkbv5oBLNFBYIldh74zQhRLyhxcuYTFhBbRCBcYsr7LmYQm1lAXeLO 4nNg84UFjCWW/t3PDLF4JZPE08szwBo4BQIl7jx7yg5xqLhET2MQRK+exJSrLYwQtrxE89bZ zBB3aks0NHWwTmAUmoVk9SwkLbOQtCxgZF7FKFmcWlycm25koJebnluil1qUmVxcnJ+nV5y6 iREY2Ae3/DbawXhyj/0hRmkOFiVx3uusNUFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFU2 Ox09FXbmmLWCcMkZPt0TCccstgoYxOQt/B0/ReQ4r+KjYOkrc4PMSxxmfjXoU/B3v1PU+GCt a4HW/u+/98pmrL3btkB1cnyj0rSrPpHtxy/1hzUuFjQT6DjwtKrqMq9zaepSpk9bXb2Vcz0/ vsz81VVS9Mlj88Vg1Q0/Nr5Z/UPKf6lBhRJLcUaioRZzUXEiAITC05s6AgAA
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: Wed, 12 Mar 2014 08:03:29 -0000

On 2014-03-12 04:53, Justin Uberti wrote:
> On Tue, Mar 11, 2014 at 7:02 AM, 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).
> 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.

(as individual)

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?

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.

I would also point out that highest DSCP value isn't clear. We are
talking about forwarding behavior and I don't see how Expedited
Forwarding (EF) can be compared with AF for example.

I think we have to consider what our goals are here. To determine if we
can get any packets through or determine if a particular 6-tuple (Source
Address, Destination Address, Source Port, Destination Port, Protocol,
and DSCP value) works? If it is the later then I think we need to have
checks running on all the 6-tuples in use. This clearly have overhead
concerns and helps worsening the ICE The Voice Hammer Attack (See
section 18.5.1. of RFC 5245).

If the goal is the first, isn't using BE a reasonable choice. Yes, it
might have higher drop probability than AF, but it is likely to be
robuster in general deployments and it determine if the peer is there or
not. Dealing with broken 6-tuples needs to be a separate issue.


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: