Re: [rtcweb] DSCP marking for STUN packets

"Muthu Arul Mozhi Perumal (mperumal)" <> Wed, 12 March 2014 09:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 41F781A0937 for <>; Wed, 12 Mar 2014 02:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q6oXKIWosTDw for <>; Wed, 12 Mar 2014 02:06:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BBC551A091D for <>; Wed, 12 Mar 2014 02:06:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5773; q=dns/txt; s=iport; t=1394615174; x=1395824774; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4kIYc9OWMqlhfOMPa4Bti7d8BwZ6OfwAKO1xlsdK1/I=; b=bFeycbvR+lhGlIuQY3S+HJtkpuYB0ckeyCu1hNWcp+NAAQvfYKRdekFB CBsLvXmB7TzORFz0R1okQDbMRnUiIk1DWdqRhJocJO2aOjMO0JG4AiOwm if5oQGSGyL+OSeFQJt6i/Dt6otFKIi/jORlhegMU/QMd7FaG9DutFK72p 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.97,636,1389744000"; d="scan'208";a="309728313"
Received: from ([]) by with ESMTP; 12 Mar 2014 09:06:13 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s2C96DSg018206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 09:06:13 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 04:06:13 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <>
To: Magnus Westerlund <>, Justin Uberti <>, Simon Perreault <>
Thread-Topic: [rtcweb] DSCP marking for STUN packets
Thread-Index: Ac85vcTs78cs2C8tSs2+vLGf/NxF+AEC/C2eAACAeTA=
Date: Wed, 12 Mar 2014 09:06:12 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 09:06:24 -0000

I think we are discussing two different problems:
1. Determining what DSCP actually works over the Internet, by using ICE.
2. For one or more DSCPs an endpoint uses for a traffic flow, what DSCP ICE needs to use.

In the case of #2, the endpoint uses those DSCPs because the network is provisioned that way by the network admin or the service provider. This could possibly be achieved through a combination of some browser configuration and JS input. For this case, using the highest DSCP value among those that are used for a given media or data-channel flow for ICE connectivity/consent checks makes sense to me.

On this other hand, #1 looks a bigger problem. In the absence of any information, starting with BE or not setting anything in the packet looks a good option to me.


|-----Original Message-----
|From: rtcweb [] On Behalf Of Magnus Westerlund
|Sent: Wednesday, March 12, 2014 1:33 PM
|To: Justin Uberti; Simon Perreault
|Subject: Re: [rtcweb] DSCP marking for STUN packets
|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:
|rtcweb mailing list