Subject: RE: Comments on draft-ietf-iptel-glp-00.txt

From: Alok Mittal <[email-masked]>
Date: Tue, 23 Feb 1999 13:51:17 -0000

Sorry for the lost indentations.
Hi Matt,

>So I agree that determining which attributes are understood by each peer is
>important.  I haven't yet decided if this function is better provided by
>negotiations during hello phase or by flags in the attribute.  Opinions?

To me it seems that this activity is best done in the negotiation so that a lot
of overhead is avoided if the peers are not compatible. The degree of control
offered by per-attribute control does not seem to be necessary. 

>I think that other applications of SCSP use similar information as their
>identifiers (I can't get to the IETF server to confirm right now).  
> <snip>
>But I can't specify this format until we figure out how we want to
>represent the Internet Telephony Administrative Domain.  Another Editor's
>note asks for opinions of how an ITAD should be represented (url, string,
>decimal, etc).  After we answer this question, I'll go back and re-specify
>what the SCSP identifiers should be.
>
>Does that sound reasonable?  

Yes, we could go with that approach. Or just to use what H.323 does for Call
Identifiers -- it specifies a 6 byte field within Call ID for "node" specifying that
it has to be spatially unique. The recommendation then suggests that ethernet
card address should be used, BUT if there is no netowork card, the system
may use other means to generate globally unique node identifier -- such as 
make least significant bit of first octet to 1 (refers to multicast so doesn't conflict
with any ethernet card addresses) and fill a 47 bit pseudo random number
elsewhere.

>I think the real question is whether a prefix is sufficient to specify the
>likely sets of target telephone numbers.  In the US, I think that a prefix
>is sufficient.  The proximity of area/city codes does not mean the
>proximity of areas/cities, which seems a likely criteria for a gateway
>serving 'range' but not a 'prefix'.  Is this common of phone numbering
>systems throughout the world?  If so, then I agree we should go with
>prefixes and not ranges. 

In India, again there is no strong correlation between the two, though in many
cases such a property may be satisfied.

>Its not clear to me what you mean by cost. Cost, to most routing protocols,
>is the number of hops.  But we don't really care about the number of
>signalling hops.  A couple weeks ago, there was something on the mailing
>list which enumerated many variables affecting the cost/price of an
>internet phone call.  So the meaning of cost is ambiguous at best.  
>
>If you have something specific that you mean by cost then let me know, but
>my view is that we can't do anything with real cost, and that we should
>stick to a black-box structure to express business practices and
>relationships.

Yes, I agree that this is a rather vague thing. To think of a cost metric at an 
application level, we could use the number of administrative domains through
which the shortest path to destination lies (from this gateway/signaling node).
This is based on an assumption that every administrative domain would charge
*some* fees for routing packets through its gateways. But this will lead to the 
problem of propagating this information, and it also makes a simplifying
assumption that cost of passing through each administrative domain is more
or less the same (or at least the difference is insignificant as compared to 
passing through an additional domain). Will think more and get back to you
if I have better suggestions!

Best Regards
Alok

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Feb 1999 10:43:09 -0500

> offered by per-attribute control does not seem to be necessary.

On the other hand, I think marking the attributes is simpler, avoiding
the need to define a specific capabilities exchange. 

> with any ethernet card addresses) and fill a 47 bit pseudo random number

I agree. Let implementations determine how to guarantee uniqueness, and
make some reccomendations in the draft.

> cases such a property may be satisfied.

The problem is that there is really no other scalable way to do it. In
an environment where the correlation between prefixes and geographical
regions (and more specifically, cost) is lost, there really is no easy
way to specify phone number ranges.

> if I have better suggestions!

I think we still need a pricing structure, opaque to GLP. We need a hop
count for TTL purposes already, and we have also discussed a capacity
metric. This would seem to provide a reasonably large enough set of
information for an LS to decide what to do with the routing object,
based on whatever total measure of "cost" it decides to define.

If there is additional cost for transit service, shouldn't this be
wrapped into the pricing attribute? An ITAD would simply modify the
pricing to include its own transit costs before propagating the
attribute, if it so chooses.

-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: Scott Petrack <[email-masked]>
Date: Wed, 03 Mar 1999 18:20:20 -0500

>way to specify phone number ranges.

Is an MGCP-style "digit map" string a practical matching pattern which is
more general than just a prefix? (I guess that I can see the problem with
using a general regular expression....).

---------

---

From: Douglas Clowes <[email-masked]>
Date: Fri, 05 Mar 1999 09:38:25 +1100

>way to specify phone number ranges.

Number prefixes is the way to go. However, there are a few things to note.

Cost is a significant factor to be considered, and that can vary in
pseudo-absurd ways. Number ranges can have holes in them, where cost varies
significantly. Take for example the US number range, prefixed by "1", where
"1800" and "1900" are significantly different to the broader range in which
they are contained.

Similar characteristics exist even within an area code where, in my
experience and opinion, strange thing can occur. Here, I am assuming that a
gateway is connected to a regular phone line, at a particular point in
space. Within one are code, calls to some exchanges are free, or fixed
price, while calls to other exchanges are toll calls. Similarly, sometimes
you can dial the seven digit number with or without the 1-area-code prefix,
while sometimes you must, and other times you must not dial it, when you
are in that area code.

Consider, for example, a corporation that has a directory number (say
1-616-555-1212) and have local operations in NYC, LAX and SFO. They want to
carry calls to that number on their private network, from their gateways in
those cities, and offer it for free. The gateways in SFO will offer "1-415"
for a price and "1-616-555-1212" for free, while the Michigan gateways
offer "1-616" for a price and "1-616-555-1212" for free.

A similar situation exists for 1-800 numbers, where the callee pays by the
distance of the caller from the destination. While all gateways will be
able to access the 1-800 number, there will be a preference for a gateway
closer to the point of termination. What should happen is that all the
gateways offer "1-800", while the gateway closest to the destination offers
"1-800-555-5000".

It can be suggested, that part of the requirement is to match the longest
prefix, at the lowest cost.

>> >stick to a black-box structure to express business practices and

One mas price is another man's cost.
 
>attribute, if it so chooses.

What cost is, depends on who you are. If you are the egress gateway
operator, your costs would include things like fixed costs (interest,
depreciation, rental of premises, lines and Internet connection) and
variable costs would include things like calls into the PSTN, bandwidth
charges on your Internet connection. The egress gateway operator would then
set a price, to cover costs and make a profit (unless they are buying
market share ...).

For the ingress gateway operator, or private caller, their costs include
the price charged by the egress gateway operator, their own equipment and
rental costs, and their bandwidth charges. Plus tax.

When I go looking for a gateway to terminate my call, all of my costs are
fixed, except the price charged by the egress gateway operator. Unless I
pay hugely different backbone bandwidth charges to different gateways,
egress gateway price is going to be the determinant of cost, and dwarf any
other cost variables.

The other issues come down to reachability, capacity, and QoS. In a "well
engineered" network, these will not matter. If we assume that they do
matter, then it is something that the call originator must determine.

I think that pricing must *not* be opaque to GLP, because it must aggregate
routes based on cost. Gateways will act as secondary alternates (and
tertiary, and quaternary, ...). Typically, they will reflect increasing
prices by their operators, because of increasing geographic distance
between the gateway and callee being reflected in increasing PSTN charges.

An LS outside your network can never know the reachability and QoS for a
gateway that is also outside your network. How can it possibly know that
your router is misconfigured and that gateway is unreachable from your
network, or that the link over the shortest path is overloaded - it can't.
Only the caller can ascertain the QoS on the link, and decide it doesn't
meet its requirements.

As for gateway capacity, it could be useful in weighting the decision, but
it will not be absolute. If there will be other LS giving out the same
information, an LS can't know about traffic from other LS. Since calls
don't all have the same statistical characteristics, load will not be
balanced by weighted round robin.

Again, in the end, the caller must make the determination. Take a list of
possible gateways, ordered by price (and then capacity), add your own
costs, go down the list trying each one. If you're not prepared to pay the
price/cost combination give up. If you are, check the QoS (ping, RSVP,
whatever), if that passes, try to connect, etc..

Douglas

---------

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 5 Mar 1999 15:58:27 -0500

The choice of prefixes and the destination descriptor was guided
primarily by two considerations:
 - The ability to use longest-match easily as a route discriminator.
Other destination descriptors don't necessarily have well defined
partial orders.
- The ability to do fairly strightforward route aggregation (of course
modulo the problems of multiple metrics and the lack of a totaly order
among them).

We seriously considered using regexps (some existing Cisco products do
just that) because of their power and generality, but it's quite
difficult to achieve the two characteristics above using them.

Dave.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Scott
> Petrack
> Sent: Wednesday, March 03, 1999 6:20 PM
> To: Jonathan Rosenberg; Alok Mittal
> Cc: 'Matt Squire'; [email-masked]'
> Subject: Re: Comments on draft-ietf-iptel-glp-00.txt
>
>
> >> In India, again there is no strong correlation between the
> two, though in
> >many

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 05 Mar 1999 16:15:08 -0500

> Other destination descriptors don't necessarily have well defined

Good point. 

> modulo the problems of multiple metrics and the lack of a totaly order

Actually even with prefixes, it seems hard. Basically - are the prefixes
expressed in terms of bits, or in terms of decimal numbers. Decimal is
more logical, but then to aggregate to +1-555, you must collect
+1-555-1, +1-555-2, +1-555-3, etc., which is 10 routes. If its done
bitwise, it only requires 2.

Thoughts?

-Jonathan R.

---------

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 8 Mar 1999 08:27:07 -0500

> bitwise, it only requires 2.
Well, if all phone numbers can be normalized to a "natural" length or
canonicalized into full 15 digit E.164 numbers, then you just convert
the number to binary and the bitwise scheme will work fine. Good idea.
One interesting question is wherhter to actually encode the numbers in
binary in the protocol. Whether this saves or wastes space depends on
whether you expect long or short prefixes. From a protocol debugging
point of view, sending strings wins.

---------

---

From: Scott Petrack <[email-masked]>
Date: Mon, 8 Mar 1999 12:21:22 -0500 (EST)

> point of view, sending strings wins.

Surely the processing time is more important than the space issue. I
realize that the packets don't need to be processed anywhere near line
speed, but a server that needs to process 1000s of phone calls will surely
benefit from not having to process the strings. 

Anyone who needs to debug can easily write a filter to translates the bits
into decimal.

Scott

---------

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 8 Mar 1999 15:07:25 -0500

> benefit from not having to process the strings.
These are in ROUTING messages, not SIGNALING messages. If we're sending
routing updates at anywhere near the signaling rate we're toast no
matter how things are encoded.

> Anyone who needs to debug can easily write a filter to
True, but this is a swamp I'm not going to wade into...

---------

---

From: Douglas Clowes <[email-masked]>
Date: Tue, 09 Mar 1999 10:33:11 +1100

Scott,

The big issue of text versus binary usually arises where the processing
domain and the transmission domain are potentially different. This is,
IMHO, not such a case.

The problem domain of mapping dialed digits, is not a numeric one, but a
string one. The processing needs to be done "in string", so the
transmission may as well be, to save the conversions that text transmission
usually involves.

While 49 and 50 are quite close in binary, they are very different in terms
of the digits dialed. Extending that thought, 599-9999 (5B8D7FH) might
represent something very close to 600-0000, in hex/ (5B8D80H) binary, but
they are very different as dialing strings.

Additionally, numerics are "right-centric", while strings (dialed digits)
are "left-centric". Here, 600 and 6000000 are very different numerically,
but map the same in a three digit string compare. That is, if 600 is the
template, and 6000000 is the dialed digits, they match.

You have to store them and process them as strings, you should transmit
them as strings, even in a binary protocol.

Regards,

Douglas

---------