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

From: Vadim Suraev <[email-masked]>
Date: Mon, 23 Jul 2001 20:00:06 +0300

Hi, Kireeti.
I have few comments/questions to the draft:

1). It seems that a case of link bundling is not yet addressed in the draft.
Should maximum normalized BW of bundled link be the max of component links'
normalized maximum BWs ?

2). My assumption is that normalized maximum BW of bundled link is max of
normalized maximum BWs of component links.
If it is correct, I think that a node, which is setting up a flow, cannot
predict a new value of the maximum normalized BW.
Further more, even if the new value of unreserved BW can be predicted, the
node cannot deterministically calculate a path for another flow
before a link state update was received.

3). Regarding to the paragraph 5.2 Analysis, I think it is not clear, to
which values of  unser[0] & unres[7] the following example is applied:
"Another drawback is that Z cannot predict whether setting up a given flow
will cause preemption or not. In the above example, say that Z wants to set
up a 300Mbps flow. In case 1, this will require that the priority 7 flow be
preempted; in case 2, this flow fits without preemption. If Z doesn't want
to cause preemption, Z cannot tell whether it should use link L or not." 
Is it applied to the case 1 when unser[0] == 400 & unser[7] == 200 ?

Best regards,
  Vadim.

KereniX                           	    Data-Aware Optical NetworksTM
----------------------------------------------------------------------------
------
Vadim Suraev 			http://www.kerenix.com     
Phone: +972-3-9050830	                Mobile: 972-53-568711
Fax:  +972-3-9347720		[email-masked] 
70 Pinsker St., POB 10053,   Petach-Tikva 49221 ISRAEL
----------------------------------------------------------------------------
------

---

From: "Amir Hermelin" <[email-masked]>
Date: Tue, 24 Jul 2001 12:07:11 +0300

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:[email-masked]>
Charlotte's Web Networks Inc.     <http://www.cwnt.com>

> -----Original Message-----
> From: Sudhakar Ganti [mailto:[email-masked]]
> 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: [email-masked] [mailto:[email-masked]]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:[email-masked]>
> > Charlotte's Web Networks Inc.     <http://www.cwnt.com>
> > 
> > 
> > > -----Original Message-----
> > > From: Sudhakar Ganti [mailto:[email-masked]]
> > > Sent: Saturday, July 21, 2001 12:20 AM
> > > To: Kireeti Kompella
> > > Cc: [email-masked]
> > > 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
> > > 
> > > 
> > 
> > 
>

---

From: Cristian Lambiri <[email-masked]>
Date: Tue, 24 Jul 2001 07:04:06 -0700

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

---

From: "Amir Hermelin" <[email-masked]>
Date: Tue, 24 Jul 2001 17:57:35 +0300

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.

> From: Cristian Lambiri [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 5:04 PM
> To: Amir Hermelin; Sudhakar Ganti
> Cc: TE-wg (E-mail)

---

From: Cristian Lambiri <[email-masked]>
Date: Tue, 24 Jul 2001 10:54:40 -0700

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