The MPLS WG Archive

[Chatur sharp <chatur_b@yahoo.com>]

Hi

Thanks for your comments. But...

How about EF? Following is a flick from the EF
definition
RFC2598.

"
   The EF PHB is defined as a forwarding treatment 
   for a particular diffserv aggregate where the
   departure rate of the aggregate's packets from any 
   diffserv node must equal or exceed a configurable
   rate.  The EF traffic SHOULD receive this rate
   independent of the intensity of any other traffic 
   attempting to transit the node.  It SHOULD average 
   at least the configured rate when measured over any
   time interval equal to or longer than the time it 
   takes to send an output link MTU sized packet at 
   the configured rate.  
"

Now I do agree SHOULD is not same as MUST. But given 
the scenario I have drawn how do you meet this 
recommended requirement, over the time scales 
mentioned in the RFC? To me DIFFSERV would be fine 
if we take away the policing part. There is no need
for a meter. Only scheduler is enough. The kind of 
link level rate limiting you are talking about in
DIFFSERV will fall apart once you have network with 
different link speeds. To me DIFFSERV seems like
an attempt to divide one network into as many networks
as the number of DIFFSERV classes, with resources
being
allocated to each of them? This a sub-optimal use of
network resources and does not provide any garuntees
which a lot of applications need.


Anyhow phrases like :
"  The EF traffic SHOULD receive this rate
   independent of the intensity of any other traffic 
   attempting to transit the node.  "

Do not make any sense, till the time you specify what
is the meaning of transit. Does it mean that traffic
coming on interface i and going out of interface j 
will have this commitment? If so it is fine, else
it is losing too much by coarse graining everything.

IMHO, DIFFSERV should provide an option to let
PHBs be associated to destination addresses or egress
points through a network if needed. It will still
allow
diffserv to work in the manner it is working today and

will also enable SPs to provide garuntees which are 
required by some of the real-time applications 


Finally, I think the DIFFSERV-MPLS approach is
the right approach as it really takes into account
need of all kinds of traffic rather than just the
traditional IP services. 


Thanks
C.






--- Brian E Carpenter <brian@hursley.ibm.com> wrote:
> Hi,
> 
> You say
> 
>   "Now the AF class definition says that the domain
> Y
>    and hence node B must provide garuntee that as
> long
>    as traffic coming from A is green it MUST forward
>    it reliably."
> 
> I'm sorry, but RFC 2597 says nothing of the kind. It
> says things like
> 
> >    An AF implementation MUST detect and respond to
> long-term congestion
> >    within each class by dropping packets, while
> handling short-term
> >    congestion (packet bursts) by queueing packets.
> 
> which shows clearly that reliable forwarding is
> *not* part of the
> AF definition. The traffic engineering for services
> based on AF is
> statistical, and obviously requires statistical
> estimates of traffic
> per egress, but there are no guarantees.
> 
>    Brian Carpenter
>    diffserv co-chair
> 
> > Chatur sharp wrote:
> > 
> > Hi folks,
> > 
> > This mail is regards the policing and providing
> > QoS garruntees part of DIFFSERV. I have a feeling
> > that the current definition of PHBs is incomplete
> to
> > implement the AFx as well as the EF class. This is
> > because in the PHB definition the destination of
> > a flow is not taken into account.
> > 
> > For example let us consider a simple network confg
> > as shown below:
> > 
> > Domain| Domain
> > X     |   Y
> >       |
> >       |
> > A ----|---B ---- C
> >       |     \
> >       |      \___D
> > 
> > 
> > In this setup domain X and domain Y are connected
> > via link AB. Both these domains are independent
> > DIFFSERV domain. Let us consider traffic entering
> > domain Y( ingress node B) through domain X (
> egress
> > node B).
> > 
> > Now the AF class definition says that the domain Y
> > and hence node B must provide garuntee that as
> long
> > as traffic coming from A is green it MUST forward
> > it reliably. For example, let us say that the SLA
> > between node B and node A garuntees that as long
> > as traffic flowing is less than 200MB per sec it
> > will treat it as green. But if A doesnot specify
> > the destination of its traffic than B would be
> > forced to allocate this much of bandwidth along
> all
> > its link ( if it is to meet the MUST transfer it
> > reliably requirement). This to me seems a little
> > bizarre. Usually for CAC and traffic engineering
> > you should know the endpoints.
> > 
> > To me it seems that DIFFSERV is not useful as a
> > traffic engineering tool as long as it is not
> > combined with something like MPLS or it does not
> > start including end points for identifying flows.
> > 
> > To me an SLA between any two domains MUST mention
> > the destination address or no garuntees can be
> > provided and the traffic would be best effort.
> > 
> > However, I do believe that in case, there is no
> CAC
> > and hence policing to be performed then DIFFSERV
> can
> > be used to prioritize traffic like in regular
> > CoS-IP world.
> > 
> > Any comments
> > thanks
> > C.
> > 
> > =====
> > I am willing to learn,  if you care to teach.
> > I am willing to teach, if you care to learn.
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Messenger - Talk while you surf!  It's
> FREE.
> > http://im.yahoo.com/
> > 
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 


=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/