Re: [Dart] Commentary on draft-york-00

<Ruediger.Geib@telekom.de> Mon, 16 June 2014 06:54 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 593441B2C0A for <dart@ietfa.amsl.com>; Sun, 15 Jun 2014 23:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 qKuhTziNTfsg for <dart@ietfa.amsl.com>; Sun, 15 Jun 2014 23:54:19 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665731B2C08 for <dart@ietf.org>; Sun, 15 Jun 2014 23:54:17 -0700 (PDT)
Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 16 Jun 2014 08:54:05 +0200
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 16 Jun 2014 08:54:04 +0200
From: <Ruediger.Geib@telekom.de>
To: <david.black@emc.com>
Date: Mon, 16 Jun 2014 08:54:04 +0200
Thread-Topic: [Dart] Commentary on draft-york-00
Thread-Index: Ac+GPMQkqW7R46+9S0SkejvvC1nsFgAi8thQAAIqc3AADiec8ACIiabA
Message-ID: <CA7A7C64CC4ADB458B74477EA99DF6F502D063BB67@HE111643.EMEA1.CDS.T-INTERNAL.COM>
References: <5399A1C8.7080407@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712076FF26767@MX15A.corp.emc.com> <CA7A7C64CC4ADB458B74477EA99DF6F502D063B6E3@HE111643.EMEA1.CDS.T-INTERNAL.COM> <8D3D17ACE214DC429325B2B98F3AE712076FF267B4@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FF267B4@MX15A.corp.emc.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/hqzgSHxlUNclWa4POfDt_Y74aAk
Cc: dart@ietf.org
Subject: Re: [Dart] Commentary on draft-york-00
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, 16 Jun 2014 06:54:21 -0000

Hi David,

to make sure we mean the same thing on AF, re-marking and PHB consumption:

If a network provider just supports aggregated classes and that provider must use DSCP based classification then

Incoming AF4n -> outgoing AF4 with a cost of 1 local PHB is (for example):

Incoming DSCP 100 010 -> outgoing DSCP 100 010    PHB AF41
Incoming DSCP 100 100 -> outgoing DSCP 100 010    PHB AF41
Incoming DSCP 100 110 -> outgoing DSCP 100 010    PHB AF41

The other option, with a cost of 3 local PHBs is

Incoming DSCP 100 010 -> outgoing DSCP 100 010    PHB AF41
Incoming DSCP 100 100 -> outgoing DSCP 100 100    PHB AF42
Incoming DSCP 100 110 -> outgoing DSCP 100 110    PHB AF43

If there was an additional possibility to classify based on 
DSCP bits 0-2, the second option can be configured with a cost 
of 1 local PHB (results in an aggregate / single local PHB for 
the provider and 3 DSCPs for an application or a device closer 
to the network edge). 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Black, David [mailto:david.black@emc.com] 
Gesendet: Freitag, 13. Juni 2014 15:24
An: Geib, Rüdiger
Cc: dart@ietf.org
Betreff: RE: [Dart] Commentary on draft-york-00

Hi Ruediger

Many thanks for the additional information.  I have a few comments:

> - there used to be a possibility to ignore the lower DSCP
>   bits 3-6, but there's no standard to that. Some vendors
>   removed this option and with IPv6, each PHB must be
>   classified and completely configured individually by DSCP.

That's a good thing, since that behavior (per DSCP traffic
handling) is a core element of the DiffServ architecture, and is required by RFC 2474 (Section 3).

>   Please be aware, if it comes to a re-write, a single DSCP
>   is set for all incoming DSCPs matching this PHB. Keep in
>   mind the possible restrictions on the number of PHBs.

Full AF support should classify all 3 PHBs that make up an AF class into a single aggregate on the node, with remarking applied to that aggregate, not DSCP by DSCP.

> If end-to-end DiffServ PHBs are what you look for, standardize what is 
> really required and be clear on how to use it.

As noted earlier, that's not the goal of the dart WG, as I understand it.  I believe the goal of this short term WG is to describe what exists and provide guidance on how to use it, particularly for RTCWEB.

Thanks,
--David


> -----Original Message-----
> From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
> Sent: Friday, June 13, 2014 4:05 AM
> To: Black, David
> Cc: dart@ietf.org
> Subject: AW: [Dart] Commentary on draft-york-00
> 
> Hi David,
> 
> to answer the question related to implementations and configurations 
> at least from the viewpoint of one network provider
> 
> - you can support a multi-vendor strategy. This makes sense
>   from an economical point of view, but limits
>   deployments to the minimum common denominator.
> 
> - to configure a PHB, there are classifiers, policers,
>   schedulers, AQM and re-markers.
>   Implementations differ to some aspects (e.g. on
>   supported number of classes and ingress/egress remarking).
>   Limits like less than 20 PHBs may apply today.
>   I'd be interested, whether there are offers of any
>   complete AF class as part of a single product.
> 
> - there used to be a possibility to ignore the lower DSCP
>   bits 3-6, but there's no standard to that. Some vendors
>   removed this option and with IPv6, each PHB must be
>   classified and completely configured individually by DSCP.
>   Please be aware, if it comes to a re-write, a single DSCP
>   is set for all incoming DSCPs matching this PHB. Keep in
>   mind the possible restrictions on the number of PHBs.
> 
> - many IP/MPLS backbone networks and also many Ethernet
>   based access networks support 3-4 PHBs for retail services.
>   I'm not aware of any two providers using exactly the
>   same DSCPs. I'm also not aware of any two standards using fully
>   matching DSCPs for their PHBs (IETF, GSMA, MEF).
> 
> - There's something I'd call enterprise philosophy, that is
>   making use of a large set of internal PHBs. I never saw
>   any of these philosophies remotely resembling the other.
>   PHBs or classes are used to identify products,
>   access types, stream types and so on. These usually just
>   consume PHBs with sometimes at best loose relation to
>   standards.
> 
> If end-to-end DiffServ PHBs are what you look for, standardise what is 
> really required and be clear on how to use it. If a network provider 
> is expected to support these PHBs, there must be a convincing reason 
> to do so. Take EF as an example for a well specified DiffServ standard.
> 
> Regards,
> 
> Ruediger
> 
> -----Ursprüngliche Nachricht-----
> Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Black, David
> Gesendet: Freitag, 13. Juni 2014 07:43
> An: Harald Alvestrand; dart@ietf.org
> Betreff: Re: [Dart] Commentary on draft-york-00
> 
>    Harald,
> 
>    Many thanks for the review and commentary, especially for the discussion
>    of real time traffic sensitivity to reordering.  This note is an attempt
>    to pick up non-editorial items that haven't been dealt with in other
>    messages on the list. I see four of them:
> 
> RG: [snip]
> 
>    [4]
>    > 2.4 DSCP remarking
>    >
>    > The discussion of token-bucket-based remarkers leaves me a bit confused.
>    > To me, it's obvious (?) that token-bucket-based remarkers would
>    > operate in color-blind mode on a network boundary, and in
>    > color-sensitive mode only when they had assurance that incoming
>    > markings were already indicating color. Thus, flows from an end-user
>    > system should only hit color-blind remarkers; the real question is:
>    > will a color-blind remarker use the incoming DSCP codepoint to decide
>    > which of a group of remarking treatments it chooses for the packets?
> 
>    I'm not sure about the "obvious" point - anyone care to comment on what's
>    actually deployed/configured in practice?
> 
>    The answer to the final question about choice of remarking treatment is
>    "yes" although the PHBs in an AF class should receive the same treatment.
>    The fact that the question was asked suggests that the discussion of
>    traffic classifiers needs some additional clarity and explanation.
> 
>    Thanks,
>    --David
>