Subject: [Diffserv] RE: Question about qosActionEntry

From: "Hesham Elbakoury" <[email-masked]>
Date: Thu, 27 Jul 2000 04:16:32 -0700

I definitely agree with Andrew that we should not overload the definition
of DSCP.

  Hesham

-----Original Message-----
From: Andrew Smith [mailto:[email-masked]]
Sent: Thursday, July 27, 2000 12:51 AM
To: Michael Fine
Cc: rap; diffserv
Subject: Re: Question about qosActionEntry

Michael,

I may be reading too much into your answer but I think that those are both
bad
assumptions to make in general (they might be OK in specific deployments or
for
specific devices - perhaps that's what you meant?). 

For (1), you need to be able to represent rules that filter and/or mark on
802.1p and/or DSCP, all 4 combinations of the above, independently.

For (2), I think it is a really bad idea to use DSCP as a canonical
representation of a PHB - go back and read all of the ancient Diffserv
discussion which lead to the whole idea of separating the two for some clues
as
to why this is a bad thing to do. A DSCP is merely a 6-bit label for use *on
the
wire* - it has no meaning internal to a device once it has been translated
to
the PHB that it represents. What happens if you have a device that supports
65
different PHBs? What if a DSCP means one thing on one interface and a
different
thing on another? You need an internal representation but you must not
overload
DSCP with that function. 

BTW, on a related topic, you discounted my earlier comment that the PIB
ought to
be able to reflect the capability to influence a drop algorithm using more
than
just DSCP (the use of VLAN, 802.1p, uni-/multicast or IPsrc/dest information
come to mind) - that is why the Diffserv model and MIB allow for placing an
arbitrary classifier at that point: I think that the PIB should do the same
-
this is a gratuitous difference from the Model for the sake of saving a few
objects in the PIB definition. If not then at least an extensibility
mechanism
should be provided to achieve this.

Andrew

[CCing the Diffserv list]

Michael Fine wrote:
> 
> There are two ways to look at this.
> 
> 1.  The filter is filtering on layer 2 (or any other) information but
> the packets are still IP packets.  In this case, it still makes sense
> to re-write the DSCP in the packet header.
> 
> 2.  The DSCP is a canonical representation of the PHB.  It is used
> internal to the device to decide how to treat the packet.  For
> example, it determines which queue to enqueue the packet onto even for
> non-IP packets (do such things exist? :-).  In this case it would not
> imply any modification of the packet header itself.
> 
> That said, one can imagine a enterprise-specific PIB that, say, maps
> DSCP to 802.1p CoS and a device that writes the 802.1p field of a
> packet based on the mapped DSCP from the qosActionEntry.
> 
> Michael
> 
> Rajiv Dighe writes:
>  > From: Rajiv Dighe <[email-masked]>
>  > To: rap <[email-masked]>
>  > Subject: Question about qosActionEntry
>  > Date: Tue, 25 Jul 2000 14:31:28 -0400
>  >
>  > Hi All,
>  >
>  >     Pardon me if this seems like a stupid question. in qosActionEntry,
>  > possible values for qosActionAction are drop, mark or leave unchanged.
>  > hypothetically speaking let's say that I am talking to a PEP that is
capable
>  > of layer2 as well as layer3 classification. If I install a qos802Ace
entries
>  > in my decision & specify action as mark with Dscp of 0x24 is that an
error?
>  > AFAIK, even if device was capable of looking deep witheen ethernet
frame,
>  > this action will not make sense if payload carried in the frame is
anything
>  > other than IP. If this indeed an error, does that mean specifying an
action
>  > of mark for 802 traffic is not allowed? this becomes more of an issue
now
>  > that latest drafts allow a target entry to point to a mix of IP & 802
>  > filters.
>  >
>  > Regards,
>  >
>  > --Rajiv
>  >
>  >

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 27 Jul 2000 09:42:58 -0700 (PDT)

>   I definitely agree with Andrew that we should not overload the
> definition of DSCP. 

While I can agree from a device perspective, this is incorrect from
a policy perspective.

Our driving goal with policy is to have network-wide policies, and for
DiffServ, we think this means:

- at the edge of the DiffServ cloud, you classify the packets and mark
  them with a DSCP,
- in the middle of a DiffServ cloud, you treat each packet according to
  (and only according to) its DSCP.

With the same policy in all parts of the DiffServ cloud, you can not
have more than 64 different treatments in any one (logical) DiffServ
cloud.  If you want 65 or more different treatments, then you get them
by introducing extra ("internal") edges which divides the one DiffServ
cloud into multiple logical DiffServ clouds.  At the extreme, all you
have are edges; you don't have any middle.  While that's possible from a
device perspective, it's just not useful from a policy perspective.

In the PIB, the DSCP is used to drive the queueing/scheduling/etc. not
only in all the middle routers, but also in the edge router where the
classification was done.  This ensures the same "network-wide" policies
for queueing/scheduling/etc.  can be downloaded into all of these
routers. edge and middle.

In other words, from a policy perspective, rather than overloading the
DSCP, to use it to indicate the desired queueing/scheduling/etc. treatment
is exactly right.
 
Note that it is only the PIB which has this network-wide perspective.
The model document presents a model of *a* router within a DiffServ
cloud.  The MIB is a MIB for *a* router within a DiffServ cloud. 
Both have more generality than is required for the network-wide
perspective, but that's OK.  By analogy, in team sports, individual
players often have the ability to do more than is required by their
role on the team.  To control an individual player, you need to control
all the things that player can do.  To control a team, you need to
control only those things which the players do in their roles on the
team.

Keith.
 
> From: Andrew Smith [ mailto:[email-masked]
> <mailto:[email-masked]> ] 
> I may be reading too much into your answer but I think that those are
> both bad 
> assumptions to make in general (they might be OK in specific deployments
> or for 
> discussion which lead to the whole idea of separating the two for some
> clues as 
> to why this is a bad thing to do. A DSCP is merely a 6-bit label for use
> *on the 
> wire* - it has no meaning internal to a device once it has been
> translated to 
> the PHB that it represents. What happens if you have a device that
> supports 65 
> be able to reflect the capability to influence a drop algorithm using
> more than 
> arbitrary classifier at that point: I think that the PIB should do the
> same - 
> >  > hypothetically speaking let's say that I am talking to a PEP that
> is capable 
> >  > of layer2 as well as layer3 classification. If I install a
> qos802Ace entries 
> >  > in my decision & specify action as mark with Dscp of 0x24 is that
> an error? 
> >  > other than IP. If this indeed an error, does that mean specifying
> an action 
> >  > of mark for 802 traffic is not allowed? this becomes more of an
> issue now 
> ------_=_NextPart_001_01BFF7BC.1E179EC0
> Content-Type: text/html;
> 	charset="iso-8859-1"
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> 
> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
> <TITLE>RE: Question about qosActionEntry</TITLE>
> </HEAD>
> <BODY>
> <BR>
> 
> <P><FONT SIZE=2>&nbsp; I definitely agree with Andrew that we should not overload the definition of DSCP.</FONT>
> </P>
> 
> <P><FONT SIZE=2>&nbsp; Hesham</FONT>
> </P>
> 
> <P><FONT SIZE=2>-----Original Message-----</FONT>
> <BR><FONT SIZE=2>From: Andrew Smith [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
> <BR><FONT SIZE=2>Sent: Thursday, July 27, 2000 12:51 AM</FONT>
> <BR><FONT SIZE=2>To: Michael Fine</FONT>
> <BR><FONT SIZE=2>Cc: rap; diffserv</FONT>
> <BR><FONT SIZE=2>Subject: Re: Question about qosActionEntry</FONT>
> </P>
> <BR>
> 
> <P><FONT SIZE=2>Michael,</FONT>
> </P>
> 
> <P><FONT SIZE=2>I may be reading too much into your answer but I think that those are both bad</FONT>
> <BR><FONT SIZE=2>assumptions to make in general (they might be OK in specific deployments or for</FONT>
> <BR><FONT SIZE=2>specific devices - perhaps that's what you meant?). </FONT>
> </P>
> 
> <P><FONT SIZE=2>For (1), you need to be able to represent rules that filter and/or mark on</FONT>
> <BR><FONT SIZE=2>802.1p and/or DSCP, all 4 combinations of the above, independently.</FONT>
> </P>
> 
> <P><FONT SIZE=2>For (2), I think it is a really bad idea to use DSCP as a canonical</FONT>
> <BR><FONT SIZE=2>representation of a PHB - go back and read all of the ancient Diffserv</FONT>
> <BR><FONT SIZE=2>discussion which lead to the whole idea of separating the two for some clues as</FONT>
> <BR><FONT SIZE=2>to why this is a bad thing to do. A DSCP is merely a 6-bit label for use *on the</FONT>
> <BR><FONT SIZE=2>wire* - it has no meaning internal to a device once it has been translated to</FONT>
> <BR><FONT SIZE=2>the PHB that it represents. What happens if you have a device that supports 65</FONT>
> <BR><FONT SIZE=2>different PHBs? What if a DSCP means one thing on one interface and a different</FONT>
> <BR><FONT SIZE=2>thing on another? You need an internal representation but you must not overload</FONT>
> <BR><FONT SIZE=2>DSCP with that function. </FONT>
> </P>
> 
> <P><FONT SIZE=2>BTW, on a related topic, you discounted my earlier comment that the PIB ought to</FONT>
> <BR><FONT SIZE=2>be able to reflect the capability to influence a drop algorithm using more than</FONT>
> <BR><FONT SIZE=2>just DSCP (the use of VLAN, 802.1p, uni-/multicast or IPsrc/dest information</FONT>
> <BR><FONT SIZE=2>come to mind) - that is why the Diffserv model and MIB allow for placing an</FONT>
> <BR><FONT SIZE=2>arbitrary classifier at that point: I think that the PIB should do the same -</FONT>
> <BR><FONT SIZE=2>this is a gratuitous difference from the Model for the sake of saving a few</FONT>
> <BR><FONT SIZE=2>objects in the PIB definition. If not then at least an extensibility mechanism</FONT>
> <BR><FONT SIZE=2>should be provided to achieve this.</FONT>
> </P>
> 
> <P><FONT SIZE=2>Andrew</FONT>
> </P>
> 
> <P><FONT SIZE=2>[CCing the Diffserv list]</FONT>
> </P>
> <BR>
> 
> <P><FONT SIZE=2>Michael Fine wrote:</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; There are two ways to look at this.</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; 1.&nbsp; The filter is filtering on layer 2 (or any other) information but</FONT>
> <BR><FONT SIZE=2>&gt; the packets are still IP packets.&nbsp; In this case, it still makes sense</FONT>
> <BR><FONT SIZE=2>&gt; to re-write the DSCP in the packet header.</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; 2.&nbsp; The DSCP is a canonical representation of the PHB.&nbsp; It is used</FONT>
> <BR><FONT SIZE=2>&gt; internal to the device to decide how to treat the packet.&nbsp; For</FONT>
> <BR><FONT SIZE=2>&gt; example, it determines which queue to enqueue the packet onto even for</FONT>
> <BR><FONT SIZE=2>&gt; non-IP packets (do such things exist? :-).&nbsp; In this case it would not</FONT>
> <BR><FONT SIZE=2>&gt; imply any modification of the packet header itself.</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; That said, one can imagine a enterprise-specific PIB that, say, maps</FONT>
> <BR><FONT SIZE=2>&gt; DSCP to 802.1p CoS and a device that writes the 802.1p field of a</FONT>
> <BR><FONT SIZE=2>&gt; packet based on the mapped DSCP from the qosActionEntry.</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; Michael</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; Rajiv Dighe writes:</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; From: Rajiv Dighe &lt;[email-masked]&gt;</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; To: rap &lt;[email-masked]&gt;</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; Subject: Question about qosActionEntry</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; Date: Tue, 25 Jul 2000 14:31:28 -0400</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt;</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; Hi All,</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt;</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Pardon me if this seems like a stupid question. in qosActionEntry,</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; possible values for qosActionAction are drop, mark or leave unchanged.</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; hypothetically speaking let's say that I am talking to a PEP that is capable</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; of layer2 as well as layer3 classification. If I install a qos802Ace entries</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; in my decision &amp; specify action as mark with Dscp of 0x24 is that an error?</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; AFAIK, even if device was capable of looking deep witheen ethernet frame,</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; this action will not make sense if payload carried in the frame is anything</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; other than IP. If this indeed an error, does that mean specifying an action</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; of mark for 802 traffic is not allowed? this becomes more of an issue now</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; that latest drafts allow a target entry to point to a mix of IP &amp; 802</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; filters.</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt;</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; Regards,</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt;</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt; --Rajiv</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt;</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp; &gt;</FONT>
> </P>
> 
> </BODY>
> </HTML>
> ------_=_NextPart_001_01BFF7BC.1E179EC0--
> 
> 

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/