Subject: RE: Intserv marking

From: [email-masked]
Date: Wed, 29 Sep 1999 13:08:32 -0400

>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:39:30 -0400

>the contract, the network is allowed to do bad things.

David,

The specs do impose some conditions on (goals for? There's one 
SHOULD) non-compliant traffic, and it is not optimal to just dump it 
into a single FIFO best-effort queue. An implication is that the 
comments that a couple of people have made here that "the specs say 
that you literally turn noncompliant intserv traffic into 
best-effort" is not really right.

Speaking for CL in particular, the goal was to keep non-adaptive 
non-compliant CL traffic from killing adaptive BE traffic. The spec 
basically says that

a) when the traffic is within the flowspec you see an unloaded net 
(queueing delay equivalent or less than what you'd get dumping your 
own bursts into a pipe the size you asked for)

b) when the traffic is noncompliant it should get a (loosely defined) 
fair share of any available bandwidth above the reservation level.

The intention of CL is to let you try to send as much traffic as you 
want to, in case the network can carry it, but to give you a floor 
level that you can count on working well. This is very useful for 
adaptive audio/video coding, multiparty conversations using RSVP's SE 
or WF reservations, and so on.

It was a goal that there be a number of ways to implement this or 
acceptable approximations to it. CL was also intended to allow 
scheduling of aggregates rather than demanding per-flow queueing, and 
in fact I think that using AF with the right edge mechanisms and 
bandwidth allocation could be a very good one - looks a lot like some 
of the early implementation pictures, except we didn't know what to 
call the funny queue yet..

G has similar words, but it is a little harder to do in practice 
because there is a question of how quickly the guarantee is 
re-established after non-compliant traffic becomes compliant again.

John