Re: [rtcweb] DSCP marking for STUN packets

Justin Uberti <juberti@google.com> Wed, 12 March 2014 03:55 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 32FFA1A0897 for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 20:55:48 -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 3CeNsPD-QYOj for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 20:55:46 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADA71A0398 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 20:55:46 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id lc6so8854403vcb.7 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 20:55:40 -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=GYOthn6hxnFuEAZ4ww9qMDtrCOW6Fdyt0B8DcFRmbYo=; b=Ja2j/WUJdJFclLiVoagIfp9gyqfd//xIxCE7ljKHc9IMk+3/qzNcivZg/eEm1SL/bS Wpa4sJmTpVHUwu0Op9PSHdMgjKwPG4Nxj5X8X6O/IfvIxP9atgtLHdJixFCip8iV/trM MA4fwFHKMGTWdmv9Ldlx3Az005aacopZN6EuZwpshx+wslseIo+2RMPxtPCtLaxvWr8Y 2eFFnqAhXtnFVbhIzYEQ4N0BtqxysIrK6d/xTBNA54I9vvL5h81d8avHsNQqEEqpXVCk dFS0lqKZ52r9jIQEUXVCF5VRmaSaz9vrtdkBnxASqINS7Dbna52C5a8HbhD6cRaE2UDx ERQg==
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=GYOthn6hxnFuEAZ4ww9qMDtrCOW6Fdyt0B8DcFRmbYo=; b=U6sYFrLTz4kXX303K9INIBQRFuVEuX2dEb4HQrg0/ik76GqmO0JwaihoBrRPZiYxNc jmp0Y8678s5DalpWe5F4FO1uLsxX85E8YqmykKZo7GPY2I2K5ZAQakoNlYVJKSoc0t0c JPLqmRwWDWobvm95GQzIUjS4b+elvGyml6z4mcFq+3CyKSP2gbiXC1qSBtxxnV29UWx0 W/EziL0e5CmEoiaCwlwuGSp+/0d887XpIsP45Kbmmi+bjdojxbEpYWAiFCRU3kvamkU8 nk4oKxOuWMx7tpwCSrJ/uQdbIUj03DQmCpycz+H0R0qah2N3+NYvRI/j8Seg28G5a/Iz 8qAQ==
X-Gm-Message-State: ALoCoQl9ZFsg+c3jsfC7NPvgWTAH1S4jrBKMczcc2vUr74zY8BAXt37f08zMaPfPVlse4CR+B9vlrM85RFiJvm0ky+WUMY1vMSh6w3eH4cLgBpij1r2bOEMh2CuSecah+1JYsmu06N3VyN2LdH3by6fhnpapgRxnAnh9h8ecrsKnneHmtTgb4Uf2L7dKRZyKv5DWOU7ZZU1k
X-Received: by 10.52.65.132 with SMTP id x4mr120995vds.36.1394596540434; Tue, 11 Mar 2014 20:55:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Tue, 11 Mar 2014 20:55:20 -0700 (PDT)
In-Reply-To: <CAA93jw6p=E6T_+CNRFs+OmiBTpZo1-UAENi=i95iboV-c+H1Lg@mail.gmail.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> <531F212A.4040102@alvestrand.no> <CAA93jw6p=E6T_+CNRFs+OmiBTpZo1-UAENi=i95iboV-c+H1Lg@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 11 Mar 2014 20:55:20 -0700
Message-ID: <CAOJ7v-1S_4HnCnLF53fQf1Mq5hcGu+T2QrtqPQUSR=1zSxFOdg@mail.gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Content-Type: multipart/alternative; boundary=20cf3071c8ac65e9e204f460cfab
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kfuVMfOmi2vclDlTCpntt5N7GiQ
Cc: Keith Winstein <keithw@mit.edu>, "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:55:48 -0000

On Tue, Mar 11, 2014 at 10:17 AM, Dave Taht <dave.taht@gmail.com> wrote:

>
> On Mar 11, 2014 7:44 AM, "Harald Alvestrand" <harald@alvestrand.no> wrote:
> >
> > On 03/11/2014 03:02 PM, 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).
> >
> >
> > This explanation makes sense for (ICE) connectivity checks.
> >
> > For other control information, especially information about delay, you
> want to have it delivered as fast as possible, and with as little loss as
> possible, because jitter in the return path will make the delay signal more
> noisy, and lost packets may cause drastic actions like those the
> circuit-breakers draft recommends.
> >
> > Whether that always translates to "the highest DSCP code point" is ....
> a good question.
>
> It doesn't.  Keith added af42 support to mosh last year and had several
> reports of packets being dropped with that marking. Worse the drops
> happened after 10 seconds of connectivity.
>
> Ecn markings on the other hand have thus far survived (if occasionally
> stomped on) across the open internet in that protocol.
>

This is a concern of mine as well, which is why we haven't yet flipped the
switch to turn DSCP on by default in Chrome. I think we'll need to do some
experimentation to see how often DSCP makes things worse.