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

[<[e-mail]>]

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:[e-mail]] 
Gesendet: Freitag, 13. Juni 2014 15:24
An: Geib, Rüdiger
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]]
> Sent: Friday, June 13, 2014 4:05 AM
> To: Black, David
> Cc: [e-mail]
> 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:[e-mail]] Im Auftrag von Black, David
> Gesendet: Freitag, 13. Juni 2014 07:43
> An: Harald Alvestrand; [e-mail]
> 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
>