Subject: RE: [IPTEL] the silence is deafening...

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 2 Oct 2001 10:17:59 -0400

My response sated below [RRR]:

-----Original Message-----
From: Henning G. Schulzrinne [mailto:[email-masked]]

"Roy, Radhika R, ALCTA" wrote:
> 
> Per Henning's suggestions, I am adding the following . . .
> 
> The common properties that all intra-ITAD (intra-domain) proposals need to
> have:
> 
> 1. A single protocol

I don't understand this requirement.

[RRR] For example, there are GWs and servers. The communications scenarios
are GW <-> Server and Server <-> Server. In all scenarios, it is better to
use the same protocol.

> 
> 2. Gateways can be Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs
(E.164,
> Email IDs, URL IDs)
> 
> 3. Communication environments for address resolutions: a. GWs <->
> (Location/Route) Server and b. (Location/Route) Server <->
(Location/Route)
> Server

This depends on a particular model of the world; I don't think that's a
given.

[RRR] A large network will consist of many GWs and servers. Therefore, it is
reasonable to have this kind of scenarios. Otherwise, it may be difficult to
manage the large network. For example, if there are many-to-many
communications relationship with every GW is communicating with every
server, it will complicate the process in managing the network. More over,
the needs for communications among the servers are not the same as of
communications among the GWs and server.

> 
> 4. Functionalities of the protocol needed: Discovery, Registration,
> Confirmation (and Selective Updates of addresses, and Keep-Alive messages,
> and Error-Notifications for efficiency reason).
> 
> 5. Scalability of the protocol (e.g., Multicasting using connectionless
> transport [e.g., UDP])
> 
> 6. Possible Extensions for Value-added features (e.g., capability
> negotiations, alternate peers for back-up, capacity, policy, QOS)

Just like for routing, depending on the complexity trade-offs, that may
not be the right one. There is a reason, after all, that not everyone is
running OSPF when router discovery is all you need.

[RRR] These are value-added features and will definitely increase the
complexity. However, the protocol may need to be flexible enough to
accommodate these if needed. For example, reliability is an important one to
have the back-up functional element. Therefore, a flexible protocol is
always useful.

> C. GW-SLP (W. Zhao, et al)
> 
> 1. The GW-SLP proposal extends the SLP protocol for discovery and
> registration, but there exists a many-to-many relationship between the
> gateways and servers. This may pose problems in managing the large
networks.

I don't see the problem. SLP commonly deals with many clients that need
resource information and with many services.

[RRR] The efficient communication scenarios are, as stated above, GW <->
Sever, and Sever <-> Server. So, the many-to-one and one-to-many seem to be
better as opposed to many-to-many scenarios. It may be noted that discovery
and registration are not the only requirements. The selective updates,
keep-alive, etc. are also needed.

> In ITRP proposal, it can be restricted such that a set of GWs can be
> communicating only with a single server.
> 
> 2. The GW-SLP proposal does not specify communications among the servers
> and, GWs are required to communicate with all servers using multicasting
if
> multiple servers are deployed. That is, a new protocol may be needed if
the
> server-to-server communications are required. (Both ITRP and GW-TRIP
provide
> mechanisms for server to server communications.)

That is bogus. DAs can communicate with each other, if that's the
architecture selected.

[RRR] Are you suggesting DAs will be using to perform selective updates,
keep-alive and others extending the SLP protocol?
If SLP can be extended to use in the communications scenarios GW <-> Server
and Server <-> Server and all requirements are met, it will serve one good
purpose - that is, one single protocol can be used for the intra-ITAD. Can
we see the proposal that meet all requirements?

> 
> 3. No mechanism is defined in the GW-SLP proposal if selective updates are
> needed because it is not efficient to send the register message again and
> again for simple updates.

I don't know what you mean by selective updates. You mean for individual
prefixes? SLP has partial updates, if really needed. (Based on
experience, it seems to be deprecated and little used in practice.)
Supported or not, my suspicion is that the complexity is not worth it,
given the issues of synchronization of new "listeners". In general, at
least in SIP (and RSVP, for another example), we have made the choice of
providing complete state information, rather than incremental state. How
large do you anticipate advertisements to be? Inside a network, is the
bandwidth efficiency an issue?

[RRR] The selective updates are very efficient. For example, many GWs will
be communicating to a single server. A GW may deal with 100s, 1000s of
addresses. If all GWs send their only the updated addresses, a sever only
needs to send only those updated addresses to all other servers. In this
way, there is an efficiency in communications.

> 
> 4. A server may also need to aggregate the address information and may
> require to send the same to all other servers and, there is a need for
> communication among the servers (as suggested in ITRP and TRIP-GW). In
> GW-SLP proposal, no protocol has been suggested for the server-to-server
> communications.

Bogus. See above. You can do whatever aggregation you want, if that's
necessary. Clearly, the aggregated version has to be distinguished (it's
a different "service"), but I don't see the protocol problem.

[RRR] It is about server to server communication part. A server will
aggregate and the same needs to sent to all other servers. Now, SLP proposal
needs to clarify how it will do this part. Are you suggesting that DAs will
do this meeting all requirements? Can the communications scenarios be
limited to many-to-one (e.g., GW <-> Server) and one-to-many (e.g., server
<-> Server) as appropriate? Will it also be possible to discover the GW(s)
by a server, should a server need to do so to serve a call in certain
circumstances?

> 
> The above note provides a brief summary of all proposals.
> 
> Comments will be appreciated.

[RRR] Will we be able to accommodate all requirements extending the SLP
protocol?

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 02 Oct 2001 11:06:27 -0400

"Roy, Radhika R, ALCTA" wrote:

> are GW <-> Server and Server <-> Server. In all scenarios, it is better to

Since you don't say what you mean by "server", I can't understand this
requirement. See my last note on architecture. Also, just stating "it is
better" is not particularly helpful.

> communications among the GWs and server.

Again, you state your assumptions as facts. This is not very helpful.

> have the back-up functional element. Therefore, a flexible protocol is

We all agree, in the abstract, that reliability and flexibility are
good, but I don't understand how this applies here. Just as a "for
instance", SLP supports redundancy for SAs, DAs and UAs, in various
meanings of the word redundancy. I'd be surprised if TRIPlite couldn't
do something similar.

> keep-alive, etc. are also needed.

Again, you state your assumptions as facts. Selective updates (by which
I assume you mean partial updates of some properties of a gateway) is
only useful if the volume of per-entity information is so high that a
complete update is not feasible. Absent of that, partial updates are not
desirable.

I have no idea why you believe that SLP doesn't support many-to-one or
one-to-many scenarios.

As I said before, SLP supports partial updates, if you really want them.
(I don't see the need in this case, but maybe you can show why each
update has tens of kilobytes of information.)

> keep-alive and others extending the SLP protocol?

I realize that this is a different WG, but we have been working with the
SLP WG on DA replication for about (I'm guessing) a year. This requires
only very modest changes to SLP DAs, and none to SAs or UAs. See
http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-10.txt

> way, there is an efficiency in communications.

I'm sorry, I just don't see how a gateway advertises 1000s of addresses
one at a time. Are you going to advertise each area code in the world
separately? Just like in TRIP, I would imagine that you do
longest-prefix-matching if you need to carve out special cases.

Realistically, I see gateways advertising the list of (maybe 30?)
7-digit prefixes (1212854, etc.) that are within local calling range,
maybe some regional calls and then a few dozen different international
groups, based on price similarity. But this assumes that the
advertisement includes cost; otherwise, the number of prefixes is much,
much smaller as they all look the same.

We seem to have very different views of how gateways work. Can you
explain your view?

> [RRR] It is about server to server communication part. A server will

Since you don't explain what you mean by "server" and we got tons of
different ones (UAS, proxy, various gateway location protocol servers,
depending on the specifics of the protocol, with at least two different
kinds in SLP), this is hard to discuss.

> [RRR] Will we be able to accommodate all requirements extending the SLP

Once the architecture(s) and requirements are clear, we can make
progress towards answering this, not just for SLP.

---

From: Weibin Zhao <[email-masked]>
Date: Tue, 2 Oct 2001 12:05:50 -0400 (EDT)

> http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-10.txt

Hello all,

I have been working with Prof. Henning on SLP DA (Directory Agent)
replication and other SLP enhancements. The current version of
slp-da-interaction is 12, so the link should be:
http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-12.txt.
This draft enhances SLP with a lightweight DA-to-DA (server-to-server)
protocol for propagating service registration information.

To use SLP for iptel-gwloc, we need to define a service template
for iptel gateway: a set of attributes. These attributes can be
defined as required or as optional. Now we are working on a new version
of the template specification. A sample of the template is as follows:

   ----------------------template begins here-----------------------

   template-type = iptel-gw

   template-version = 1.0

   template-description =
     The 'service:iptel-gw:' template describes the attributes
     supported by the Internet telephony gateway service.

   template-url-syntax =
   # service:iptel-gw://<hostname>:<port>

   total-capacity = integer
   # Total number of phone calls that can be supported by the gateway

   remaining-capacity = integer
   # Number of phone calls that can be further supported by the gateway

   prefix-list = string M L
   # A list of phone number prefixes that can be reached from the
   # gateway. Each phone number prefix MUST be an E.164 number prefix
   # without visual separators and without the "+" prefix.
   #
   # Grammar:
   #     prefix-list = prefix / prefix ',' prefix-list
   #     prefix      = 1*DIGIT
   #     DIGIT       = %x30-39
   #
   # Example:
   #     prefix-list = 1212,8610,4930
   #
   # where 1212 --- New York, NY, USA
   #       8610 --- Beijing, P.R.China
   #       4930 --- Berlin, Germany

   cost-list = string M L
   # A list of costs for reaching each phone number prefix defined in
   # the "prefix-list" attribute. The last element of this list may
   # use '*' to represent all unspecified prefixes. The cost is given
   # in a relative manner, no unit of cost is needed.
   #
   # Grammar:
   #     cost-list = cost-info / cost-info ',' cost-list
   #     cost-info = prefixes ':' cost
   #     prefixes  = prefix / '*'
   #     prefix    = 1*DIGIT
   #     cost      = 1*DIGIT
   #     DIGIT     = %x30-39
   #
   # In this "cost-list" attribute, prefix A MUST preceed prefix B if
   # A is more specific than B, e.g., 1212 MUST preceed 1.
   # To determine the cost for reaching a prefix, use the longest
   # matching for prefix.
   #
   # Example:
   #     cost-list = 1212:5,1:10,*:20
   #
   # where the costs are as follows:
   #               Prefix                              Unit of Cost
   #        1212 (New York, NY, USA)                         5
   #        1    (all other places in USA/Canada)           10
   #        *    (the rest of world except USA/Canada)      20

   -----------------------template ends here------------------------

One important issue is: what attributes are needed for whole gateway
(such as total-capacity, remaining-capacity), and what attributes are
needed for each phone number prefix (such as cost, ASR).

Comments are welcome, thanks.

-Weibin

---

From: Michael Hammer <[email-masked]>
Date: Tue, 02 Oct 2001 13:00:52 -0400

Small observation:  Are your units in U.S. dollars or
Deutsch Marks or Euros?

Mike

At 12:05 PM 10/2/2001 -0400, Weibin Zhao wrote:

On Tue, 2 Oct 2001, Henning G. Schulzrinne

Hello all,

This draft enhances SLP with a lightweight DA-to-DA
(server-to-server)

defined as required or as optional. Now we are working on a new
version

of the template specification. A sample of the template is as
follows:

----------------------template begins
here-----------------------

template-type = iptel-gw

template-version = 1.0

template-description =

The 'service:iptel-gw:' template describes the
attributes

supported by the Internet telephony gateway
service.

template-url-syntax =

total-capacity = integer

# Total number of phone calls that can be supported by the
gateway

# Number of phone calls that can be further supported by the
gateway

prefix-list = string M L

# A list of phone number prefixes that can be reached from
the

# gateway. Each phone number prefix MUST be an E.164 number
prefix

# without visual separators and without the "+"
prefix.

#

# Grammar:

#     prefix-list = prefix / prefix ','
prefix-list

#
prefix      = 1*DIGIT

#
DIGIT       = %x30-39

#

# Example:

#

#       8610 --- Beijing,
P.R.China

#       4930 --- Berlin,
Germany

cost-list = string M L

# A list of costs for reaching each phone number prefix
defined in

# the "prefix-list" attribute. The last element of
this list may

# use '*' to represent all unspecified prefixes. The cost is
given

#

# Grammar:

#     cost-list = cost-info / cost-info
',' cost-list

#     cost-info = prefixes ':'
cost

#     prefixes  = prefix /
'*'

#     prefix    =
1*DIGIT

#     cost
= 1*DIGIT

#     DIGIT     =
%x30-39

#

# In this "cost-list" attribute, prefix A MUST
preceed prefix B if

# A is more specific than B, e.g., 1212 MUST preceed
1.

# To determine the cost for reaching a prefix, use the
longest

# matching for prefix.

#

# Example:

#

#
Prefix
Unit of Cost

#        1212 (New York,
NY,
USA)
5

#
1    (all other places in
USA/Canada)
10

#
*    (the rest of world except
USA/Canada)      20

-----------------------template ends
here------------------------

One important issue is: what attributes are needed for whole
gateway

(such as total-capacity, remaining-capacity), and what attributes
are

-Weibin

IPTEL mailing list

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 02 Oct 2001 13:16:36 -0400

Michael Hammer wrote:
> 
> Small observation:  Are your units in U.S. dollars or Deutsch Marks or
> Euros?
> 

Columbia University laundry tokens, to be precise :-)

Clearly, as discussed in the TRIP case, anything having to do with cost
and prices is fraught with difficulties. I think there are two possible
approaches (besides ditching the parameter):

(1) Since the protocol under discussion is meant to be used within a
single ITAD, the ITAD presumably has a single accounting currency, which
is magically translated to whatever is appropriate (if anything) when
this is exported to the world at large via TRIP - after adding a
sufficient markup, taxes, license fees and shipping & handling,
naturally.

(2) Treat it like a cost or distance parameter in routing protocols,
where smaller is better, but there's no assumption that it related to
any physical unit, be it miles, milliseconds or dollars. (Or, similar to
the preference value in DNS SRV, to cite another similar example.)

Clearly, each ITAD can make this choice independently.

Again, this is probably a more generic discussion, independent of the
protocol chosen.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Michael Hammer <[email-masked]>
Date: Tue, 02 Oct 2001 13:50:01 -0400

Henning,

Sorry, but as an engineer, providing a measurement without defining the 
units is what leads to things hitting Mars rather than orbiting it.  I 
don't think it is a good idea to imply limits on the scope of an ITAD.  And 
if decisions are to be made based on cost, you can be sure the accountants 
will definitely want to know precisely what the cost is going to be when 
comparing data coming from two different gateways or ITADS.

Mike

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 02 Oct 2001 13:58:53 -0400

> comparing data coming from two different gateways or ITADS.

If somebody can point to a registry of currency symbols (preferably one
that includes Columbia laundry tokens...), this can certainly be added
as a parameter. If I remember past discussions correctly, this territory
is full of landmines, such as:

- what about more complicated charges (first minute costs X, second
minute costs Y, where Y < X or first minute is free);

- unit of charging (second, minute, 6 seconds, etc.)

- time-of-day dependencies (although these are less of an issue here
since the advertisements are updated periodically in all of the
protocols);

etc.

I'm agnostic here, but I suspect that without drawing pretty clear scope
boundaries, this can turn into a "tariff expression language", which I
don't think you'd want to engineer. That way also lie "restraint of
trade" and other nasty things that the IETF does its very best to stay
out of. (Basically, as soon as you specify anything specific that smacks
of business models, you're favoring Joe's model over Jane's model, which
may make Jane sufficiently unhappy to call a lawyer.)

SLP (and the other proposals) is extensible so that you can add cost
models appropriate for your customers. Then, if people don't like your
notion of how costs are computed, they'll complain to your marketing
folks, which I find preferable to talking to lawyers. (I'm not sure what
would happen if somebody were to simply describe a template or extension
as an informational RFC or IANA registration, without any blessing by
the IETF; I suspect that that is the right thing to do in this case, if
you want to go there.)
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Michael Hammer <[email-masked]>
Date: Tue, 02 Oct 2001 14:50:09 -0400

Henning,

I think I remember reading an Open Settlement Protocol (OSP) document that 
had some elements defined in XML.  But, as you point out this would be much 
like the calendar discussion.

Perhaps we could have an equivalent to the APR based on a 3-minute hold 
time.  Likewise, to placate the lawyers, we should have a memo field in 
which we can put all sorts of disclaimers using a very small font size. :-)

Mike