Re: [rtcweb] DSCP marking for STUN packets

Justin Uberti <juberti@google.com> Wed, 12 March 2014 03:53 UTC

Return-Path: <juberti@google.com>
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 956361A03A7 for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 20:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level:
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 PkNFZtxo_Wpa for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 20:53:37 -0700 (PDT)
Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 684DB1A03A5 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 20:53:37 -0700 (PDT)
Received: by mail-ve0-f181.google.com with SMTP id oy12so9397781veb.26 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 20:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bc6YXgohZCT3FBgJfhqHciPMs3IVXj30qdO0wIlE2zg=; b=inh7h9zKnTMgF6n6eL0SqId9UiMvbWEd56KnzlXV0Kuxg7/Pu2nWX12HMRCYwkrTlO GeognUgEnNsfwXXvfdbg+NiF1giIDk3il3BjfzRoERM8stUdRcis2BsenYiHJFcMA24l 0LGJOofInm/RVH/JNxz+ytjM+/lVUESTqsz1IX+N3ocCREH1EOZ9q8gkhaXjhwJCJ3qo Vhs+SjjsaY1J2taXvwfHXo7wKQSeC/PHyr6XBcOBB063ep+MRSG69QiLW4A8eCIGwPbl OZt+JQNCyV5zy9RDA5szGA6BVXUzM8fMYgUVDf9TZ1D/1RJMcI4pbJ8uoas6+UILokY6 4t7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Bc6YXgohZCT3FBgJfhqHciPMs3IVXj30qdO0wIlE2zg=; b=Y5w7JCHn8DMXk5h00E/8DVpuUacjyuxAsJAvJJETmYNDgSeVPOxIDhBD8j3i7RdBEA riCctk6kjC9FbbSUCbgz9HCC0c1j2I3jUe7xnv+24gY0Icihkfq3lKxIILMM7VhlDkyu yD9+VpDJDPz4YYWBM6/ztbu50QBkVVEwJluGsIPjfgUkskXU2NK+fCRTCJFBwDJo9B72 Ns7kZdrdgwD4qxPJHuINPDf7PejqG1xToVHXIiG2r2xSz6L4GcgfV3U+yXq1e63Gn/XF k9WfI2vRd/eT0wmiJzhTHJCxdxb4/xNufe6u7BbhSsq/OlajuUkXdh6+W/qLvJ8eVY2B uCWA==
X-Gm-Message-State: ALoCoQkGj6n66BdYhdCt9hKYi8XOeHUnH4MFxY5AfaphMs+HD7NBkJ6cFWZVdC0JUTsZD1IMo5swgYiNj0o10ez8DCIk+O1WHkBaZn9L+ca0ehtrt0o16lWZiInTUT0hhUrNy04p3m4A8qhVHDWLK+2QaxscLTAXP+TBsqscRD5hk8x4KNzj+QMt5xhb847ZuuwBPXojpEre
X-Received: by 10.52.72.12 with SMTP id z12mr36470vdu.40.1394596411084; Tue, 11 Mar 2014 20:53:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Tue, 11 Mar 2014 20:53:11 -0700 (PDT)
In-Reply-To: <531F176C.2070305@viagenie.ca>
References: <E721D8C6A2E1544DB2DEBC313AF54DE22E30E33C@xmb-rcd-x02.cisco.com> <CAOJ7v-2jnBAPEhkxjgRtNyntWPL6KBB-PQSLkUPUu91QHoPr3g@mail.gmail.com> <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca>
From: Justin Uberti <juberti@google.com>
Date: Tue, 11 Mar 2014 20:53:11 -0700
Message-ID: <CAOJ7v-1ZaDjOMFAXiW6yzCcQCrUE5sbY1kaNUT7L4kmwVs8NyQ@mail.gmail.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Content-Type: multipart/alternative; boundary=20cf307f313cb029e004f460c7fd
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_4LlHfKzeQyY8Mq-ge_p57Nhsmk
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Wed, 12 Mar 2014 03:53:39 -0000

On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault <
simon.perreault@viagenie.ca> 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.