Return-Path: 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 ; 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 ; 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 ; Mon, 10 Mar 2014 01:51:41 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so7987519wes.7 for ; 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: References: Date: Mon, 10 Mar 2014 08:51:36 +0000 Message-ID: From: Dave Taht To: "Muthu Arul Mozhi Perumal (mperumal)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 08:51:45 -0000 --e89a8f642e1e0c5a6004f43cb6f4 Content-Type: text/plain; charset=ISO-8859-1 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 > > --e89a8f642e1e0c5a6004f43cb6f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

In all this talk about drop precedence and so on I'd lik= e to point people at some details of some currently deployed packet schedul= ing and aqm systems.

http://snapon.lab.bufferbloat.net/~d/dr= aft-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 i= n non-multiplexing

|cases (i.e. BUNDLE).

=A0

I don't think so. Even for non-multiplexing cases, a s= ame stream could use different drop precedence for different packets, as de= scribed in draft-dhesikan-tsvwg-rtcweb-qos

=A0

=A0=A0 The combination of priority input and multiple prec= edence levels

=A0=A0 within a data class provides flexibility for an imp= lementation in

=A0=A0 deciding the importance of the stream and packets w= ithin a stream.

=A0=A0 For example, if I frames are more important than th= e P frames then

=A0=A0 the I frames can be marked with a DSCP with the low= er drop

=A0=A0 precedence.

=A0

My take is that STUN connectivity/consent checks SHOULD us= e the lowest drop precedence within a given data type and priority.<= u>

=A0

|For consent checks, I think the same DSCP markings as any= other ICE connectivity

|checks should be used.

=A0

Agree.

=A0

|If multiplexing is being performed, the connectivity chec= ks probably should

|use the highest DSCP value being used by the multiplexed = media.

=A0

For multiplexed media, I guess there is no WG consensus on= how to mark the stream, yet (draft-ietf-mmusic-sdp-mux-attributes lists tw= o 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..<= u>

=A0

Muthu

=A0

From: Justin U= berti [mailto:juber= ti@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

=A0

I think that the existing guidance should be suffici= ent in non-multiplexing cases (i.e. BUNDLE). For consent checks, I think th= e same DSCP markings as any other ICE connectivity checks should be used; f= or ICE-for-SCTP checks, the same DSCP markings as media packets (i.e. the SCTP traffic) should be used.

=A0

If multiplexing is being performed, the connectivity= checks probably should use the highest DSCP value being used by the multip= lexed media.

=A0

On Fri, Mar 7, 2014 at 4:35 AM, Muthu Arul Mozhi Per= umal (mperumal) <mperumal@cisco.com> wrote:

ICE says that an endpoint SHOULD apply the same DSCP marki= ng 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 differe= nt drop pecedences (draft-dhesikan-tsvwg-rtcweb-qos).<= /p>

- connectivity checks performed for non-media/data-channel= traffic.

- DSCP markings for consent checks.

=A0

Comments on where we need to specify them? The last one ca= n probably go into draft-ietf-rtcweb-stun-consent-freshness?<= u>

=A0<= /u>

Muthu


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

=A0


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--e89a8f642e1e0c5a6004f43cb6f4--