Re: [rtcweb] DSCP marking for STUN packets

Magnus Westerlund <> Mon, 10 March 2014 14:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 22EF41A0489 for <>; Mon, 10 Mar 2014 07:24:48 -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 wFqhnzDZKsd1 for <>; Mon, 10 Mar 2014 07:24:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6ABAE1A0488 for <>; Mon, 10 Mar 2014 07:24:45 -0700 (PDT)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-2c-531dcb2761e1
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 3A.CD.04853.72BCD135; Mon, 10 Mar 2014 15:24:40 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 15:24:39 +0100
Message-ID: <>
Date: Mon, 10 Mar 2014 15:24:39 +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: "Muthu Arul Mozhi Perumal (mperumal)" <>, Justin Uberti <>
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+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvja7Gadlgg8en+Cy2ThWyuPNpDqvF 2n/t7A7MHlN+b2T1WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBmn191nL+gSqWi89JClgXGm QBcjJ4eEgInE7aVPmCBsMYkL99azdTFycQgJnGCU6NmyiQnCWc4o8X36DjaQKl4BbYnp0/Yw djFycLAIqEpsPpkDEmYTsJC4+aMRrERUIFhi54HfjBDlghInZz5hAbFFBFIkNs3fARZnFlCX uLP4HDuILSxgLLH0735miF2XGCX6JxwFS3AK+Eo8+HWZDWSXhIC4RE9jEESvnsSUqy1Qc+Ql mrfOZgaxhYBOa2jqYJ3AKDQLyepZSFpmIWlZwMi8ilGyOLW4ODfdyEAvNz23RC+1KDO5uDg/ T684dRMjMLwPbvlttIPx5B77Q4zSHCxK4rzXWWuChATSE0tSs1NTC1KL4otKc1KLDzEycXBK NTBuLub+pSuh37I/+MXD1Zv91ZTuXw7eZDRths1HrbJtkdv5ytO4J2w71GeQtMtc+EXqhmwj UUW+9i0TrpaJHbnx8l1+bPqOCycd9kz7PV0tgFkrrti/UCdJs3Z+FTcHn46AYNKcKzzTS2N3 6LidW2jisOT6LfkjKlseZZhs5nm1fFXLi3PpOveUWIozEg21mIuKEwGfrlt8PQIAAA==
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: Mon, 10 Mar 2014 14:24:48 -0000

(as individual)

I think we need to start with what the goals are with the STUN packets.

In the initial connectivity establishment of ICE the purpose is to find
paths that works. To make that determination at all, I would argue to
maximize success one should use best effort markings as the network is
least likely to do something strange with such packets, including
dropping them for violating policy (even if they should just be

If one like to use STUN to determine the possibility to get DSCP != BE
packets through the network from a peer to peer perspective, then I
think one should consider specifying something like the STUN ECN check
options that are documented in Section 7.2.2 in RFC 6679.

To summarize, this sends an additional round of STUN packets after a
working path has been found to check ECN compliance in this path. It
includes and option indicating the ECT value entered, and the receiver
echoes the received value back. Thus enabling a sender to determine that
the path is ECT.

Something similar could be specified if desired to determine that at
least the network doesn't drop packets with DSCP != BE.

For consent freshness I don't think we need to do that on a per traffic
marking type level. Thus, the important is that it reaches the peer. And
the packet reaching the just needs to be statistically high enough
probability over a sequence of checks. Thus, I would say that the only
important factor here is to not mark it so that it has significant
higher drop probability. It also don't need to be minimal delay, thus EF
appears overkill and although AFx could be used, that should rather be
based on a traffic mix with a lot of AFx traffic.

In the end, it might be easier to not use other DSCP marking that BE for
the STUN, simple because it gives the most robust behavior and not
subject to network issues due to policing or DSCP remarking.

I think it will be important to take the considerations for using
multiple DSCP on the same 5-tuple that DART will document into account


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: