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

[<[e-mail]>]

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