Subject: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / CS1

From: <[email-masked]>
Date: Fri, 29 May 2015 12:20:29 +0200

Gorry,

the notes taken in Dallas (and thanks to the note taker!) showed a scavenger-class-at-interconnection related discussion.

Summary of Dallas discussion:
-       Scavenger is not supported at Interconnection, as CS1 is not a widely deployed standard DSCP for scavenger.
-       Taking this into account, there was a request for CS1 not to be re-marked to any other DSCP.

Basic questions:
-       Is the issue to get Scavenger support in a general DiffServ sense at Interconnection, i.e. the PHB is supported by the receiving domain but the DSCP may be remarked? To me, this would make Scavenger relevant for diffserv-intercon
-       Is the issue to avoid remarking of the DSCP, no matter whether the receiving domain supports Scavenger? As I agree to remove the remarking discussion from diffserv-intrcon, I'd regard this to be out of its scope (in both cases, if the receiving domain supports Scavenger by CS1 and also if it transports CS1 unchanged if it isn't aware of the DiffServ PHB indicated by it).

Those interested in scavenger class marked packets passing interconnection points are asked to respond.

My take:
-       The uniform model assumes the DSCP and PHB to remain unchanged when passing a tunnel (may also be an MPLS tunnel). The uniform model is out of scope of diffserv-intercon.
-       The pipe model assumes the DSCP to remain unchanged when passing a tunnel. The pipe model is out of scope of diffserv-intercon.
-       The short pipe model tolerates or requires a DSCP rewrite at interconnection points. Diffserv-intercon proposes to indicate a desired PHB by a defined DSCP at an interconnection point. Any DSCP may be re-written by the receiving domain.

This is not to say, that uniform model or pipe model should not be supported. It just to indicate what's within and what's out of scope of diffserv-intercon. The draft doesn't define the uniform and pipe model to be out of scope yet, the next version will (unless there's disagreement on this aspect).

Regards,

Ruediger

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 29 May 2015 14:53:11 +0200 (CEST)

>From an operational point of view, for me, the only way to get scavenger 
class incrementally implemented is to create a new DSCP bit pattern for 
this with the first 3 bits set to 0. CS1 is not well suited for scavanger 
for incremental deployment in todays networks because it means different 
things in different places.

I posted about this in another discussion here on AQM:

http://www.ietf.org/mail-archive/web/aqm/current/msg01240.html

The proposal is to create a scavanger class which would map to CS0 but 
have DSCP-style drop probability bits set.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 May 2015 08:43:20 +1200

Firstly, note that RFC 3662 is very intentionally not standards-track and
does not recommend a DSCP value. To me, this discussion seems to mix up two
orthogonal concepts:

1. What the PHB for a scavenger class actually is (or in Mikael's
suggestion to AQM, what the PHB set is, since mention of priority
implies several members of a PHB set, like AFxy).

2. What DSCP values happen to be used for this PHB set. Despite
the confusion introduced by RFC 3662, those values don't have to
ones already used for other purposes, especially not CSx. Actually
the text makes it clear that the DSCPs recommended for AFxy should
be considered:

   If a CS PHB is used, note that this configuration will violate the
   "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have
   a less timely forwarding than CS0.  An operator's goal of providing
   an LE PDB is sufficient cause for violating the SHOULD.  If an AF PHB
   is used, it must be configured and a DSCP assigned such that it does
   not violate the "MUST" of paragraph three of section 2 of RFC 2597
   [RFC2597] which provides for a "minimum amount of forwarding
   resources".

     Brian

On 30/05/2015 00:53, Mikael Abrahamsson wrote:
>> -       Is the issue to get Scavenger support in a general DiffServ sense at Interconnection, i.e. the PHB is supported by the
>> receiving domain but the DSCP may be remarked? To me, this would make Scavenger relevant for diffserv-intercon
>> -       Is the issue to avoid remarking of the DSCP, no matter whether the receiving domain supports Scavenger? As I agree to
>> remove the remarking discussion from diffserv-intrcon, I'd regard this to be out of its scope (in both cases, if the receiving
>> domain supports Scavenger by CS1 and also if it transports CS1 unchanged if it isn't aware of the DiffServ PHB indicated by it).
> 
> class incrementally implemented is to create a new DSCP bit pattern for this with the first 3 bits set to 0. CS1 is not well
> suited for scavanger for incremental deployment in todays networks because it means different things in different places.
> 
> The proposal is to create a scavanger class which would map to CS0 but have DSCP-style drop probability bits set.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 29 May 2015 23:10:38 +0200 (CEST)

>   [RFC2597] which provides for a "minimum amount of forwarding

I was only talking about what the 6 DSCP bits should be for this to ever 
start to work widely across the Internet. My suggestion is 000xx0 and the 
recommendation is to only bleach the first three bits at ISP interconnects 
instead of all 6 bits (which is the most commonly done at this time). This 
is backwards compatible with CS0/BE and it's also backwards compatible 
with default queuing behaviour when doing automatic IP precedence -> 
802.1p and the recommended 4 queue ethernet prioritization (where CS1 and 
CS2 is lower than CS0 and CS3).