Re: [rtcweb] DSCP marking for STUN packets

Justin Uberti <juberti@google.com> Thu, 13 March 2014 16:15 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 D0AA71A09AB for <rtcweb@ietfa.amsl.com>; Thu, 13 Mar 2014 09:15:45 -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 VPKIIER-nO_f for <rtcweb@ietfa.amsl.com>; Thu, 13 Mar 2014 09:15:42 -0700 (PDT)
Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0D33D1A09F7 for <rtcweb@ietf.org>; Thu, 13 Mar 2014 09:15:41 -0700 (PDT)
Received: by mail-ve0-f175.google.com with SMTP id oz11so1328053veb.20 for <rtcweb@ietf.org>; Thu, 13 Mar 2014 09:15:35 -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=qvp7+2URpIZyNhipinOBvAydDvECj30sBIGibJT51xs=; b=Zt7wkXRLllA3pBTzNZY3v/giJBdHj+/Y1gazlPXoDBhuv13VeZp6o9Nr1OErUS6gia wTsb0CUv0TqY6UyH1Oap3J4DUU7UGTzIx0fBlWEqBDOwyzqWp/mN2ltuLTbz/pU+V2WT 2yHBB/Z2cy+XMb3lPyBqH2mvJHlloefqPsTRTvNOHkFS2SMbxgHgZc1kHvMxAWVLHwgA 7aM/hchE/Ztb3I9Q4Tj4jDGlRZeIsrLMfqIHcOtdJXxehiM8agQqH9LnZtaxT5EDf+Nw 5+01ds3T8jFgwLoEvpxlaFEwtnuykazrI3fXhZVsZf4laCQBLMbWutQTohLcKDJI6xKr SXgQ==
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=qvp7+2URpIZyNhipinOBvAydDvECj30sBIGibJT51xs=; b=A7C/SkGHOgTjyY8McV9E9ejBQDVCxPgeDg+5ZlBFGDjIOfn645C9i24lamePue7wSz lTrcfTOMC7stUzMdVn2wBolfXxtyT5cE/sTtH7xsXdbxFFchA9NXR8jURdf8XEKjiB+5 CtZBIyrSQ1wXjPaq2ZnELxmkTwkuOn1yZWGEcLwi+a0MnvzaKj/UnWSUg4g3u+wGEAcf C7vYWsxwc59PffojBqtL2e+8DFL3xPqGsVAG5r7mBeHCOhj3HSKB3g+0R710xi4d5qzb gaIKZOSqBTW6oPhZLBN6ek/Ymyc7amBHdFF+D8X8dhzi0qDePHyAQbbwmhENsxX/cJwF Bgig==
X-Gm-Message-State: ALoCoQnc9DWalKGtITqSgpgx12+Cd4CBndazI2WMJEpOlSEXL41foyoERhHpThDOEoBe+E5RUfLvw6OYdbDtybncP6hv6UA7ZSp4ZLa8EMgPRh45+zhQ0bl/W88hPzZT1L37gwrizSkmb0zSly+7CtprzD8bMDYcUuS9zI/HuOCnbnL3bQeMgc+ajgs46OiBD/13UO6nps3m
X-Received: by 10.52.8.225 with SMTP id u1mr138689vda.64.1394727335319; Thu, 13 Mar 2014 09:15:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Thu, 13 Mar 2014 09:15:15 -0700 (PDT)
In-Reply-To: <5321A75B.8080100@ericsson.com>
References: <E721D8C6A2E1544DB2DEBC313AF54DE22E30E33C@xmb-rcd-x02.cisco.com> <CAOJ7v-2jnBAPEhkxjgRtNyntWPL6KBB-PQSLkUPUu91QHoPr3g@mail.gmail.com> <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> <CAOJ7v-1ZaDjOMFAXiW6yzCcQCrUE5sbY1kaNUT7L4kmwVs8NyQ@mail.gmail.com> <532014C8.2050908@ericsson.com> <CAOJ7v-3QiHi1eU=Js6ik6cP2CDLDfSvKtu4ugSM2uHQyD7c8Xg@mail.gmail.com> <5321A75B.8080100@ericsson.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 13 Mar 2014 09:15:15 -0700
Message-ID: <CAOJ7v-37nbgQqsHYjYkQF415ZmBJ40bq9eKORSSyHb7u4drMug@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=20cf302d497a617a9204f47f4393
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yAZ7jHQwPkj1mMWp7rEa_alr2wU
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: Thu, 13 Mar 2014 16:15:46 -0000

On Thu, Mar 13, 2014 at 5:40 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> On 2014-03-12 17:05, Justin Uberti wrote:
> >
> > On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund
> > <magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>>
> > wrote:
> >
>
> >
> >     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?
> >
> >
> > The idea is to have the same drop probability as the most critical media
> > that is flowing (e.g. voice), so that we don't end up in a situation
> > where media flows fine, but the media crowds out STUN consent check
> > packets, leading to call failure.
>
> Okay, that makes a certain sense. First of all this is not likely to
> have the "highest" DSCP value. In fact it might not have the lowest drop
> probability either. But, yes it might be prioritized over BE. This is
> assuming that this DSCP marking do work and doesn't prevent the 6-tuple
> to work. But lets take this as a separate issue.
>
> >
> >
> >     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.
> >
> >
> > If nodes stomp on certain AF-marked packets, and this is widespread,
> > this essentially dooms use of DSCP at all, unless we want to build some
> > sophisticated detection and fallback mechanism. IOW, it's not clear to
> > me that marking packets as BE confers any value over not marking at all.
>
> BE is no marking at all, i.e. DSCP = 0. But, I wanted to be clear that I
> really meant best effort.
>
> But, the question is what we do about nodes that not simple down mark
> DSCP code points !=0. I see some potential solutions.
>
> 1) We recommend that one track the loss rates the different DSCP
> markings individually and in cases when loss rates for some markings
> doesn't match the expected relative behavior between different markings,
> then one stops using DSCP markings and send everything as BE.
>
> 2) One expands the initial STUN exchange to a second round after
> nomination to verify the DSCP code points that one intended to use is
> not being blocked.
>
> The alternative to do something is to ignore the issue. It might be
> small enough that it isn't significant. I don't have data on this. If
> someone has any data source it would be appreciated if they share.
>
>
We could perform an experiment to determine how often this occurs in real
life. I was thinking about having clients send STUN requests with different
DSCP markings to a STUN server, and then analyzing the success rate. Open
to other ideas though.