Subject: RE: Intserv marking

From: Shahram Davari <[email-masked]>
Date: Thu, 23 Sep 1999 14:28:46 -0700

Hi,

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?

Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, September 23, 1999 7:01 AM
To: [email-masked]
Subject: re: Intserv marking

Shahram Davai wrote:
>In RFC 2211 and 2212 it is recommended to mark the non-compliant packets as
>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: Steve Blake <[email-masked]>
Date: Thu, 23 Sep 1999 20:36:31 -0400

> non-conformant Intserv traffic, a separate DSCP is needed for Intserv. 

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: Ping Pan <[email-masked]>
Date: Fri, 24 Sep 1999 09:08:53 -0400

Hi,

IMHO, in terms of implementation, IntServ CL "flows" and DiffServ AF
packets can be treated the same at queuing and buffer management level,
as mentioned by Liang.

This also brings up another interesting issue: how do routers separate
IntServ and DiffServ packets on receive? One way is to mark all IntServ
packets with some different DSCP. 

Another way is that if IntServ flows are managed by RSVP, we just have
to make sure checking IntServ packets prior to DiffServ. The code flow
will be something like:

...
check for IntServ (5-tuple matching);
if matched
  send to the QoS queue(s);
  exit;
check the DSCP
if AF/EF
  send to the QoS queue(s);
...

The second approach, you don't need to do any DSCP marking for IntServ
flows.

Regards,

- Ping

---

From: "Hungkei (Keith) Chow" <[email-masked]>
Date: Fri, 24 Sep 1999 11:04:58 -0400

Hi Ping,

I think Shahram was particularly concerning the non-conformancing IntServ traffic.

Your second suggestion might work if policing is done at all nodes. But, if you
only police flows at the edge of the network, some form of marking is required.

IMO, I think it is the problem with IntServ itself so it might not be appropriate
to use a
standard DSCP to solve it.

My 2c,
-- Keith.

---

From: Ping Pan <[email-masked]>
Date: Fri, 24 Sep 1999 11:16:40 -0400

> only police flows at the edge of the network, some form of marking is required.

In both IntServ and Diffserv, traffic conditioning will take place at
both edge and interior of the network. In a node cannot deal with
IntServ, then so be it. RSVP will detect the problem, and the IntServ
flows will suffer. I think in the current framework, packet marking is
for DiffServ traffic only.
 
> standard DSCP to solve it.

BTW I remeber Yoram has a DSCLASS proposal, what's the status on that?

- Ping