Subject: Re: [Diffserv] A question on re-mapping

From: Aditya Manpuria <[email-masked]>
Date: Mon, 24 Apr 2000 19:21:21 +0530 (GMT+0530)

Anoop,
   Your observation holds good under the following conditions -
1) the router is using the AF PHB (and a DS compliant router need not
necessarily implement this PHB)
2) out-of-profile packets are remarked with DSCP values from the same
class
(I am assuming that the resources allocated for any AF class, including
its drop precedence levels, is constant)
   
   In the generic case, when a packet (with DSCP X) is remarked with DSCP
Y, it starts competing for resources (buffer space/bandwidth) intended for
"in-profile" traffic in the BA corresponding to DSCP Y. 
   Now, when congestion sets in, and the router has to decide which
packets to drop, I feel "out-of-profile" packets which have been remarked
to this BA should be dropped first since there could be scenarios wherein
such "out-of-profile" packets could hog a major part of the resources
intended for this BA thereby starving traffic which are "in-profile" and
belong to this BA.
   (In a way, this could also hold good for packets remarked within the
same AF class) 
   This is why I feel that we should look at some means of tagging packets
as "out-of-profile" and using it to preferentially drop packets.
   
Regards,
Aditya.

On Sun, 23 Apr 2000, Anoop Ghanwani wrote:

> 
> The DSCP contains information that says that this packet
> belongs to a particular class but has been downgraded.
> For example, a packet marked with AF11, gets downgraded to
> AF12, or AF13, which means the AF class stays the same
> but the packet has a higher drop preference.  So there's
> nothing unfair :-)
> 
> -Anoop
> 
> [email-masked] wrote:
> > 
> > Hi,
> >         I am relatively new to this mailing list. While going through the
> > RFCs and drafts on diffserv, I had some thoughts which I would like to
> > share with you. Your comments would be much appreciated.
> > 
> >         Consider the following scenario -
> > 
> >         In-profile traffic is mapped to a particular DSCP (say X) and
> > out-profile traffic is mapped to another DSCP (say Y) which will lead the
> > routers to adopt a relatively "inferior" forwarding behaviour.
> >         At the time of congestion, the router might want to drop packets
> > from the BA whose corresponding DSCP value is Y. In this scenario, the
> > probability of dropping packets which are "in-profile" and are mapped to
> > this DSCP (ie Y) is equal to that of "out-profile" traffic which has been
> > remapped to this DSCP.
> >         Is this not unfair ?
> >         Instead should we not look at some form of tagging mechanism to tag
> > packets as "out-of-profile" when remapping them to other DSCP values.
> > Probably one of the two unused bits in the DSCP octet could be used for
> > this purpose. The router could then preferentially drop packets within a
> > particular BA.
> > 
> > Regards,
> > Aditya.
> > 
> > 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> -- 
> Anoop Ghanwani, IP Infrastructure, Nortel Networks, Billerica, MA
> Ph: 978-288-4514  Fax: 978-288-0620   [email-masked]
> 

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

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 24 Apr 2000 17:04:26 -0700

Aditya Manpuria wrote:
	[..]
> "in-profile" traffic in the BA corresponding to DSCP Y.

This scenario misuses DSCPs. By definition you should only
map traffic into a given DSCP if *all* packets so marked are intended
to get the same service. It is never the intention that the same
DSCP provides multiple levels of servic - that's what other DSCPs
are for.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley