Subject: Intserv marking

From: Shahram Davari <[email-masked]>
Date: Wed, 22 Sep 1999 16:11:07 -0700

Hi Intservers,

In RFC 2211 and 2212 it is recommended to mark the non-compliant packets as
BE traffic. Could somebody tell me how is this marking done over an IP
packet? As far as I know the first 6 bits of the ToS field is used by
Diffserv and the last 2 bits by ECN.

I appreciate your response.

Regards,

                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
          Shahram Davari
          Systems Engineer, Product Research
          PMC-Sierra Inc. 
          105-8555 Baxter Place
          Burnaby, BC V5A 4V7, Canada
          Phone: +1 (604) 415-6000, Ext. 2428
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/

---

From: [email-masked]
Date: Thu, 23 Sep 1999 10:00:43 -0400

Shahram Davai wrote:
>BE traffic.

I don't think 'BE' mentioned in 2211 and 2212 is in the same context as BE in
DiffServ (vs. AF/EF).
In our implementation, IntServ treats DiffServ link as a QoS-capable link that
spans one or multiple router hops, terminating at an DiffServ exit router which
is also IntServ capable.  IntServ traffic is mapped to DiffServ AF or EF based
on customers' policy.  If EF is used, non-compliant packets will be dropped. If
AF is used, non-compliant packets will be marked as DP2 or DP3 as appropriate
(this is BE from IntServ point of view?).  No separate DSCPs are used for
IntServ.

Liang Li.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 23 Sep 1999 17:40:56 -0700

Steve,

Correct; local DSCP may be used. But what if you want to convey the
information about the conformance of the packet to the other networks
downstream?

Shahram

-----Original Message-----
From: Steve Blake [mailto:[email-masked]]
Sent: Thursday, September 23, 1999 5:37 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: Intserv marking 

Shahram Davari wrote:

> In RFC 2212 in page 9 it is explicitly mentioned:
> "Best effort is defined as the default service a network element would
give
> to a datagram that is not part of the flow".
> So the BE on RFC 2212 is exactly the same as Diffserv BE, which is the
> default behavior.
> It is possible to map Intserv to Diffserv PHBs as you mentioned, but if
such
> mapping is not required, and a network operator decides to support both
> Intserv and Diffserv in the same router, then to support both conformant
and
> non-conformant Intserv traffic, a separate DSCP is needed for Intserv. 
> 
> Don't you think so?

I think that if a provider is running IntServ on each router and not
layering
IntServ-onto-Diffserv in the core, then there is value in designating
non-conforming packets using a DSCP value (to be used in much the same
way as the AF drop precedence indicator).  But contrary to my previous
views I think that this codepoint should not be standardized and should
come out of the local use space.  One practical reason is that you would
not want to confuse this codepoint with others which map the traffic into
a particular Diffserv queue (since the IntServ flows may be serviced by a
different set of queues than those for Diffserv traffic).

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake                  <[email-masked]>
Ericsson IP Infrastructure             (919)468-8466 x232

---

From: Shahram Davari <[email-masked]>
Date: Fri, 24 Sep 1999 09:28:50 -0700

Hi,

But what about compliant packets? How are they differentiated from
non-compliant packets? We need 2 DSCPs; one for compliant and one for
non-compliant packets. 

Don't you think so?

Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, September 23, 1999 9:11 PM
To: [email-masked]; [email-masked]
Subject: RE: Intserv marking

Mark it with a DSCP of 000000 - see Section 4.1 of
RFC 2474.  This is one of the very few REQUIRED
PHB mappings in Diffserv.  Other code points could
be used (e.g., to preserve the information that
the packet was remarked as best effort from GS or CL),
but that is a matter for local domain configuration.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]
---------------------------------------------------

> From:	Shahram Davari [SMTP:[email-masked]]
> Sent:	Wednesday, September 22, 1999 7:11 PM
> To:	[email-masked]
> Subject:	Intserv marking
> 
> Hi Intservers,
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 24 Sep 1999 11:10:12 -0700

Hi steve,

As you and somebody else mentioned, we can do MF classification of Intserv
flows first, to identify the Intserv flows. And we can use LU/EXP DSCPs to
differentiate conforming and non-conforming packets. But the danger is when
a downstream router which doesn't support Intserv but supports Diffserv only
receives the packet. In that case the DSCP may be interpreted as a
Diffserv-PHB! Besides this 6-bit fields belongs to Diffserv doesn't it? 

The other point is that in both RFC 2211 & 2212, there is not even a single
word about reordering requirement for Intserv flows, and in fact in RFC 2212
page 11, it is mentioned "to minimize  problems of misordering, reshaping
points may wish to forward BE datagram from the front of the queue", which
means reordering is anticipated. 

Also in RFC2211 two methods are suggested; a) to use a separate queue  for
non-conformant CL packets; b) use the same BE queue but with higher
drop-precedence. Which means it is anticipated that the non-conformant
packets will not be serviced in the same queue as conformant packets.

But I do remember that when this RFC was still an I-D, there were some text
in it which explicitly mentioned that BE in these drafts meant BE from the
viewpoint of the Intserv not BE in the strict sense and that the
non-conformant packets should stay in the same queue as conformant packets
to avoid reordering. But it is obvious that those text are removed and I
assume it was intentional.

Regards
Shahram

-----Original Message-----
From: Steve Blake [mailto:[email-masked]]
Sent: Friday, September 24, 1999 10:27 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Intserv marking 

> but that is a matter for local domain configuration.

You can always use any value of DSCP as long you are picking out the
non-comforming packets using a MF classifier (which includes DSCP as part
of the filter spec), but it is a mistake to associate non-conforming
IntServ packets with default (best-effort) packets.  You want non-
conforming packets to be served in the same queue as the conforming ones
(with possibly higher drop precedence) to avoid micro-flow reordering,
and you may want to restrict the bandwidth available to non-conforming
traffic to less than that reserved for default traffic.

Practically, it is probably better to choose an EXP/LU codepoint to
avoid having mysterious things happen if the classifier is misconfigured.

If one or more AFxy PHB groups are reserved for handling CL and GS traffic
then those codepoints are fine.

Regards,

---

From: [email-masked]
Date: Fri, 24 Sep 1999 15:17:33 -0400

Shahram Davari wrote:
>                                                                  But what if
you want to convey the
>information about the conformance of the packet to the other networks

In pure IntServ, there is no means to convey the information about the
conformance of each packet to the networks downstream.  So I guess I don't
understand why there is now such a requirement when you run IntServ side-by-side
with DiffServ.  If this is for non-IntServ DiffServ node, DiffServ shouldn't do
anything special for non-DiffServ flows.

Also, if you run IntServ parallel to DiffServ (as opposed to mapping to
DiffServ), it appears either you define a new set of PHBs and get new DSCPs so
that the GS/CL QoS can be reserved; or you use the BE DSCP (as David Black
suggested), and at each IntServ hop you apply local GS/CL treatment to satisfy
the IntServ requirement (just view the total bandwidth not as 100% of link but
only the BE % of the link...  This is kind of like a hierarchical model).

Regards,
Liang.

---

From: Shahram Davari <[email-masked]>
Date: Fri, 24 Sep 1999 12:28:47 -0700

If in pure Intserv there is no mean to convey the conformance level of
Intserv packets, then why in RFC2212 page 10, it is mentioned that: "If
marking is available, the non-conformant datagrams SHOULD be marked"?

Shahram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 24, 1999 12:18 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: IntServ marking

Shahram Davari wrote:
>                                                                  But what
if
you want to convey the

In pure IntServ, there is no means to convey the information about the
conformance of each packet to the networks downstream.  So I guess I don't
understand why there is now such a requirement when you run IntServ
side-by-side
with DiffServ.  If this is for non-IntServ DiffServ node, DiffServ shouldn't
do
anything special for non-DiffServ flows.

Also, if you run IntServ parallel to DiffServ (as opposed to mapping to
DiffServ), it appears either you define a new set of PHBs and get new DSCPs
so
that the GS/CL QoS can be reserved; or you use the BE DSCP (as David Black
suggested), and at each IntServ hop you apply local GS/CL treatment to
satisfy
the IntServ requirement (just view the total bandwidth not as 100% of link
but
only the BE % of the link...  This is kind of like a hierarchical model).

Regards,
Liang.

---

From: [email-masked]
Date: Fri, 24 Sep 1999 16:24:33 -0400

Shahram:

You are right; I was mistaken on GS.  But, if IntServ is not mapped to DiffServ
somehow, I am not sure marking is availble to IntServ.  You can't on the one
hand put IntServ outside of DiffServ, on the other hand use DiffServ DSCPs for
IntServ's conform/non-conformant marking.  Seems to me either new PHBs need to
be added or IntServ uses BE DSCP.

Regards,
Liang.

To:       L Li/Raleigh/IBM@IBMUS, Shahram Davari
          <[email-masked]>, [email-masked]
cc:
From:     Shahram Davari <[email-masked]>
Date:     09/24/99 07:28:47 PM GMT
Subject:  RE: IntServ marking

Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 24, 1999 12:18 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: IntServ marking

if
you want to convey the

Regards,
Liang.

---

From: JJ Krawczyk <[email-masked]>
Date: Fri, 24 Sep 1999 20:45:17 -0400

Shahram,

I'm not sure what "pure intserv" is....

When the intserv work was being done years back, long before the acronym
"diffserv" was uttered, the group acknowledged that no means existed in
IPv4 to mark packets as non-conformant.  However, the consensus was to NOT
shut the door on this possibility should a marking capability become
available.

Or at least that's how I remember it.

I think the reason you are getting frustrated (or at least it sounds like
you are - hard to tell in email) is that, as far as I know, not many people
have thought about mixing diffserv and intserv together in the same
networks.  Most of the thought has gone into "intserv at the edges,
diffserv in the core".  I'm not sure how many people want to do it
differently.

Again, that's just my recollection.

-jj