[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt
Hi Amir,
I think one should ask *why* does the user want to do TE. The reasons that
come to my mind are: alleviate congestion, maximize network utilization,
make sure that the network can fulfill some SLA specified traffic
parameters. Congestion alleviation is the same as saying that you want to
reduce the probability of buffer overflow, which in turn means minimizing
the probability of packet loss across the network. The second reason has the
same goal in mind, with the caveat that you want to do network wide
optimization. In the third case you take into consideration some extra
traffic parameters. Kompella's draft specifically refers to a diffserv
scheme, which implies a QoS behavior. It is always true for store and
forward systems that the buffer capacity and state (utilization/queue
length) are also important when talking about QoS and not only bandwidth. To
that respect Sudhakar is right. In the current draft there seems to be an
implicit idea that all we know (and should know) about the traffic is the
peak rate, and this is not always true. Traffic with affine arrival curves
also has a second term that represents the maximum number of bytes that the
node might have to store to ensure that no traffic is dropped. This gives
you the necessary buffer capacity for that flow.
This is also where the over-subscription factor comes in. Using such a
factor is merely an admission that the chosen arrival curve is not a tight
enough model, but just an upper bound. If no extra information about the
traffic is available when setting up the link, then picking the
over-subscription factor is just a gamble on the part of the operator based,
hopefully, on an educated guess on the *possible* traffic characteristics
(ie the operator makes a statement about the traffic model).
To conclude, I think Sudhakar has made some very valid points regarding QoS
related traffic engineering, which this draft seems to be about.
Cheers,
Cris Lambiri
-----Original Message-----
From: Amir Hermelin [mailto:amir@cwnt.com]
Sent: Tuesday, July 24, 2001 5:07 AM
To: Sudhakar Ganti
Cc: TE-wg (E-mail)
Subject: RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt
Sudhakar,
let me clarify: CSPF calculations are used to find paths that meet
certain traffic constraints (e.g. remove congestion, etc.). QoS has do
with queues, scheduling, etc. TE and QoS are two entirely different
terms.
Engineering traffic according to certain constraints is what the user
wants to do. If those constraints involve QoS, and if he/she wants to
engineer the traffic across multiple platforms, than these constraints
cannot be internal (yes, I know QoS behavior is something vendors do
differently - that's why you don't see a lot of QoS-TE these days...).
If those constraints involve available bandwidth for TE (which is NOT
related to QoS), and the user wants to engineer traffic across multiple
platforms, than vendors have to agree on how to advertise the values
needed as input for the computation - or else it will not generate
correct results. Then, if some vendor wants to allocate RSVP traffic to
queue #5 with high-drop-probability etc. that's their business...
The point is this: *engineering* traffic needs to be based on some
inputs - those have to be set the same in a multi-vendor environment,
whether Diffserv or not. Don't you agree?
--
Amir Hermelin <mailto:amir@cwnt.com>
Charlotte's Web Networks Inc. <http://www.cwnt.com>
> -----Original Message-----
> From: Sudhakar Ganti [mailto:sganti@tropicnetworks.com]
> Sent: Monday, July 23, 2001 4:19 PM
> To: Amir Hermelin
> Cc: TE-wg (E-mail)
> Subject: RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt
>
>
> Hi Amir,
>
> A node allocates bandwidth based on it's own internal
> resources (e.g, buffer), how much you want to book a
> link, design of the node itself, traffic models
> assumed and other such factors. Therefore the BW
> allocation is node's internal view and is implementation
> specific.
>
> All the drafts talk about advertising the "node's view"
> of the resources. That is logical and correct. This is
> needed so that a better decison can be made if "QoS
> routing" is employed in the network. There is no inter-
> operability issue here. You make a routing decison based
> on the "current view" of the network resources.
>
> -Sudhakar
>
> > -----Original Message-----
> > From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
> > Behalf Of Amir Hermelin
> > Sent: Sunday, July 22, 2001 5:33 AM
> > To: Sudhakar Ganti
> > Cc: TE-wg (E-mail)
> > Subject: RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt
> >
> >
> > > 1) First, I am surprised to see a draft describing
> > > bandwidth accounting (or CACing).Thought these
> > > are internal to a node, implementation specific
> > > and should not be influenced by standards.
> >
> > TE bw accounting is mostly *not* internal to a node, *not*
> > implementation specific, and *should* be interoperable.
> Otherwise, why
> > have drafts on advertising these values in the first place?
> >
> > --
> > Amir Hermelin <mailto:amir@cwnt.com>
> > Charlotte's Web Networks Inc. <http://www.cwnt.com>
> >
> >
> > > -----Original Message-----
> > > From: Sudhakar Ganti [mailto:sganti@tropicnetworks.com]
> > > Sent: Saturday, July 21, 2001 12:20 AM
> > > To: Kireeti Kompella
> > > Cc: te-wg@ops.ietf.org
> > > Subject: RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt
> > >
> > >
> > > Hi Kireeti,
> > >
> > > A few more comments on the draft:
> > >
> > > 1) First, I am surprised to see a draft describing
> > > bandwidth accounting (or CACing).Thought these
> > > are internal to a node, implementation specific
> > > and should not be influenced by standards.
> > > 2) The term "priority" is kind of overloaded in
> > > Section 7.1. If priority is referring to a service
> > > class (or a PSC as in Diffserv), then please
> > > change the name appropriately. Or are you inferring
> > > preemption priority is one-to-one mapped to the service
> > > class? I am assuming that is not the case.
> > > 3) I thought Class type is only useful in reducing the
> > > flooding information of IGP protocols and one needs
> > > per-class bandwidth accounting anyway. For example
> > > you can use different CAC parameters for the classes
> > > belonging to the same Class-type, but consume bandwidth
> > > from same aggregated pool. Therefore Class Type band
> > > width pool may not necessarily mean that we don't
> > > need per-class bandwidth accounting.
> > > 4) Is there any reason why you did not discuss FA-LSPs or
> > > hierarchical tunnels, corresponding bandwidth accounting,
> > > bandwidth accounting of LSPs riding on the tunnels and
> > > overbooking?
> > >
> > > -Sudhakar
> > >
> > >
> >
> >
>