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

From: Alok Mittal <[email-masked]>
Date: Mon, 22 Feb 1999 09:28:08 -0000

Hi Matt,

  Some comments/suggestions:

5.1.2 Hello Phase -- the heading number should be 5.1.1 -- It might be 
	useful to have a version number, may be to indicate what kind
	of attributes might be expected of the other end -- this also brings
	me to another point, whether we actually need to make some of
	the attributes mandatory in the sense of being able to make some
	call routing decisions.
5.2 -- Using a network layer identifier (IP address) for an essentially 
	application level protocol might cause problems in other networks.
	Can we just define the semantics of the id as being locally unique,
	and suggest that one possible way of doing it on IP networks is to
	use the IP address? Or use some other network-independent
	formation?
5.2.2 -- For the Telephone number range, another useful way to express
	it might be a prefix -- so if it says +9191, then the node handles
	all numbers starting from +9191 -- I understand that this can be
	expressed in current range format, but that will unnecessarily 
	increase message size, and comparison complexity -- especially
	since in this case the high end number has to be completely
	specified (such as +919199999999999) owing to inclusive limits
	on both lower and upper bounds. This could be done also by 
	just using len(Upper Bound) to be 0.
5.2.3.1 -- In the sig-proto-id, it is useful to have a version number along with
	protocol name, as this is likely to be important in selection decisions.
5.2.3.2 -- This is kinda generic -- Having pricing information in glp is 
	encapsulating not the application requirements, but the business
	requirements that probably form another higher layer from a 
	protocol standpoint. Business rules are likely to be based on more
	than just the price, and even the price may be different for each
	business relationship. As such, if we can replace this by some
	cost measure, then that might serve the application protocol 
	semantics better.

Best Regards
Alok
-----------------------------------------------------------------
Alok Mittal	
Technical Leader,	Hughes Software Systems
Prestige Opal, 146 Infantry Road, Bangalore - 560001
Tel: +91-80-2286390,91,92	Fax: +91-80-2286393
-----------------------------------------------------------------

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

---

From: Matt Squire <[email-masked]>
Date: Mon, 22 Feb 1999 08:50:42 -0500

Alok - 

Thanks for all of the comments.  My responses are included below.  

>	the attributes mandatory in the sense of being able to make some

I agree that some kind of version/feature exchange is desireable.  I'm
currently working with one of the SCSP authors to determine the best way to
address this.  

In Section 5 I somewhat address the mandatory nature of attributes, but not
completely, and probably not clearly enough. 

Within the individual sections describing each attribute, I tried to say if
particular attribute was required or had some limitation on the number of
times it could appear within a single call routing object.  Currently, the
only ones which I say 'must' be included are the TTL (to prevent unlimited
propagation) and the next hop provider (seemed logical that you would want
to know to whom you are sending your signalling messages).  So these are
'mandatory' in the sense that the must be included in each call routing
object.  

Now there's another interpretation of mandatory, and that is that the
receiver must be able to understand the attribute.  We could provide this
by having a flag in the attribute signify that if the receiver does not
understand the attribute, then the receiver must ignore the entire call
routing object.  We could take a bit from the type field as follows.  
  C - Compulsory.  Set to indicate that the receiver of this call routing
object should ignore the entire object if they do not understand this
attribute.  

There are alternate methods to get similar effects to the compulsory flag.
Specifically, we could use feature negotiation in the Hello Phase to
determine the set of attributes understood by each peer.  Using a
compulsory bit also implies that we'd need an error indication to let the
sender know that some attribute type is not understood.  

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?

>	use the IP address? Or use some other network-independent

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).  The
semantics of the IDs are that the sender/receiver/originator ID must be
unique with the server group.  It seems logical that we should define what
goes in the field in a way that guarantees this uniqueness criteria is
satisfied.  The IP address seemed like the easiest way.  This information
is certainly available to the application layer, so I didn't consider it
problematic (yet! see below).  

One of the Editor's notes in the draft asks if we need to apply GLP to
non-IPv4 networks (ie use more general address arguments).  I think we need
such generality.  If this is the consensus, then the use and specification
of the network address as the SCSP sender/receiver ID is not as clear.  In
this case, I agree that we should choose some other method of specifying
the IDs.  To guarantee uniqueness, I think we'd need a format like
ITAD:Server.  Since any provider controls only their machines, we'd need to
scope each server identifier with the provider identifier.  Each provider
can ensure uniqueness within their domain. 

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?  

>	just using len(Upper Bound) to be 0.

The first time I wrote this up, I used prefixes.  But then I generalized it
to a range, and for the life of me, I can't remember why.  

The range is certainly more general.  I wasn't worried about the comparison
complexity because in many (most?) cases, the decision will be
multi-attributed, so the complexity of a simple string comparison seemed
small compared to determining a server using the right protocols by the
right provider within a given price range ...  

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. 

>	protocol name, as this is likely to be important in selection decisions.

Good point.  I'll fix it.  

>	cost measure, then that might serve the application protocol 

The pricing attribute does encapsulate business and not application
requirements, but I think that's what people are after.  The pricing
attribute is a big black box as far as the protocol is concerned.  Its
specified that way because we can't set any limits on business
rules/practices.  The peer-to-peer nature of GLP would allow one to have
different pricing structures for different business relationships (ie peers). 

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.

- Matt  

---------

---

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

Hi Matt,

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. 

identifiers (I can't get to the IETF server to confirm right now).  
<snip>

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.

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

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

---------

---

From: Matt Squire <[email-masked]>
Date: Fri, 26 Feb 1999 09:44:35 -0500

At 10:43 AM 2/25/99 -0500, Jonathan Rosenberg wrote:
>Alok Mittal wrote:
>> 
>> Sorry for the lost indentations.
>> Hi Matt,
>> 
>On the other hand, I think marking the attributes is simpler, avoiding
>the need to define a specific capabilities exchange. 
>

The two approaches are not mutually exclusive.  

I think there should be version negotiation in the hello phase.  Other
features/attributes which must be agreed upon before two peers synchronize
should also be negotiated in the hello phase.  BGP has an I-D where
capabilities exhange is added to the OPEN message, and I think we should
have similar flexibility.  

Attributes could also be marked 'required', and if the attribute is not
understood by the peer then the entire routing object is ignored by the
peer.  

Including a list of attributes that an LS understands in the hello could be
used to reduce/eliminate the sending of 'required' attributes to a peer
that it does not understand.   This is just one of the ways to use hello
negotiation.  I think the up-front negotiation could be used to optimize,
but not replace, flagging individual attributes as 'required'.  

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

Although its not required for SCSP, I think we should at least pick a size
for the identifier in order to simplify packet processing.  Picking a
meaningful size requires some assumption about the content.  Larger
identifiers imply more overhead because every CSA/CallRoutingObject is
tagged with an identifier.  

Should the size/recommendation be based on:
  (a) internet address
  (b) mac address
  (c) domain:server
  (d) all/any of the above
  (e) others
  (f) variable length, unspecified content

Personally, I'd prefer to specify a 4-byte identifier with a recommendation
to use an IPv4 address or to set it administratively.  This ID is just has
to be unique withing the server group(s) that the LS is in, it doesn't have
to be globally unique.  

A more general possibility is to specify a 16-byte identifier.  A
recommendation could be to use 
  - ipv6 unicast addr
  - 0xff leading byte, 0x01 second byte, then all zeros, with ipv4 address
at end
  - 0xff leading byte, 0x02 second byte, then all zeros followed by mac
address at end
  - 0xff leading byte, 0x03 second byte, then some kind of ITAD:server
representation (yet to be determined)
  - 0xff leading byte, 0xff second byte, followed by anything you want (a
local problem to guarantee uniqueness)
But I think this is overkill.  

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

I agree.

- Matt

---------

---

From: Matt Squire <[email-masked]>
Date: Mon, 08 Mar 1999 16:28:30 -0500

I don't think we disagree (much).  My main point was that I think
aggregation is going to a royal pain, and that our choice of
representations shouldn't let 'easing aggregation algorithms' be a factor.
With multiple, onordered attributes, whether we use ascii or binary isn't
going make aggregation fun or easy, and probably won't have an impact on
the performance of aggregation.  

I also agree that when one writes an aggregation algorithm, it should be
general, ie apply at any reasonable boundry.  I'm not convinced that we
need to get into the bits, but I agree that any digit boundry is
reasonable.  A bit boundry would permit pairwise aggregation, which is
generally easier than performing aggregation over larger sets, but it just
seems so "wrong" to be looking at bits in phone numbers.  It might be
better, but it just seems weird.  

The efficiency of relative aggregation algorithms depends on many things,
but with the kinds of attributes that we're talking about, its not clear
(at least to me) that the cost of determining whether two objects are
capable of being aggregated is free.  As the cost of making this
determination goes up and the probability of its success goes down, it
becomes more attractive to shortcut the decision process by whether the
result is a reasonable prefix.  I'd consider this check to be an
optimization in a more general aggregation algorithm.  It could be an quick
way to cut-off potential wasted effort.  

But my main point was that aggregation isn't going to be optimal no matter
how we represent numbers, so let's try to optimize call routing decisions,
not aggregation algorithms.   

Didn't mean to get off on the wrong tangent. 

- Matt

At 03:19 PM 3/8/99 -0500, David R. Oran wrote:
>The major reason I would argue for general aggregation is so that the
>aggregator doesn't need to understand the semantics or assignment
>politics of telephone numbers. We once had such an aggregation scheme in
>the IP world (class-based addressing) and we didn't like where we wound
>up.
>
>Furthermore, semantics-blind aggregation is likely to wind up being
>simpler to both implement and administer (IMHO). The performance is
>likely to be as good or better as well, with data structures like
>level-compressed tries and the like.
>
>I'd make one exception to this principle. If there's a set of cases
>where the aggregator can be told a purported "hole" in a set of
>otherwise aggregatable prefixes isn't actually present somewhere, then
>the aggregator can do a much better job of coalescing parts of the
>address space. For example, if there's block of numbers like "+1-600"
>which are known not to exist then telling the aggregator this will allow
>for "+1-***" to be aggregated when otherwise it would be missed due to
>the hole.
>
>Dave.
>
>> -----Original Message-----
>> From: Matt Squire [mailto:[email-masked]]
>> Sent: Monday, March 08, 1999 3:00 PM
>> To: David R. Oran; Jonathan Rosenberg
>> Cc: Scott Petrack; Alok Mittal; iptel
>> Subject: RE: Comments on draft-ietf-iptel-glp-00.txt
>>
>>
>> At 08:27 AM 3/8/99 -0500, David R. Oran wrote:
>> >> > - 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).
>> >>
>> >> 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?
>> >>
>>
>> Planning for general aggregation is probably wasteful.  I'm
>> in area code
>> 919 in North Carolina.  Area code 920 is in Wisconsin, and 918 is in
>> Oklahoma.  I don't see that I'd be aggregating these together
>> unless I'm
>> aggregating all +1 numbers together.  I don't predict many
>> prefixes of the
>> form +1-9 or +1-91 being of any use, nor do I think many like
>> +1-919-9 are
>> of great value.  Writing code that goes and checks for
>> possible aggregation
>> at arbitrary bit/byte boundaries seems like a waste of time.
>> Phone numbers
>> are heirachical and based on groups of digits, we should plan for
>> aggregation along the same lines.
>>
>> So I don't think we should worry about how to make
>> aggregation easier when
>> we choose representations, we should optimize representations
>> for processing.
>>
>> - Matt
>>
>>
>>
>
>

---------