RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt

["Amir Hermelin" <amir@cwnt.com>]

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