[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 was trying to point out that, IMO, although the way in which the bandwidth
utilization is broadcasted is of interest for interoperability, how one
admits a new request bw (the CAC part) is not. This is true if you consider
that CAC depends on how much the operator knows about traffic in a class, as
well as the capabilities of the nodes along the path, and for this I agree
with Sudakar's view that the inclusion of CAC is "surprising".
Cheers,
Cris Lambiri
-----Original Message-----
From: Amir Hermelin [mailto:amir@cwnt.com]
Sent: Tuesday, July 24, 2001 10:58 AM
To: Cristian Lambiri
Cc: TE-wg (E-mail)
Subject: RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt
Cristian,
having read your reply and tried to understand it (I'm not sure I've
completely succeeded), I couldn't understand what the point is. Is it:
1) The ingress can perform a CSPF computation with a bandwidth
constraint on some class, without knowing how much bandwidth is
allocated for that class on every router along the path.
2) Not all routers in a Diffserv domain have to agree on the same PHB
definitions, because QoS is completely internal to a node.
3) Diffserv-TE, as it is defined currently, is not something feasible.
If it's one of the above, then it doesn't relate directly to Kompella's
draft, but rather to the whole set of drafts regarding Diffserv-TE.
Also, I tend to disagree with all of the above.
Please correct me if I misunderstood.
Amir.
--
Amir Hermelin <mailto:amir@cwnt.com>
Charlotte's Web Networks Inc. <http://www.cwnt.com>
> -----Original Message-----
> From: Cristian Lambiri [mailto:Cristian.Lambiri@mapleoptical.com]
> Sent: Tuesday, July 24, 2001 5:04 PM
> To: Amir Hermelin; Sudhakar Ganti
> Cc: TE-wg (E-mail)
> Subject: 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
> > > >
> > > >
> > >
> > >
> >
>