Re: [rtcweb] DSCP marking for STUN packets

Harald Alvestrand <harald@alvestrand.no> Tue, 11 March 2014 14:44 UTC

Return-Path: <harald@alvestrand.no>
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 A8F3D1A073B for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 07:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 yk2YLKdYPQ1Y for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 07:44:01 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 56EBA1A0736 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 07:44:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 038A07C4F20 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 15:43:55 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SNEKZbXW+OF for <rtcweb@ietf.org>; Tue, 11 Mar 2014 15:43:54 +0100 (CET)
Received: from [192.168.1.17] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 32CCB7C4F14 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 15:43:54 +0100 (CET)
Message-ID: <531F212A.4040102@alvestrand.no>
Date: Tue, 11 Mar 2014 15:43:54 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <E721D8C6A2E1544DB2DEBC313AF54DE22E30E33C@xmb-rcd-x02.cisco.com> <CAOJ7v-2jnBAPEhkxjgRtNyntWPL6KBB-PQSLkUPUu91QHoPr3g@mail.gmail.com> <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca>
In-Reply-To: <531F176C.2070305@viagenie.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ff5vuEuX5TjsYe9IZ9jdCnOWqGM
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: Tue, 11 Mar 2014 14:44:04 -0000

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.