Re: [rtcweb] DSCP marking for STUN packets

Dave Taht <> Tue, 11 March 2014 17:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 357E91A074F for <>; Tue, 11 Mar 2014 10:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YlSqLYbeuqQ8 for <>; Tue, 11 Mar 2014 10:17:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22d]) by (Postfix) with ESMTP id 65F271A0768 for <>; Tue, 11 Mar 2014 10:17:58 -0700 (PDT)
Received: by with SMTP id w61so10357049wes.32 for <>; Tue, 11 Mar 2014 10:17:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=01uRt8zmKHPVHi6dNZ568An4HXli/j6noIjkKYfYnE0=; b=yLOFfBZjID2SjKXpWAdhBoXCOkDEyG8fsnkQC5xHOIAr37AJ4OiCPQJfi9Gk/wNSYx hEvWs0nOLN/LN8WQAOFcC2NAUEegjdRCJQe9AXXHhGH2DcyQpWVTKW6Z+ED61M+e1/5W PkGluQdXEz1oBmMlvtiTy4plLweIf7im9cDuRywk4QaKvJFZc7WqZZ+GAoU2ezgWFVHG pHXl0kSRUD6FGEPhaTY7aL2lPgsBohbR+C5zU9WaXwkL/EpduID78LxPO+IBEl0RorNC pJI657VbZW60OyD5LIcCfqbeQMy9GgrIT952E7hx9L7QIRpl3LHebOl8gp8Rn5NNiKM9 Lq6w==
MIME-Version: 1.0
X-Received: by with SMTP id gb9mr3980862wic.17.1394558272077; Tue, 11 Mar 2014 10:17:52 -0700 (PDT)
Received: by with HTTP; Tue, 11 Mar 2014 10:17:51 -0700 (PDT)
Received: by with HTTP; Tue, 11 Mar 2014 10:17:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Tue, 11 Mar 2014 17:17:51 +0000
Message-ID: <>
From: Dave Taht <>
To: Harald Tveit Alvestrand <>
Content-Type: multipart/alternative; boundary="001a11c26bb86d04a004f457e631"
Cc: Keith Winstein <>,
Subject: Re: [rtcweb] DSCP marking for STUN packets
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Mar 2014 17:18:01 -0000

On Mar 11, 2014 7:44 AM, "Harald Alvestrand" <> 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.
> _______________________________________________
> rtcweb mailing list