Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 11 August 2014 20:13 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8CB1A0004; Mon, 11 Aug 2014 13:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no
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 mToK_Zrb7Trc; Mon, 11 Aug 2014 13:13:05 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54A91A0002; Mon, 11 Aug 2014 13:13:04 -0700 (PDT)
Received: by mail-pa0-f50.google.com with SMTP id et14so11510119pad.23 for <multiple recipients>; Mon, 11 Aug 2014 13:13:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m1e5pZ4q/VR2MWt66JLLjGGm8LAxjhTXV3DCiYfFKuU=; b=Ur2N9LXBgn3f/kvVM+wfE02+PW328N+0sDBVBubTFcgf7kFMXlD1u43EN43wl9R1Yl AktYDmcy5NNvpoTLVL/+P4b4vPnvq/BXIj5/e6Hhqp2iQN5GzmIo5IjajPzjybprIEw9 7kYsyXZI5aHa4E17z2cIFgcUWVDzGPtfWEuk3BFBjWGw/nmZ2n6xSlewJ6E7jKTwnvMc Lrjxe/RlJYopQ1rMUkjbiWD5Vtr6K+cavMnjTEq8COBzP8Vo23ILrJ2Ai6o2YnL/J9++ U99XPgenmp8W0X4PFkZRhcRD1OAyyiHBY5+pqCGu8v0dm0EcHsmJOYcI73SuC02d0pSe ps8Q==
X-Received: by 10.66.122.175 with SMTP id lt15mr27061pab.77.1407787984588; Mon, 11 Aug 2014 13:13:04 -0700 (PDT)
Received: from [192.168.178.23] (110.199.69.111.dynamic.snap.net.nz. [111.69.199.110]) by mx.google.com with ESMTPSA id rv10sm8642126pbc.5.2014.08.11.13.13.02 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 13:13:03 -0700 (PDT)
Message-ID: <53E923CE.1000803@gmail.com>
Date: Tue, 12 Aug 2014 08:13:02 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ruediger.Geib@telekom.de
References: <B92C2A41-5596-4874-B3B7-D765A3E76D5E@nostrum.com> <CA7A7C64CC4ADB458B74477EA99DF6F502DE409525@HE111643.EMEA1.CDS.T-INTERNAL.COM>
In-Reply-To: <CA7A7C64CC4ADB458B74477EA99DF6F502DE409525@HE111643.EMEA1.CDS.T-INTERNAL.COM>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/x0FKvtctrtmXtSWteEIRzIbcqF4
Cc: david.black@emc.com, dart@ietf.org, tsvwg@ietf.org
Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2014 20:13:06 -0000

Hi Ruediger,

On 11/08/2014 22:21, Ruediger.Geib@telekom.de wrote:
> Hi David,
> 
> new EF related text has been added in the -01 version. I've copied 
> in some text of RFC3246 related to EF remarking and policing below. 
> My take:
> 
> . remarking of entire flows is an option, but no remarking of 
>   packets exceeding EF capacity limits.
> - looking at the EF jitter and delay properties, I doubt that 
>   shaping is desirable. RFC3246 doesn't mention shaping as part 
>   of EF conditioning. I personally wouldn't expect EF shaping 
>   in sections where policing is applied. 
> - dropping of packets exceeding EF capacity is a MUST, if I 
>   interpret RFC3246 correctly.

Well, it seems to me to be a SHOULD, with the MUST that you cite
below being conditional on "a mechanism that allows unlimited
preemption of other traffic." So I would not be at all surprised
by deployments that support shaping and remarking. Also, there
are certainly implementations that are closer to RFC 2598 or
RFC 3248 and therefore less strict.

I think the draft should make it clear that there is likely to be
variation in actual behaviour for EF traffic that exceeds the nominal
rate. (Leaving aside the fact that without a string of matching SLAs
along the path, the nominal rate might not even be well defined.)

   Brian

> 
> I suggest to adapt the section of draft-dart-dscp to be more 
> precise regarding the optional remarking of EF traffic and to 
> remove shaping as a conditioning option if traffic is beyond 
> the EF forwarding capacity limit. A Proposal for the final 
> sentence:
> 
> ...exceeds that capacity must be dropped. EF compliant flows may 
> be remarked to a different DSCP.
> 
> All other new text indicated by the Diff version looks allright.
> 
> Regards,
> 
> Ruediger
> 
> 
> 
> draft-dart-dscp:
> 
> 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic	
>    traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865]	
>    is an admission controlled variant of the EF PHB. Both of these	
>    PHBs are based on pre-configured limited forwarding capacity;	
>    traffic that exceeds that capacity may be shaped, remarked to a	
>    different DSCP, or dropped.
> 
> ########################################
> 
> RFC3246 (three excerpts):
> 
>    Packets belonging to a single microflow within the EF aggregate
>    passing through a device SHOULD NOT experience re-ordering in normal
>    operation of the device.
> 
>    Packets marked for EF PHB MAY be remarked at a DS domain boundary
>    only to other codepoints that satisfy the EF PHB.  Packets marked for
>    EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS
>    domain.
> 
>    If the EF PHB is implemented by a mechanism that allows unlimited
>    preemption of other traffic (e.g., a priority queue), the
>    implementation MUST include some means to limit the damage EF traffic
>    could inflict on other traffic (e.g., a token bucket rate limiter).
>    Traffic that exceeds this limit MUST be discarded.
> 
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Ben Campbell
> Gesendet: Samstag, 9. August 2014 19:50
> An: dart@ietf.org
> Cc: Richard Barnes; draft-ietf-dart-dscp-rtp.all@tools.ietf.org; mls.ietf@gmail.com
> Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02
> 
> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. It's available on the data tracker at the following URL:
> 
> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/
> 
> The WGLC will conclude on 22 August, 2014. Please send your comments to the authors and the DART mailing list. If you've reviewed it and think it's good to go, please say so.
> 
> Thanks!
> 
> Ben.
> 
> _______________________________________________
> Dart mailing list
> Dart@ietf.org
> https://www.ietf.org/mailman/listinfo/dart
> 
> _______________________________________________
> Dart mailing list
> Dart@ietf.org
> https://www.ietf.org/mailman/listinfo/dart
> .
>