Re: [Dart] AF - DSCPs, PHBs and remarking

[<[e-mail]>]

Hi David,

you are of course correct with your assessment on standards. You've asked 
for information on what's implemented today and that's what I've provided.

Each AF DSCP identifies an individual PHB. If classification is DSCP 
based and limits apply on the number of PHBs, that's what providers have 
to respect. This limit still applies, if e.g. all AF4 packets are operated 
by the same scheduler (which I'd expect from a provider deployment).

It is also somewhat demanding to configure 14 PHBs to support just rtcweb 
on a  retail access and then provide additional PHBs for services of a 
provider. The provider may offer some services with admission control and 
if rtcweb isn't running through the same admission control, this requires 
additional PHBs. Some carriers may have deployed DiffServ already, when 
rtcweb starts to use it. 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Black, David [mailto:[e-mail]] 
Gesendet: Montag, 16. Juni 2014 23:58
An: Geib, Rüdiger
Cc: [e-mail]
Betreff: AF - DSCPs, PHBs and remarking

Hi Ruediger,

> 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

Well, what ought to happen (based on the original design of AF) is neither 1-1 PHB mapping nor classification by only the first three bits of the DSCP, as the latter approach would also run
CS4 (DSCP 100 000) through the same queue as AF4x.

The desired treatment is to classify by DSCP, but put inbound traffic with three DSCPs for AF4x into one queue preserving packet order.  The DiffServ term for this set of traffic that uses the three AF4x PHBs (with a DSCP for each) is "ordered aggregate" - see Section 5 of RFC 3260.

After initial classification has separated out the ordered aggregate, it can be run through an AF remarker in order to condition the outbound proportions of AF41/42/43 to match some desired distribution.  For examples of AF remarkers that can be used for this purpose, see RFC 2697 and RFC 2698.

Thanks,
--David


> -----Original Message-----
> From: Dart [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Monday, June 16, 2014 2:54 AM
> To: Black, David
> Cc: [e-mail]
> Subject: Re: [Dart] Commentary on draft-york-00
> 
> 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
> >
> 
> _______________________________________________
> Dart mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dart