Re: [rtcweb] DSCP marking for STUN packets

Simon Perreault <simon.perreault@viagenie.ca> Tue, 11 March 2014 14:02 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C3E1A045C for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 07:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhHomlgZvQ3P for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 07:02:27 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDEC1A0423 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 07:02:27 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d5d1:ac74:fa48:a37a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 46C0C403F8 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 10:02:21 -0400 (EDT)
Message-ID: <531F176C.2070305@viagenie.ca>
Date: Tue, 11 Mar 2014 10:02:20 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <E721D8C6A2E1544DB2DEBC313AF54DE22E30E33C@xmb-rcd-x02.cisco.com> <CAOJ7v-2jnBAPEhkxjgRtNyntWPL6KBB-PQSLkUPUu91QHoPr3g@mail.gmail.com> <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com>
In-Reply-To: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1isr4_CBHdblWG_5Jj96trxIvNM
Subject: Re: [rtcweb] DSCP marking for STUN packets
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Mar 2014 14:02:29 -0000

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).

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca