The MPLS WG Archive

[Brian E Carpenter <brian@hursley.ibm.com>]

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/