Subject: Re: [Diffserv] RFC2597

From: Chatur sharp <[email-masked]>
Date: Tue, 24 Oct 2000 08:55:19 -0700 (PDT)

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 <[email-masked]> 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
> > [email-masked]
> > 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/

---

From: Kathleen Nichols <[email-masked]>
Date: Tue, 24 Oct 2000 10:49:58 -0700

Chatur sharp wrote:
...
> is the meaning of transit. 

The meaning of transit (from www.dictionary.com):

tran·sit (trnst, -zt) 
 n. Abbr. t. 

        1.The act of passing over, across, or through; passage. 
        2.Conveyance of people or goods from one place to another,
especially on a local public transportation system. 
        3.A transition or change, as to a spiritual existence at death. 
        4.Astronomy. 
             a.The passage of a celestial body across the observer's
meridian. 
             b.The passage of a smaller celestial body or its shadow
across the disk of a larger celestial body. 
        5.A surveying instrument similar to a theodolite that measures
horizontal and vertical angles. 

Definition 1 is what we had in mind. I would have thought the others
didn't fit.

> Does it mean that traffic
> will have this commitment? 

It is difficult to tell if you mean by the above: "coming
in on a specific interface i and going out of a specific
interface j" or "coming in on some arbitrary interface i
and going out on some arbitrary interface j".

> required by some of the real-time applications

Again, it is difficult to tell if you mean "associating"
in the sense of applying a classifier on that destination
address and when there is a match, treating it with that
PHB (which is, of course, possible) of if you mean you
want to specifically take all the packets marked for a particular
per-node forwarding behavior and ensure that they egress the
network at a particular point. This is clearly something in
the domain of the control plane, not the forwarding path and
would require that the IGP make a decision based on the DSCP
it seems. This is the wrong working group for that.

> need of all kinds of traffic rather than just the

Then it sounds like your needs are being met. MPLS is a control
plane approach using diffserv mechanisms in the FP. If you like
that approach, it isn't clear what you want this WG to do.

	Kathie

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 24 Oct 2000 19:48:25 +0100 (BST)

>         1.The act of passing over, across, or through; passage.
[..]

n. That's short for noun.

It's unfortunate that you couldn't find a definition supporting your
use of 'transit' as a verb.

Why we have to verb rare nouns instead of saying something perfectly
clear to English-is-second-language-speakers as 'attempting to travel
through' is beyond me. The challenge is perfectly reasonable; 'passing
over' often means 'avoiding', making the use ambiguous as well as
ungrammatical.

If you must resort to quoting a dictionary definition, you need a
rewrite.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Oct 2000 16:44:54 -0500

Adding to what Kathie said...

> Thanks for your comments. But...

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

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

> To me DIFFSERV seems like
> allocated to each of them? 

Exactly

> This a sub-optimal use of

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.

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

> 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

No it wouldn't, because it wouldn't scale.
> required by some of the real-time applications

That is what EF is for already.

> need of all kinds of traffic rather than just the

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