Subject: data issue 4: capacity

From: Matt Squire <[email-masked]>
Date: Thu, 11 Mar 1999 21:21:16 -0500

4) Capacity.

I think we have consensus that a capacity attribute is needed.  What we
mean by capacity, unfortunately, is still up in the air.

  a) Should capacity be unitless and relative, or measurable and
     absolute?  
  b) If measurable/absolute, what are the appropriate metric(s).  Some
     possibilities are bandwidth, maximum circuits, load, (others?)...
  c) What are the timescales that capacity can be changed?  In other
     words, does it represent some maximum capacity (constant) or
     current capacity (depends on load).
  d) Is capacity an attribute of an egress gateway, or to the signalling
     path, both, or do we need two different capacity measurements (one
     for path, another for egress gw)?

The definition and use of capacity will most likely differ depending upon
your preference for the SCSP or BGP approach.  With the SCSP approach, I
suggested a unitless, relative capacity which represents the capacity of
the egress gateway.  I thought that we had come to such a consensus during
Jonathan's presentation at the last wg meeting.  

With the SCSP approach, this makes more sense because the its very
difficult to infer anything about the capacity of the IP path because of
the explicit separation of the call routing from the IP routing.  With the
SCSP approach, an LS that aggregates or changes the next hop information
could modify the capacity to include the capacity of the path between the
LS and its next-hop.  The value of such a modification is limited because
it does not reflect the capacity of the data path, which is much more
likely to be the bottleneck.

With the BGP approach, carrying e164 numbers in BGP integrates data and
call routing, and thus capacity information about the IP path can be
integrated into the capacity metric.  In the current TBGP draft, it is
considered an open issue whether TBGP is a simple extension to BGP (and
thus yields this integrated routing) or whether TBGP is a different
instance of the protocol.  I believe that if TBGP is a different instance
of the protocol (and is separated from the IP routing information), then it
will not be able yield an accurate reflection of path capacity.  

A unitless measurement has a disadvantage in that it is an administrative
manner to ensure that the weight of a gateway reflects is capacity relative
to other gateways.  In an inter-domain protocol, this requires some
administrative coordination across domains.  A measurable capacity would be
nice, but it seems that no single metric would suffice, and if we permit
multiple metrics, then we're faced with the problem of determining which
capacities are larger than others (ie is 20 circuits better than 100 Mbs or
not).  

In either case, I'd recommend that the capacity attribute NOT reflect
anything about the real-time load on a gateway or path.  Due to the
complications of multiple metrics, I'd also recommend that capacity remain
unitless and that it be an administrative exercise for the capacity to be
consistent across the confederation of iptel domains.  Hence, I'd propose a
simple 4-octet field that can be used do determine relative capacity.

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

---

From: "Hussein F. Salama" <[email-masked]>
Date: Sun, 14 Mar 1999 19:01:28 -0800

> will not be able yield an accurate reflection of path capacity.

Depends on how similar the IP ASes topology and TBGP Administrative
Domains (AD) topology are.

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. 

It may be worthwhile to define two metrics for capacity, one for
physical resources and another one for policy.

Hussein

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Mar 1999 22:23:36 -0500

> Domains (AD) topology are.

I believe we agreed that independent of whether SCSP or TBGP is used,
the protocol runs independent and outside of the current routing
infrastructure.

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

For your approach to work, the advertisements originated by an AD for a
prefix in a gateway  must have the sum of the capacities of the metrics
less than the actual gateway capacity. This results in a very
inefficient, static division of resources.

So, I'd rather not associate any "guarantees" on capacity with this
metric. I think the metric needs to have a unit, else providers won't
know how to select values that are comparable across providers (I think
there was consensus on this too during the meeting, but speak up if I'm
confused). But, we should treat this as nothing more than a "hint",
useful for making (1) policy decisions (as any attribute is useful for
that purpose), and (2) load sharing decisions between gateways.

-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

---------

---

From: Hussein Salama <[email-masked]>
Date: Thu, 18 Feb 1999 23:18:25 -0800

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

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.

> inefficient, static division of resources.

In your example, assume the gateway at AD1 has a total capacity of X. It
advertises a capacity of Y to AD2 and a capacity of Z to Ad3. 

I think the only constraints on Y and Z should be:
0 <= Y <= X and 0 <= Z <= X. 

However Y + Z shouldn't necessarily be less than or equal to X. I think
it should be possible to achieve efficient utilization of resources by
selecting Y and Z such that Y + Z > X based on some statistical analysis
of call arrivals and call durations.

> metric. I think the metric needs to have a unit, else providers won't

From the above, you only guarantee that a minimum number of calls ( = X
- Z) will be accepted from  the AD2 route, and a minimum number of calls
(= X - Y) will be accepted from the AD3 route. No guarantees beyond
that.

> that purpose), and (2) load sharing decisions between gateways.

It's different from the originally proposed capacity metric, because it
can be modified hop by hop based on local policy. It could lead to a
fair utilizations of resources among calls from different origins. I
don't think it's much more difficult to define that the originally
proposed metric. The original capacity metric was proposed to be set
equal to the total capacity at the egress gateway and does not change
hop by hop. This is a special case of what I am proposing.

Hussein

---------