Subject: Re: data issue 4: capacity

From: Matt Squire <[email-masked]>
Date: Wed, 24 Mar 1999 08:29:22 -0500

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

Sounds as good as anything else I've heard.

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

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

 1) when propagating a route, should the capacity attribute remain
unchanged or should an LS be permitted to alter its value (ex. call
multiplexing/partitioning)
 2) should this behavior be different depending if the LS inserts a new
next-hop or propagates the same next-hop
 3) how should this attribute be treated with regards to
aggregation/deaggregation?

These are the kinds of questions we're going to have to handle for every
attribute we define and relate to whether an attribute is a function of the
egress gw(s), of the advertisement's path, or of the call-routing path.

In basic BGP, all attributes are attributes of the path.  In GLP, we seem
to be talking about three different kinds of attributes.  Do we classify
capacity as a property of the gateways, of the routed path to the gateways,
or of the routing advertisement's path?  I'm assuming the latter
alternative is not desired by anyone, but the first two seem viable.  

I think Hussein's capacity might be a capacity of the routed path, where
Jonathan's might be of the egress gateways.  Do we need a multiple capacity
attributes? 

In a related note, I think we might need two PATH attributes.  For lack of
anything better, I'll call them CALL_ROUTED_PATH and ADVERTISEMENT_PATH.
The ADVERTISEMENT_PATH would describe the path of propagation of the call
route, and the CALL_ROUTED_PATH would describe the path that a call using
this routing object would take.  Due to the fact that an LS need not insert
a new next-hop, these paths are likely to be different.  The
ADVERTISEMENT_PATH can be used for things like loop-detection, and the
CALL_ROUTED_PATH seems more useful for route selection since it shows the
actual route for potential calls.  

- Matt

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Mar 1999 22:37:24 -0500

> multiplexing/partitioning)

If a route is not aggregated or de-aggregated, but just propagated as
is, I think an intermediate LS shouldn't modify the capacity. Only the
originator of the route should decide how to set it.

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

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

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

* if there is partial overlap, so with prefix P1 and P2, P1 intersection
P2 = P3, with the size of P3 less than both P1 and P2, you want to come
up with a number less than the sum of the capacities, since there might
be overlap.

* if there is full overlap, so that P1 is a subset of P2, you may want
to do something much less than the sum as the aggregated capacity.

In fact, even for non-overlapping routes, addition doesn't work.
Consider the following example. Gateway 1 serves a single number, +1
555-1212, and has a capacity of 100. Gateway 2 serves all the US, +1 *,
and has a capacity of 1. These prefixes can be aggregated into +1 *.
But, the capacity isn't really 100+1 = 101, since you can't actually
support 101 calls to anywhere in the US. 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.

> alternative is not desired by anyone, but the first two seem viable.

As I mention above, I think its a gateway metric. Its usually determined
by size of the trunk to PSTN, DSP resources, and things that are gateway
specific. The call routing path (set of LS servers, *not* the IP path) 
may have limits, but I suspect they are substantially higher than
gateway limits, and it seems easiest to ignore them.

> actual route for potential calls.

Why do you need the actual route? In normal routing, you only know the
next hop, not the whole routed path. Also, with aggregation, you won't
know the advertisement *path*, but rather the advertisement *set*.

-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 F. Salama" <[email-masked]>
Date: Wed, 24 Mar 1999 19:53:41 -0800

> Jonathan's might be of the egress gateways.  Do we need a multiple capacity

Yes, either multiple attributes or none at all. 

> actual route for potential calls.

The ADVERTISEMENT_PATH is identical to BGP's AS_PATH. Right?

I think I understand what you mean by the CALL_ROUTED_PATH, but I don't
see how you'll be able to compute it. For example:

          gw1----AD1----AD2----AD3----AD4----AD5----gw2
        1408*     |                           |
                  |                           |
                  |-----AD6----AD7----AD8-----|
                         z      y      x

Assume the call routing AD topology is identical to the layer 3 AS
topology, i.e., AS=AD in the above picture. Assume also that for call
routing AD5 prefers routes advertised by AD4 over those advertised by
AD8, while for layer 3 routing AD5 prefers routes advertised by AD8 over
those advertised by AD4. Assume also the LSs at all AD do not change the
next hop attribute for any call routes they advertise. gw1 is part of
AD1 and gw2 is part of AD5.

As a result at AD5:
 - The call route to 1408* will have gw1 as the next hop and the
   ADVERTISEMENT_PATH will be {AD1, AD2, AD3, AD4}.
 - The layer 3 route towards gw1 will next hop x (some router in AD8)
and the
   AS_PATH will be {AD1, AD6, AD7, AD8}.

Now when a call arrives at gw2 for 14089876543, gw2 routes it directly
to gw1.  The call route has a single hop gw2 (AD5) --> gw1 (AD1). The
layer 3 route, on the other hand will have multiple hops:
     gw2 (AD5) --> x (AD8) --> y (AD7) --> z (AD6) --> gw1 (AD1)

How can call routing guess/compute such a CALL_ROUTED_PATH? The
situation is even worth when define different boundaries for the call
routing ADs than those of the layer 3 ASs. Assuming that layer 3 routing
and call routing are completely independent, I don't see how call
routing can capture the characteristics of a layer 3 route. Unless:
	- the AD boundaries overlap (or almost overlap) with those of the
          corresponding ASs, and
	- a proxy is inserted as the next hop at each intermediate AD on
the                ADVERTISEMENT_PATH. 
The result will be ADVERTISEMENT_PATH = CALL_ROUTED_PATH.

How do you define call route? Is it the signaling route, or the media
route, or the signaling+media route? I think it is more important to do
route selection based on the media route not the signaling route,
because it's the one which will carry the bulk of the traffic. That's
when a media proxy or a signaling+media proxy comes in handy.

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, 25 Mar 1999 21:07:31 -0500

> Yes, either multiple attributes or none at all.

I would generally think, based on the KISS principle, one attribute is
the best choice.

> see how you'll be able to compute it. For example:

No; this is not my understanding. We have agreed that there is no
relationship between IP telephony administrative domains and the layer 3
AS topologies. The "path" we talk about in GLP is for signaling messages
between location servers, and has nothing to do with either the layer 3
path between location servers, and certainly nothing to do with the
media path.

My understanding of Matt's ADVERTISEMENT_PATH vs. CALL_ROUTED_PATH is
the following:

GW1------LS1--------LS2-------LS3

GW1 propagates a route to LS1, which goes to LS2, then to LS3. The
ADVERTISEMENT_PATH is {GW1, LS1, LS2} when it arrives at LS3. Now, lets
assume that GW1 lists itself as the next hop (for signaling, remember),
LS1 does not change this next hop, but LS2 places itself as the next hop
before propagating the route to LS3. Now, if LS3 sets up a call to GW1,
the signaling messages go from LS3 to LS2 to GW1. So, call
CALL_ROUTED_PATH is {GW1, LS2} when the route arrives at LS3.

> when a media proxy or a signaling+media proxy comes in handy.

Since there is a total separation of media path/layer 3 topology from
signaling/GLP topology, there's little we can do here.

In any case, I'm very uneasy about these signaling+media proxies. We
have a perfectly fine layer 3 routing topology. We need GLP to help us
find our way, signaling wise, to gateways. But, once we've got that, we
know the IP address of the gateway. Why send the media through proxies?
Its inefficient, routing wise, and makes the scalability of these boxes
orders more complex.

-Jonathan R.

---------

---

From: "Hussein F. Salama" <[email-masked]>
Date: Thu, 25 Mar 1999 20:34:18 -0800

> I would generally think, based on the KISS principle, one attribute is

Except that we have two types of capacity (egress gateway capacity and
call route capacity) which IMHO are equally important and I don't see a
way for combining them into a single attribute.

> CALL_ROUTED_PATH is {GW1, LS2} when the route arrives at LS3.

I'm not sure if GW1 should be included in the ADVERTISEMENT_PATH and the
CALL_ROUTED_PATH, but that's a minor thing.

> signaling/GLP topology, there's little we can do here.

We can force both signaling and media to follow the same path. 

I may be missing something, so let me ask a basic question: What's the
use of doing multi-hop call signaling if, at the end, we won't have any
control over the media path? 

In your above example, when using signaling only proxies, call signaling
from an endpoint, EP, in LS3's domain to GW1 has to hop through LS2, but
the media streams of the same call may not flow through LS2's domain at
all. 

Here are some possible services that an intermediate proxy may offer for
a call:
- Control over capability negotiation and media channels
- QoS for the media
- Policy
- Security
- Accounting, Billing

If the media doesn't flow through LS2's domain, which of the above
services can LS2 provide for this call? And even if it can provide any
of these services, why would it care to be involved in the call at all?
Are there other services I am missing?

> find our way, signaling wise, to gateways. 

Yes, we need GLP, but it does not need to be a multi-hop call routing
protocol unless we want to control the media path through the IP
network. The signaling proxy at LS2, and intermediate signaling hops in
general, are not necessary for gateway location. A single hop call
routing protocol or a directory-based solution are sufficient for
locating gateways.

> But, once we've got that, we

Based on my experience with Cisco's H.323 signaling+media proxy, I claim
that it is quite efficient, routing wise. AND it can provide most of the
services listed above.

Hussein

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 26 Mar 1999 00:14:43 -0500

> way for combining them into a single attribute.

Again, let me make sure we're talking about the same thing. For call
route capacity, we're talking about the capacity of the location servers
along the signaling path, not the media path. My comments apply to this
definition. My argument was that the gateway capacity is generally much
less (in terms of calls it can handle) than an LS, so LS capacity was of
little value.

> Are there other services I am missing?

Most of the services you are talking about don't require the media to
flow through the LS. Certainly control over capability negotiation does
not (in H.323, gatekeeper routed H.245 is sufficient for this, and in
SIP a proxy could rewrite SDP if it felt it needed to, for some reason),
same with policy, security, accounting, and billing. QoS for the media
is handled by things like rsvp and diffserv, not the call signaling in
any case. For both gatekeeper routed signaling in H.323, and proxy
invite's in SIP, the media flows regularly between endpoints, not
through the gatekeepers or sip servers. Yet, people seem to be able to
bill, account, maintain control, etc. 

> routing protocol or a directory-based solution are sufficient for

I'm not so sure. We had lengthy discussions on this list regarding
directory services for GLP. It doesn't work. Many gateways can service a
particular number; the right one to use depends on the agreements
between providers. This kind of environment cannot be supported in a
global directory solution, like DNS. Your alternative, a single hop call
routing protocol, doesn't scale all that well. It would require gateway
providers to all have bilateral agreements with each other. Would you
advocate regular IP routing protocols that support only one hop?

-Jonathan R.

---------

---

From: "Hussein F. Salama" <[email-masked]>
Date: Fri, 26 Mar 1999 12:22:14 -0800

Jonathan Rosenberg wrote:
> same with policy, security, accounting, and billing. 

You're missing my point. Assume call signaling goes through an ingress
gateway in AD1, an intermediate signaling only proxy in AD2, and an
egress gateway in AD3. However, the media streams for that call do not
pass through AD2 at all. Assume the follow the path AD1-AD4-AD5-AD3.
Let's use H.323 as an example. The gatekeeper in AD1 may be interested
in controlling the capabilities because the ingress gateway is in its
domain and the media streams flow through that domain. Same thing
applies to the gatekeeper in the egress domain, AD3. But why would a
gatekeeper in AD2 care for being involved in, and routing this call? I
know it can, be I don't think it care. Since the layer 3 route doesn't
go through AD2.

What if the gatekeepers in AD4 and AD5 want to control the capabilities
(codec selection) for  above call? I think it's their right to do that
since the voice streams will ultimately flow through their domains.
Would they be able to do that? Not when separating signaling from media.

The same applies for accounting. What if the gatekeepers in AD4 and AD5
want to do accounting for  above call? I think it's their right to
account for voice traffic traversing their domain. Would they be able to
do that?

> QoS for the media
> any case. 

What if different intermediate domains on the media path of a call want
to provide different levels of QoS to same media stream? Let's use
RSVP/Intserv as an example. What if AD4 wants to provide controlled load
service for the audio streams while AD5 prefers to provide guaranteed
QoS?

> For both gatekeeper routed signaling in H.323, and proxy

See my above comment on accounting. So far people are doing accounting,
billing, ... etc at the ingress and egress domains only. This will
change as the volume of VoIP traffic increases.

> advocate regular IP routing protocols that support only one hop?

I didn't use "single hop call routing" in the right context.What I meant
"single hop inter domain call signaling." This can be done using either
the BGP-based GLP proposal or the SCSP-based proposal, and never
changing the NEXT_HOP attribute when an update is propagated from one
domain to another. The NEXT_HOP will always point directly to the egress
domain.

Hussein

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 26 Mar 1999 22:17:09 -0500

> know it can, be I don't think it care. Since the layer 3 route doesn't

A gatekeeper in AD2 would be interested since GLP effectively introduces
a "subcontracting relationship" among the various providers. AD1 allows
AD2 to use its gateways. By propagating this information to AD3, AD2 can
appear to be its own gateway provider, when in fact its using gateways
from AD1 to provide a more complete service. So, AD2 may want to see the
signaling messages for call accounting purposes.

Same situation arises in building a house. One big contractor interfaces
with you for the job, and they in turn subcontract some work out to
other contactors, who may further subcontract that out. Invoices for
work still pass through all of them, since they each provide the
value-add of "aggregation of service".

> Would they be able to do that? Not when separating signaling from media.

Well, this has not happened yet at all for any other IP application.
When I browse a web page, a hit a server in some domain AD1. I'm in AD2,
and I have a local proxy. The actual traffic flows through many
intermediate transit providers. To date, these providers have had no say
in whether I download the text or glitzy-image version of a page, or
whether I use gif or jpeg images. 

I do believe that an ISP should have control over what data leaves and
enters its network, but that this functionality lives at layer 3.
Diffserv and other things are how you control this. What you are
proposing requires us to overlay an independent network of proxies and
servers for every single application. One of the fundamental engineering
assumptions in the Internet is that it is application unaware, and that
apps live in the end systems. It is this model that has allowed new apps
(like the web) to come into being.

> account for voice traffic traversing their domain. Would they be able to

Accounting would be done in border routers (i.e., layer 3), using the
diffserv model. The voice traffic (or any other high priority, delay
sensitive traffic) would be marked at the ingress domain. Each border
router could account for the amount of this kind of traffic, and then
remark. So, you get the kind of accounting you want, but at layer 3.

> service for the audio streams while AD5 prefers to provide guaranteed

So, let them do it. Normally RSVP is used to ask for only one of the
two, but if for some reason a domain wanted to do something different,
it could perhaps rewrite the RSVP messages at the border routers, or
something like that. Certainly one domain can do diffserv, and another
rsvp. Check out draft-ietf-diffserv-rsvp. In either case, gatekeepers
and sip servers are not involved.

> change as the volume of VoIP traffic increases.

I agree we need accounting for voice traffic in intermediate domains.
Thats with diffserv border routers are for.

> domain to another. The NEXT_HOP will always point directly to the egress

I see, sorry for my misunderstanding. I think I address your point
already above. Intermediate LS's may want to be on the signaling path
for accounting (call usage, mind you, not voice level accounting). If
they don't want this, then you are correct. Single-hop signaling is just
fine. As I said, we have a perfectly nice underlying transport network
that allows us to go from anywhere to anywhere else.

-Jonathan R.

---------

---

From: Hussein F Salama <[email-masked]>
Date: Sun, 28 Mar 1999 00:11:43 -0800

> value-add of "aggregation of service".

Now I understand your model better.

> (like the web) to come into being.

I wish this assumption can hold across multiple administrative domains,
each applying its own policy, in the presence of real-time applications
which use dynamic ports.

> and sip servers are not involved.

A border routers can not decide on its own to rewrite the RSVP messages.
It is an application unaware layer 3 device. Some application has to
instruct the border router to do that. 

The good news is that, in spite of the different models we're
envisioning,  GLP does not care with the intermediate hops on a call
route are signaling-only proxies or are signaling+media proxies.

Hussein

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

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 28 Mar 1999 22:39:03 -0500

> route are signaling-only proxies or are signaling+media proxies.

This is true. However, the reason we came down this road was to address
the issue of the capacity metric. We have three definitions possible:

1. capacity of egress gateway
2. capacity of call signaling path (set of LS's signaling messages
touch)
3. capacity of advertisement path (set of LS's the GLP messages
traverse; a superset of 2)

If you believe that the media should flow through the LS, then (2) is
what you want. If you believe its just signaling, than (1) is what you
want.

In reality, its an artificial distinction. Nothing would actually
prevent an LS from modifying the capacity metric bceause it also acts as
one of these media proxies. So, my proposal is to define it as an egress
gateway capacity, in terms of total calls (or possibly density), and
define aggregation rules based on the assumption they don't reflect
signaling path capacity.

-Jonathan R.

---------

---

From: Douglas Clowes <[email-masked]>
Date: Mon, 29 Mar 1999 14:57:34 +1000

Actually, the metric seems to be, and should be, related to the capacity of
the mechanism which is being propagated.

This may change in meaning as it is propagated, increasing as aggregation
occurs, and decreasing if some other limit is introduced.

If an intermediate LS wants to aggregate three routes to 1-415* that have
capacity of 10, it should propagate a capacity of thirty. Since the three
routes have different signalling addresses, the aggregation should
introduce a common intermediate signalling entity, which can distribute the
requests among the three paths. If the interposed signalling entity has
unlimited call carrying capacity, the LS should propagate the aggregated
capacity of 30.

If an intermediate LS wants to introduce a signalling/media intermediary in
the path, which has a limitation of its own, then it should adjust the
metric to reflect that. If that signalling+media proxy has a carrying
capacity of 3 calls, then that should be the capacity that is propagated,
even though the gateways have greater capacity.

In one of the above, the capacity is 1 below, while in the other it is 2.
They're both valid.

BTW: can you aggregate without introducing an intermediate signalling address?

Douglas

---------

---

From: Hussein F Salama <[email-masked]>
Date: Sun, 28 Mar 1999 23:29:24 -0800

> In one of the above, the capacity is 1 below, while in the other it is 2.

But we have to agree on one of the two, because the capacity will be
propagated inter-domain.

> BTW: can you aggregate without introducing an intermediate signalling address?

Good point, I think an aggregator must change the next hop address.

Hussein

---------

---

From: Douglas Clowes <[email-masked]>
Date: Mon, 29 Mar 1999 22:35:50 +1000

>But we have to agree on one of the two, because the capacity will be

I don't think so, because it's still the capacity to carry calls. It's just
a different factor that's limiting that capacity. Whatever is determining
what the limitation is, has to determine what the resultant capacity is.

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 29 Mar 1999 10:39:27 -0500

> Good point, I think an aggregator must change the next hop address.

It must do so only if the prefixes it aggregates have different next
hops. In most cases this will be true, but not always.

-Jonathan R.

---------