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

From: "Black, David" <[email-masked]>
Date: Mon, 16 Jun 2014 17:58:09 -0400

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:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, June 16, 2014 2:54 AM
> To: Black, David
> Cc: [email-masked]
> 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:[email-masked]]
> Gesendet: Freitag, 13. Juni 2014 15:24
> An: Geib, Rüdiger
> Cc: [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, June 13, 2014 4:05 AM
> > To: Black, David
> > Cc: [email-masked]
> > 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:[email-masked]] Im Auftrag von Black, David
> > Gesendet: Freitag, 13. Juni 2014 07:43
> > An: Harald Alvestrand; [email-masked]
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dart

---

From: <[email-masked]>
Date: Tue, 17 Jun 2014 09:52:18 +0200

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:[email-masked]] 
Gesendet: Montag, 16. Juni 2014 23:58
An: Geib, Rüdiger
Cc: [email-masked]
Betreff: AF - DSCPs, PHBs and remarking

Hi Ruediger,

> 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

> If a network provider just supports aggregated classes and that 
> provider must use DSCP based classification then
> 
> 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
> 
> handling) is a core element of the DiffServ architecture, and is 
> required by RFC 2474 (Section 3).
> 
> 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
> 
> 
> > 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
> >

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 17 Jun 2014 12:33:48 +0200

Hi Ruediger,

> by the same scheduler (which I'd expect from a provider deployment).

Each AF class (2 or 3 PHBs) usually only needs a single queue.
It is not allowed to map an AF class to only a single PHB:
   Within each AF class, a DS node MUST accept all three drop precedence
   codepoints and they MUST yield at least two different levels of loss
   probability.
So at least one needs to distinguish between AFx1 and AFx2/AFx3.

> provider. The provider may offer some services with admission control and 

If you want to realize all proposed mappings of
http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-00
you probably need 7 separate queues (LE, BE, AF1-AF4, EF)
and at most 15 DSCP to PHB mappings.

> additional PHBs. Some carriers may have deployed DiffServ already, when 

I think that you'll need admission control for EF and AFx1 PHBs
otherwise you'll end up with best-effort behavior in overload
situations...

Regards,
 Roland

---

From: <[email-masked]>
Date: Tue, 17 Jun 2014 14:14:09 +0200

Hi Roland,

yes, of course all AFx packets use the same queue (and AFy another). 
That's independent of the number of drop levels. My point is, if a 
separate DSCP is desired on egress, a separate classification for 
a PHB is required on ingress. If your choice is 3 DSCPs for AFx class, 
then the queue may be configured to produce one, two or three 
differing drop levels. This may be relevant for standards compliance, 
but not for the number of PHBs to be configured. 

In this thread, we seem to either explain the same thing to each other 
or talk past each other. 

Thanks for correcting my count of PHBs, I forgot EF. And yes, 7 queues 
for RTCweb. That's another restricted resource.

Admission control must work the same way for all flows of a PHB where 
it is deployed. Otherwise it is pointless. Will RTCWeb align well 
with e.g. an IMS VoIP solution running through admission control 
if both intend to use EF?

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Dart [mailto:[email-masked]] Im Auftrag von Bless, Roland (TM)
Gesendet: Dienstag, 17. Juni 2014 12:34
An: Geib, Rüdiger; [email-masked]
Cc: [email-masked]
Betreff: Re: [Dart] AF - DSCPs, PHBs and remarking

Hi Ruediger,

Am 17.06.2014 09:52, schrieb [email-masked]:
> 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.
> 
> 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 you want to realize all proposed mappings of http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-00
you probably need 7 separate queues (LE, BE, AF1-AF4, EF) and at most 15 DSCP to PHB mappings.

> 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.

I think that you'll need admission control for EF and AFx1 PHBs otherwise you'll end up with best-effort behavior in overload situations...

Regards,
 Roland