Subject: Re: data issue 4: capacity

From: Matt Squire <[email-masked]>
Date: Fri, 19 Mar 1999 08:04:25 -0500

>> > The capacity metric could also be used to enforce policy, in addition to
>> > its use for advertising physical resources (bandwidth, ports, ... etc).
>> > For example, it can be used for constraining the number of calls from
>> > one AD to another. For example, AD1 may wish not to route more than x
>> > calls from AD2 towards +1408*. This can be achieved by setting capacity
>> > = x in advertisement of 1408* frowarded from AD1 to Ad2.
>> 
>> This introduces the following problem:
>> 
>>            -- AD1--
>>           /        \
>>         /           \
>>       AD2             AD3
>>        \              /
>>         \            /
>>          \          /
>>           \        /
>>            \      /
>>               AD4
>> 
>> AD1 propagates a prefix to AD2, and also to AD3. The prefix is to a
>> gateway with capacity X. So, AD1 propagates capacity X to AD2, and also
>> capacity X to AD3. Both AD2 and AD3 advertise this to AD4, which now
>> thinks there is a total of 2X capacity to the prefix.
>> 
>
>AD4 won't merge two routes to the same prefix. It will select either
>vthe route coming from AD2 or the route coming from AD3. In both cases
>the capacity of calls towards the prefix served by AD1 as seen by AD4
>will still be X.

I'm guessing Jonathan was thinking about a load-balancing scenario, where
AD4 wants to use multiple paths.  To perform load-balancing, an LS would
have to have multiple routes.  Whether you implement this as cycling
through a selection of individual routes, or actually selecting multiple
routes isn't important.  Using a capacity attribute to load-balance, which
is one of the reasons people wanted this attribute (as opposed to just
route selection), interferes with your scenario of partitioning capacity. 

>
>If you use such a metric, we have to make sure that it's value can only
>decrease, but not increase, as it is propogated further from the egress
>gateway.

I'm not sure that this is any different then the capacity attribute as
discussed at the wg.  We decided (I think) that we'd really like to have a
metric on the capacity attribute.  Say we make that metric "max # calls".  

We've always been a little fuzzy on what happens with this attribute at
intermediate LSs.  If an LS is just passing the (prefix,gw) address along,
then I think its clear that it shouldn't modify the capacity attribute.
But if the LS is inserting itself as the next hop, then it of course has
the right to modify the attributes, capacity included.  

But aggregation and deaggregation certainly screws things up.  In the above
example, AD2 could have aggregated +1408 into +140.  Most likely the
capacity attribute changed.  If you sum the capacity attribute (a likely
possibility), then you lose information.  For example, AD2 could be
advertising +140 with a capacity of 5X.  AD4 could then send 5X calls for
+1408 even though, at AD1, there are only X calls for +1408.  Deaggregation
causes similar problems.  

This is one of the many problems with using any true metric in the face of
aggregation and deaggregation.  Its relationship to reality is lost as
information is aggregated and deaggregated.  

Ignoring the problems of aggregation, in order to get any kind of
statistical significance as the information is propagated, I think you need
to mandate similar behavior at each LS.  Although any LS can make a
decision to break up a capacity of X into Y+Z>X.  Say you use a rule to do
Y+Z=1.2X, and another LS breaks up Y into A+B=1.9Y, and another LS breaks
up Z into C+D=1.1Z, etc.  Although you could make statistical decisions,
you would have to make assumptions about Y and Z, but these assumptions
would most likely not be valid unless you know what decisions other LSs are
using.  So in order to get some overall statistical significance to the
system, I think you'd need to have a defined method for handling capacity
in such manner at all LSs.  

Of course, the last time I did any real mathematics was in grad school, and
I had hair then, so maybe you know of a method for getting some statistical
significance out of the system without mandating intermediate behavior - I
just don't see it.  

I also don't see any capacity attribute as providing "guarantees" in the
face of aggreg/deaggreg.  Guidelines, maybe.  Heuristics, sure.  But not
guarantees.

- Matt

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Hussein Salama <[email-masked]>
Date: Sun, 21 Mar 1999 09:30:29 -0800

> route selection), interferes with your scenario of partitioning capacity.

I prefer calling it capacity multiplexing, not capacity partitioning.

I don't think load balancing conflicts with capacity multiplexing as
long as you don't do load balancing between two path leading to the same
egress gateway. This is easy to avoid by comparing the egress
administrative domains in the AS_PATH attribute of TBGP (or its
equivalent) for the various alternate routes. If they are identical for
two routes A and B, no load balancing should be done among A and B.

> information is aggregated and deaggregated.

I agree, that's why we have to be very careful when defining aggregation
rules.

> in such manner at all LSs.

The problem you're describing above disappears if we adopt the
semi-dynamic route advertising/withdrawal mechanism I proposed at the
IPTEL meeting. Just a refresher. We don't want to advertise the
available resources on a route, because it is a dynamic metric. However,
if the utilized resources on a given route as a fraction of the total
capacity exceed a given high water mark, we withdraw that route, and
send an explicit Update message removing it from all call routing
tables. Then when the utilized resources go below a certain low water
mark, we start re-advertising the route once again. No dynamic metrics
involved. 

I still haven't thought about the rules for computing the paremeter "a"
at an LS, where Y+Z=a*X, but I don't think coordinating the value of "a"
at the various LSs is important, because it will not cause routing calls
to egress gateways which have run out of resources, except may be in
some transient states of the network.

Let me briefly summarize the benefits of my proposal for using capacity
multiplexing and semi-dynamic route advertising/withdrawal:
- It permits policy-based sharing of resources among calls from various
origins towards the same egress point.
- The existance of a route in a call routing table means that route
actually has sufficient resources available to accept new calls.
- We can still do load balancing among routes to different egress
points.
- Avoids static partitioning of capacity.
- Avoids dynamic metrics.

The only function a fixed capacity metric (representing the total
resources of an egress point) can achieve is load balancing among routes
to different egress points, and even that is done in a random fashion,
because LSs have no idea whether or not an egress point currently has
resources available.

Hussein

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Mar 1999 23:27:03 -0500

> two routes A and B, no load balancing should be done among A and B.

If there is an AS_PATH; if there is aggregation, this gets collected
into an AS_SET, no? In this case, one cannot tell which domain the
egress is actually in. In fact, an aggregate can represent a whole bunch
of gateways in a whole bunch of domains, each with different capacities.
I'm not convinced we need to get really worried about this; the capacity
metric of an aggregate can never be anything more than a "hint" in any
case, as Matt pointed out. As the route gets propagated more and more,
the attribute has less and less real meaning.

As far as the unit itself, can we agree on the purposely-vague "number
of calls" as a unit?

> mark, we start re-advertising the route once again. No dynamic metrics

Well, one thing at a time. I think your proposal is orthogonal to the
capacity metric itself. I suspect there's going to be a long discussion
around this proposal (I have some concerns), but I'd rather like to
tackle the basic attributes we can at least agree we need, first.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------