Subject: Re: data issue 4: capacity

From: Matt Squire <[email-masked]>
Date: Fri, 26 Mar 1999 09:16:09 -0500

At 10:37 PM 3/24/99 -0500, Jonathan Rosenberg wrote:
>Matt Squire wrote:
>> 
>> Which brings us back to the basic question of what we mean by capacity, or
>> more importantly, how this attribute is treated by LSs (which of course
>> implicitly answers the first question).
>> 
>>  2) should this behavior be different depending if the LS inserts a new
>> next-hop or propagates the same next-hop
>
>I think capacity in this context refers to the gateway, not the routed
>path (answering your other issue), so a change in next hop has no impact
>on this.
>

I'd like to clarify the term 'aggregation' in our context.  
  - Is it aggregation if a LS takes a +1408 route for SIP and a +1408 route
for H323 and combines them into a single route for +1408 and SIP/H323.  
  - Is is aggregation if a LS takes a +1408 route for SIP and another +1408
route for SIP and advertises a single +1408 route for SIP with itself as
the next-hop, but it wants to perform load-balancing betwen the two routes. 
In the second case, the next-hop changes, but the destination and
signalling protocol do not, but I think the capacity should.  I don't know
if I view the second as aggregation, but I think you might.  

>>  3) how should this attribute be treated with regards to
>> aggregation/deaggregation?
>
>Thats the $10M question. Some thoughts:
>
>I think the goal of the capacity metric is to indicate the amount of
>calls, roughly, that can be handled by the set of gateways represented
>by a route (there can be more than one as aggregation occurs). How its
>used is at the discretion of the server policy - perhaps for load
>balancing, as has been suggested. So, when aggregating two routes:
>
>* if the two routes are two prefixes with no overlap, for example 516*
>and 517* getting aggregated to 51, their capacities should add since
>they do not refer to the same gateway. So the total number of calls
>supported by two gateways is (sort of) the sum of their capacities - see
>note below on problems with addition.
>

I think that multiple non-overlapping routes could still refer to the same
gateway, and that some kind of inspection of the path/set is still required
(as you mention below).  

>* if there are overlaps in the prefixes, but the LS_PATH or LS_SET
>(equivalent of AS_PATH/AS_SET, but for Location Servers) don't overlap,
>its also safe to add the capacities, since they don't refer to the same
>gateway.
>

By overlap, do you mean that they don't share any egress domains?  I think
we could ignore overlap "in the middle" if capacity is an egress attribute.  

>I think you need to take the
>size of the prefix into account when adding. So, if prefix 1 (P1) has
>size S1 and capacity C1, and prefix P2 has size S2 with capacity C2, the
>capacity of the aggregate is:
>
>C3 = (C1 * S1  + C2 * S2)/(S1 + S2)
>
>Of course, how does one measure size? I think one can do it similar to
>how it would be done in IP - the number of addresses within the prefix
>(whether or not all the addresses within the prefix exist or not). Its a
>bit harder with phone numbers since the addresses are variable length. I
>think a relative measure is possible, though.
>
>I'm not sure yet on how this would be done when the prefixes overlap,
>but I think its doable.
>

This is certainly different:)

So, in effect, the unit for capacity becomes "average number of calls per
phone number".  Although the calculations would project a uniform
distribution of capacity across all destinations, which certainly isn't the
case, it does seem to be more interesting than most other suggestions.  I
need to think about this more. 

- Matt

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 26 Mar 1999 21:56:21 -0500

> for H323 and combines them into a single route for +1408 and SIP/H323.

Well, I wasn't really thinking of allowing aggregation when the
signaling protocol attribues were different. This would require us to
define codepoints for all 2^N combinations of N signaling protocols,
kind of messy. But, if we did do this, yes, I would call it aggregation.

> if I view the second as aggregation, but I think you might.

Yes, I agree the capacity would change here.

> gateway, and that some kind of inspection of the path/set is still required

True if a gateway provider advertises different prefixes for the same
gateway.

> we could ignore overlap "in the middle" if capacity is an egress attribute.

True. However, when there is aggregation, the LS_PATH is lost (I
believe), and its converted to a LS_SET, so you couldn't tell whats "in
the middle" as opposed to egress.

> need to think about this more.

Yes, its a density. And yes, it does project a uniform density. I also
need to think more about it :)

-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

---------