Re: [rtcweb] DSCP marking for STUN packets

Dave Taht <dave.taht@gmail.com> Mon, 10 March 2014 08:51 UTC

Return-Path: <dave.taht@gmail.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 E4A8B1A0407 for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 01:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEEDZ1_tp3L8 for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 01:51:42 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 091AE1A03FA for <rtcweb@ietf.org>; Mon, 10 Mar 2014 01:51:41 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id x48so7987519wes.7 for <rtcweb@ietf.org>; Mon, 10 Mar 2014 01:51:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z1D1e8XLF9UBZD2M+pfVw7FFeszy6tHL7CRgc0DkH/A=; b=XqBs3YNREj9sQyi0BJFVFdf7TByrMsvxYb0TQW3E+DF47+PtMpu6eVWiOw5jPdFIbD zbU62Jjhgi7jltsP0rhPWjzVlOSSspl1JP+Qp2K9KOoP8ZnvCzKUKUWLAxUihGfRnUaC A1qdZ00MvpG0BIv8G9MxbbcdcuaaUQHO66YnreKVpQR9GN2VD0gLy1pHhAPX95m43kPA NNk5I0N2sX0UtgGoHNIHJO1sY+b/+s06dEXTwOxaliwGAbBdji69B/dFdoHswTjpdfVD 1EYiYY8YMhfEotYJV1DOQmJXGEZekAuI2bRGBBvYJdQL1rl7m8IA/I8W82cKaMGnDtSC 9E6w==
MIME-Version: 1.0
X-Received: by 10.180.37.178 with SMTP id z18mr7937031wij.46.1394441496318; Mon, 10 Mar 2014 01:51:36 -0700 (PDT)
Received: by 10.216.8.1 with HTTP; Mon, 10 Mar 2014 01:51:36 -0700 (PDT)
Received: by 10.216.8.1 with HTTP; Mon, 10 Mar 2014 01:51:36 -0700 (PDT)
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE22E3108E4@xmb-rcd-x02.cisco.com>
References: <E721D8C6A2E1544DB2DEBC313AF54DE22E30E33C@xmb-rcd-x02.cisco.com> <CAOJ7v-2jnBAPEhkxjgRtNyntWPL6KBB-PQSLkUPUu91QHoPr3g@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE22E3108E4@xmb-rcd-x02.cisco.com>
Date: Mon, 10 Mar 2014 08:51:36 +0000
Message-ID: <CAA93jw4OwNa9mWFPo+-59mSyo7v2ktsu8n=+m8QoZar2DCjLNw@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Content-Type: multipart/alternative; boundary=e89a8f642e1e0c5a6004f43cb6f4
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5gY_PnEsK-eiXU_cEs_jm4KSRb0
Cc: 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: Mon, 10 Mar 2014 08:51:45 -0000

In all this talk about drop precedence and so on I'd like to point people
at some details of some currently deployed packet scheduling and aqm
systems.

http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html
On Mar 10, 2014 1:36 AM, "Muthu Arul Mozhi Perumal (mperumal)" <
mperumal@cisco.com> wrote:

>  |I think that the existing guidance should be sufficient in
> non-multiplexing
>
> |cases (i.e. BUNDLE).
>
>
>
> I don't think so. Even for non-multiplexing cases, a same stream could use
> different drop precedence for different packets, as described in
> draft-dhesikan-tsvwg-rtcweb-qos
>
>
>
>    The combination of priority input and multiple precedence levels
>
>    within a data class provides flexibility for an implementation in
>
>    deciding the importance of the stream and packets within a stream.
>
>    For example, if I frames are more important than the P frames then
>
>    the I frames can be marked with a DSCP with the lower drop
>
>    precedence.
>
>
>
> My take is that STUN connectivity/consent checks SHOULD use the lowest
> drop precedence within a given data type and priority.
>
>
>
> |For consent checks, I think the same DSCP markings as any other ICE
> connectivity
>
> |checks should be used.
>
>
>
> Agree.
>
>
>
> |If multiplexing is being performed, the connectivity checks probably
> should
>
> |use the highest DSCP value being used by the multiplexed media.
>
>
>
> For multiplexed media, I guess there is no WG consensus on how to mark the
> stream, yet (draft-ietf-mmusic-sdp-mux-attributes lists two possible
> options). But, I agree with your proposal in general, since these STUN
> packets are a kind of (media path) signaling packets and signaling packets
> are generally given higher priority..
>
>
>
> Muthu
>
>
>
> *From:* Justin Uberti [mailto:juberti@google.com]
> *Sent:* Monday, March 10, 2014 10:46 AM
> *To:* Muthu Arul Mozhi Perumal (mperumal)
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] DSCP marking for STUN packets
>
>
>
> 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.
>
>
>
> On Fri, Mar 7, 2014 at 4:35 AM, Muthu Arul Mozhi Perumal (mperumal) <
> mperumal@cisco.com> wrote:
>
> ICE says that an endpoint SHOULD apply the same DSCP marking as media
> packets to connectivity checks. This looks insufficient for RTCWEB, since
> it doesn't cover (at least) the following:
>
> - connectivity checks performed for a stream using different drop
> pecedences (draft-dhesikan-tsvwg-rtcweb-qos).
>
> - connectivity checks performed for non-media/data-channel traffic.
>
> - DSCP markings for consent checks.
>
>
>
> Comments on where we need to specify them? The last one can probably go
> into draft-ietf-rtcweb-stun-consent-freshness?
>
>
>
> Muthu
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>