Subject: RE: Intserv marking

From: Shahram Davari <[email-masked]>
Date: Wed, 29 Sep 1999 15:24:12 -0700

Hi David,

You said:

"For packets that comply with the flowspec, the diffserv
marking depends on the network policy for
carry intserv traffic over diffserv domains; there's
an ongoing discussion on that topic in the issll WG."

But I was not talking about mapping Intserv over Diffserv PHBs rather, I was
thinking of having a router which can support both Diffserv and Intserv
without using mapping. Then in that case there is no way to Mark Intserv
compliant packets.

Regards
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 29, 1999 10:09 AM
To: [email-masked]
Subject: RE: Intserv marking

>From the direction of this discussion, the problem of
interest appears to be an Intserv over Diffserv
problem - namely how to mark packets at an Intserv
node so that something reasonable will happen at
a downstream diffserv node.

For packets that comply with the flowspec, the diffserv
marking depends on the network policy for
carry intserv traffic over diffserv domains; there's
an ongoing discussion on that topic in the issll WG.

For packets that don't comply, there are a couple of
choices:
	- If "best effort" is really wanted, then
		a DSCP value of 000000 yields the desired
		result, but one might want to configure
		a different local use DSCP to the same
		PHB in order to be able to quickly
		identify downgraded intserv packets
		at some downstream node.  This implies
		reordering within individual flows.
	- If something between compliant and pure
		best effort is wanted, and in particular
		reordering is considered undesirable,
		then using the AFxy PHBs for all traffic
		provides drop preference differentiation
		without reordering within flows.   There
		are also other PHBs and code points
		(e.g., the non-zero class selectors)
		that do various other things that may
		be of interest.
My reading of the RFCs is that the first alternative
is what was intended - the negotiated flowspec is a
contract with the network, and if the sender violates
the contract, the network is allowed to do bad things.

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

> -----Original Message-----
> From:	Shahram Davari [SMTP:[email-masked]]
> Sent:	Friday, September 24, 1999 12:29 PM
> To:	[email-masked]'; [email-masked]
> Subject:	RE: Intserv marking
> 
> 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]
> ---------------------------------------------------
> 
> 
> > -----Original Message-----
> > From:	Shahram Davari [SMTP:[email-masked]]
> > Sent:	Wednesday, September 22, 1999 7:11 PM
> > To:	[email-masked]
> > Subject:	Intserv marking
> > 
> > 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: John Wroclawski <[email-masked]>
Date: Wed, 29 Sep 1999 19:57:55 -0400

>without using mapping. Then in that case there is no way to Mark Intserv

Shahram,

I do wonder about the strength of the distinction you're making here. 
If a diffserv cloud using the correct choice of edge mechanisms and 
PHB's can effectively act as an intserv "network element" and provide 
the desired services, would there be any significant difference 
between that and what you're asking about?

Beyond that (and contrary to what I believe I said in a private msg 
to you a couple of days ago) David is right that if you do the (not 
completely desirable) thing of just kicking non-compliant intserv 
traffic into the best-effort queue, you could mark the traffic (at 
least within your network) by using an additional DS codepoint that 
is mapped to the BE PHB. If you want to do better than that, there's 
nothing really to stop you (again within your network) from using 
locally assigned DSCPs to mark intserv traffic in various ways (G vs 
CL, compliant vs noncompliant, etc) as input to the scheduler.

Of course when we wrote the specs there was no way to mark packets at 
all, so the comments that it was a good idea were somewhat 
hypothetical. There was also a strong sense at that time that there 
were situations where it wouldn't be desirable to have one router 
within a network depend for its correct functioning on the behavior 
of another. Diffserv, of course, takes the view that it is OK for 
everything within a network to trust each other, and does QoS at 
network (diffserv region) granularity, rather than single-router 
granularity. This makes things simpler, in some ways, for intserv too.

John