The MPLS WG Archive

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

Adding to what Kathie said...

Chatur sharp wrote:
> 
> Hi
> 
> Thanks for your comments. But...

So you accept my comments on AF?
> 
> 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? 

Well, the EF PHB is being studied by a design team at present
because there are indeed one or two problems in the definition.
So maybe we can discuss this when the design team reports back.

> To me DIFFSERV would be fine
> if we take away the policing part. There is no need
> for a meter. Only scheduler is enough. 

Sorry, any kind of QOS mechanism without metering and policing
makes no sense whatever to me. A scheduler is not 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. 

Of course not; you configure the rates so that they fit into
the lowest speed links. 

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

Exactly

> This a sub-optimal use of
> network resources and does not provide any garuntees
> which a lot of applications need.

Hello? There is no free lunch. If you fully commit resources
in a packet switched network with self-similar traffic
distributions, you certainly can't give any guarantees.
That's today's Internet. Mathematically, it's only by
under-committing resources that you can give guarantees
to some traffic streams without starving others.

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

Like any PHB, EF refers to the behavior at a specific egress.
What this says is that the EF rate should be delivered
at a specific egress, independent of other traffic.

> 
> IMHO, DIFFSERV should provide an option to let
> PHBs be associated to destination addresses or egress
> points through a network if needed. 

No, PHBs are stateless so that they can be processed
at line speed only by looking at the 6-bit DSCP.

> It will still
> allow
> diffserv to work in the manner it is working today and

No it wouldn't, because it wouldn't scale.
> 
> will also enable SPs to provide garuntees which are
> required by some of the real-time applications

That is what EF is for already.

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

Well, diffserv was invented to support non-traditional
IP services. Diffserv over MPLS is just one mapping
of diffserv onto a specific lower layer.

  Brian