Re: [rtcweb] DSCP marking for STUN packets

Justin Uberti <juberti@google.com> Wed, 12 March 2014 16:05 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 4343D1A09CD for <rtcweb@ietfa.amsl.com>; Wed, 12 Mar 2014 09:05:40 -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 p5jfgup07urE for <rtcweb@ietfa.amsl.com>; Wed, 12 Mar 2014 09:05:35 -0700 (PDT)
Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D72301A09D2 for <rtcweb@ietf.org>; Wed, 12 Mar 2014 09:05:34 -0700 (PDT)
Received: by mail-ve0-f173.google.com with SMTP id oy12so10483318veb.32 for <rtcweb@ietf.org>; Wed, 12 Mar 2014 09:05:28 -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=PXWSAq++PW/UZeUc4AEbEQVCOHum+vqz//54c7oWEow=; b=BHq9utIJfHnCKfPjH7FC7pimuXim5+jM4it2YDUQ65NIDWGPfSpcrQWjaoaKcFZXgC CB9scibE7Mdh99zGIh2zslz09ZnW1FDE/jHDamutF945SeF6/O8yMqryjs6L5PAuOHJQ B5y9gSj3zY7X4tc8HkJcqzth6PF41VDIOoWCtGk8cV4yqZ96QzuTjThnsnZ7e/xHqOvz fR5eFNAN533i1odDzHU6sF4XlG5yc82iXjrnB6wf/kfhZ+iuOFs9ovCCXIuV0PwkM3W0 dQU3hnykCXOIIPUkAvnxmeN0/lp4gHkcPCo4Zc4fT2lkyJ7rEbF5pNd7jGX97bRiLxGM Q4eA==
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=PXWSAq++PW/UZeUc4AEbEQVCOHum+vqz//54c7oWEow=; b=Qvp4bdIe6avhnPY8ZapL5cfKwo8eNCf+rbNJ1QoL4GGjtG8IOq9HY5uMloKRfNZeSF SKMlk+nM2BxUlm5Fj+GZgtdDHFUAPoKC3PwlAtol1O+cpG87dULBlue0hAWk4m5cG+3r wZSRqJfHTN8dgk7q7PA0rLOEcfneJpFnwaJGQ8E2aj68V1evtDfF+7tVQg48CY23cHjQ 5RfosrTcC7DB0pwydhVVI3hvjI0CY3lWV9piYlu6F5pqRQ3Tcb1m+FYoHxkp9Q9PQcM2 G153CP2zYMpPZjiWeUZwR0BTVMd45J94c8Z5SEqujQ2y1WLcCBnqoMV/yw4RojaapXuU yOqw==
X-Gm-Message-State: ALoCoQnMuIu3KwyFAuZQTM62cUmVSkVKv2tRbfyhFhDPJfTdLXV8GlH3JTbSP/pYETiqgPX94vnPObQ6uWs0rFMoRQ4rbgkFDyDN0tBdasU8I9IeEh4PgUdpLSChlZHl9iSQ2aesfsS2S01Lr5Dc8nYV9/MDxxmjPAannCngy1DaPC2VnGuazGkwCAcQ9x9fWdmAZzVPNoyQ
X-Received: by 10.52.101.135 with SMTP id fg7mr31423276vdb.17.1394640328439; Wed, 12 Mar 2014 09:05:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Wed, 12 Mar 2014 09:05:08 -0700 (PDT)
In-Reply-To: <532014C8.2050908@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>
From: Justin Uberti <juberti@google.com>
Date: Wed, 12 Mar 2014 09:05:08 -0700
Message-ID: <CAOJ7v-3QiHi1eU=Js6ik6cP2CDLDfSvKtu4ugSM2uHQyD7c8Xg@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=bcaec54695055dd01104f46b0155
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/biw6I8BKqGVkHXwtftnkTAhsyyg
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 16:05:40 -0000

On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> On 2014-03-12 04:53, Justin Uberti wrote:
> >
> >
> >
> > On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault
> > <simon.perreault@viagenie.ca <mailto: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.
> >
>
> (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?
>

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.

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

>
> 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.
>
> Cheers
>
> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>