Subject: data issue 5: price/cost

From: Matt Squire <[email-masked]>
Date: Thu, 11 Mar 1999 22:58:19 -0500

5) Price/cost.

We all agree that we need to somehow represent the cost of making a call to
a particular destination at a particular gateway.  The more difficult
question is how.

a) Can we define a set of cost primitives to sufficiently represent pricing
structures?  
b) If so, what are they?
c) If not, what then?

I believe that we had consensus at the last wg meeting that we would be
unable to determine a sufficient set of cost primitives to satisfy every
objective, and that satisfying a smaller subset of objectives was not
sufficient.  Which seemed to leave us under a few rocks and surrounded by
hard places.  

One option is to use an opaque (ie not necessarily understood by the
call-routers) attribute to express the cost of a call.  This would permit
arbitrary pricing structures to be expressed via something like a text
message or a URL.  This would be of great help to those that view GLP as
providing a service to the calling user to help them choose the 'cheapest'
gateway.  

In general, we all agreed that the cost of the IP segment of the call will
be negligible compared to the cost of the PSTN segment.   Since the effect
of the IP segment on price is deemed negligible, the fact the a call-router
cannot adjust the attribute is not too harmful.  Unfortunately, an opaque
attribute has significant impacts to aggregation and route selection.  If
the call-router does not understand the attribute, then it could not choose
the best route based on that attribute.  Also, routes with different prices
cannot be aggregated if the structure is not understood.    

Which brings us to a second option.  Even though we cannot agree on a set
of metrics that would be sufficient, a unitless metric can provide great
benefits.  Much like a unitless capacity, a unitless price metric would
permit comparisons of different routes based on a relative view of price.
The caller would not know the 'actual' price in terms of price/min etc, but
a unitless price would permit better aggregation and route selection.  As
with a unitless capacity, the set of providers within a ip telephony
confederation would have to coordinate the interpretation of the relative
metric between and within domains.  Since the protocol does not know how to
interpret the relative metric, it is difficult for the attribute to be
adjusted based on the cost of the IP path.  We could mandate that the
attribute (a) not be adjusted when propagated, or (b) make it a
configurable policy within GLP to increment this metric by x when
propagated.  

My personal belief is that we probably need both a pricing metric and a
pricing description.  For a pricing description, I suggest either a text
based message or a URL that can be used to describe a pricing structure.
To assist in aggretability, providers should use relatively few different
attributes (the attributes can be subtyped by provider and subtyped within
that) to describe their pricing structures, having each provide enough
information to be applicable at a number of gateways.  The intent of the
pricing description is that this attribute can be displayed to a user (or
interpreted by some process on behalf of an end-user) when/if the user
accesses the call routing database via some front-end protocol, and that
the information fairly accurately reflects what the user will actually pay
for the call.  A URL could be used to handle large amounts of data in a
language independent manner.  This information would not be modified by the
call-routers, only propagated so that the ingress can get an idea of how
much a call is going to cost.  The information reflects only the cost on
the PSTN side and nothing on the IP side.  
Additionally, there should be a pricing metric that can be used and
modified by the routers in route selection and aggregation.  

I think the combination of the two can provide both network and end-user
information for gateway selection.  

If we agree that a pricing description is needed, I would further suggest
that it be signed by the orginator of the information using a public-key
method.  Since people may be making decision based on this data, it should
be authenticated so that people have some reason to trust its validity.

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

---

From: "Stephen Thomas" <[email-masked]>
Date: Tue, 16 Mar 1999 20:43:35 -0500

Sorry for getting this out after the meeting, but I'm just now clearing
my inbox. But then again, we didn't get to discuss this in the meeting
anyway. Comments below.

-----Original Message-----
From: Matt Squire <[email-masked]>
To: IPTEL IETF Mailing List <[email-masked]>
Date: Friday, 12 March 1999 7:09 PM
Subject: data issue 5: price/cost

|5) Price/cost.
|
|We all agree that we need to somehow represent the cost of making a call to
|a particular destination at a particular gateway.  The more difficult
|question is how.
|
|a) Can we define a set of cost primitives to sufficiently represent pricing
|structures?
|b) If so, what are they?
|c) If not, what then?
|
|I believe that we had consensus at the last wg meeting that we would be
|unable to determine a sufficient set of cost primitives to satisfy every
|objective, and that satisfying a smaller subset of objectives was not
|sufficient.  Which seemed to leave us under a few rocks and surrounded by
|hard places.
|
|One option is to use an opaque (ie not necessarily understood by the
|call-routers) attribute to express the cost of a call.  This would permit
|arbitrary pricing structures to be expressed via something like a text
|message or a URL.  This would be of great help to those that view GLP as
|providing a service to the calling user to help them choose the 'cheapest'
|gateway.

Assuming that the model allows for gateway-to-gateway calls, it's worth
noting that in GW-to-GW calls the price charged to the calling user (by
that user's service provider) may well be completely independent of the
price charged to the originating service provider (by the terminating
service provider). Obviously, the terminating provider wants to express
its price and the originating service provider wants calls routed on
the basis of its cost. In that case GLP is not providing a service to
the calling user but rather to the call-router. As such, the price
attribute MUST be understandable by the call-router.

|In general, we all agreed that the cost of the IP segment of the call will
|be negligible compared to the cost of the PSTN segment.   Since the effect
|of the IP segment on price is deemed negligible, the fact the a call-router
|cannot adjust the attribute is not too harmful.  Unfortunately, an opaque
|attribute has significant impacts to aggregation and route selection.  If
|the call-router does not understand the attribute, then it could not choose
|the best route based on that attribute.  Also, routes with different prices
|cannot be aggregated if the structure is not understood.

I can see how price (with or without units) might aid route comparison,
but how does it help aggregation? (Possibly I'm being dense here and
someone will surely rescue me soon.) Isn't it true that "neighbor"
trees can only be aggregated if the price is identical. If for, example,
the prices for various prefixes are:

 +330*   $0.10      +331*   $0.10      +332*   $0.10      +333*   $0.10
 +334*   $0.10      +335*   $0.10      +336*   $0.10      +337*   $0.10
 +338*   $0.10      +339*   $0.10

then it may be possible (everything else being equal) to aggregate
those into a single prefix +33* at $0.10. But if even one of the original
prefixes has a price of, say, $0.11, then no aggregation is possible.
(Assuming prefixes rather than ranges for simplicity.)

Since we're talking about inter-domain gateway location here, I have
to ask what is the probability that two domains will charge the same
amount for "neighbor" trees? I suspect that probability is very low.

Is it maybe a question of my misunderstanding of the term "aggregation"
and what we're actually talking about here is the subsuming of a subtree
by a parent when the parent is of equal or better cost? (E.g. a
price of $0.05 for +3* would take priority over all of the above prefixes.)

|Which brings us to a second option.  Even though we cannot agree on a set
|of metrics that would be sufficient, a unitless metric can provide great
|benefits.  Much like a unitless capacity, a unitless price metric would
|permit comparisons of different routes based on a relative view of price.
|The caller would not know the 'actual' price in terms of price/min etc, but
|a unitless price would permit better aggregation and route selection. As
|with a unitless capacity, the set of providers within a ip telephony
|confederation would have to coordinate the interpretation of the relative
|metric between and within domains.  Since the protocol does not know how to
|interpret the relative metric, it is difficult for the attribute to be
|adjusted based on the cost of the IP path.  We could mandate that the
|attribute (a) not be adjusted when propagated, or (b) make it a
|configurable policy within GLP to increment this metric by x when
|propagated.

Admittedly it may be difficult to achieve politically, but I think
interoperability would be better served if we could agree at least
on a default, absolute interpretation for the price attribute and
perhaps allow confederations to choose to override this meaning
with their own interpetation. It might be helpful to have a flag
that signaled private interpretation. If, in the worst case, no
one ended up liking the default interpretation, the situation
would simply degenerate into the relative metric case.

To procede along these lines, the default interpretation would have
to include the following components in its definition.

  currency
  unit of measure: minutes, bits, packets, pages (for fax), etc.
  rounding increment: minute, second, etc.
  precise definition of start/stop events

Clearly specifying a single currency will be difficult politically,
but it is essential for comparison. You can't just say "convert
using standard currency exchange rates" because, (a) there is no
such thing as a standard exchange rate, and (b) most world
currencies are not (legally) freely traded. FWIW, GSM addressed
this problem by creating an artificial currency called "special
drawing rights" and the GSM MoU Association maintains exchange
rates for SDRs. Absent an equivalent organization to set exchange
rates, this approach seems impractical in our case.

As for the other components, I suggest that most service providers
would prefer to base their prices as closely as possible to their
costs, which means minutes rather than bits or packets. That does
require extra work in defining the rounding increment and start/stop
times (since time is continuous rather than discrete), but other
pricing schemes are likely to encounter more resistance.

Of course, this approach doesn't give providers nearly the flexibility
they have today, at least at the retail level. But, on the other hand,
there are some attributes of existing SCN retail pricing that make
predicting the cost in advance of the call (i.e. for route selection
or comparison) impossible. One example is MCI's $1 for the first 20
minutes and $0.10/minute thereafter. (If I'm remembering the ads
correctly.) I think we have to accept the fact that, at least for
the initial version of the protocol, we simply won't be able to deal
with these scenarios.

|My personal belief is that we probably need both a pricing metric and a
|pricing description.  For a pricing description, I suggest either a text
|based message or a URL that can be used to describe a pricing structure.
|To assist in aggretability, providers should use relatively few different
|attributes (the attributes can be subtyped by provider and subtyped within
|that) to describe their pricing structures, having each provide enough
|information to be applicable at a number of gateways. The intent of the
|pricing description is that this attribute can be displayed to a user (or
|interpreted by some process on behalf of an end-user) when/if the user
|accesses the call routing database via some front-end protocol, and that
|the information fairly accurately reflects what the user will actually pay
|for the call. A URL could be used to handle large amounts of data in a
|language independent manner.

I guess I'm still worried about the distinction between cost to the
end user and cost to the originating service provider. If the originating
service provider is making the choice, then the call-router is going
to have to interpret the attribute, not the user.

|This information would not be modified by the
|call-routers, only propagated so that the ingress can get an idea of how
|much a call is going to cost.  The information reflects only the cost on
|the PSTN side and nothing on the IP side.
|Additionally, there should be a pricing metric that can be used and
|modified by the routers in route selection and aggregation.
|
|I think the combination of the two can provide both network and end-user
|information for gateway selection.

Maybe now it's finally starting to sink into my feeble brain. (Or
maybe not?) By differentiating between network and end-user do you
mean to differentiate between calling parties that are using a
gateway (network) and calling parties that are using intelligent
devices such as SIP clients in their PC (end-user)? If that's
the case, then I might see the value in two different attributes.
One that's interpretable by call-routers and another that can
be presented to the end user. Of course, I wonder how many
terminating gateway operators are really going to price the
two differently. And, if they do, how long it will be before
some end-user pretends to be a gateway (or vice versa) in order
to get the most favorable pricing.

|If we agree that a pricing description is needed, I would further suggest
|that it be signed by the orginator of the information using a public-key
|method.  Since people may be making decision based on this data, it should
|be authenticated so that people have some reason to trust its validity.

Authentication is essential, but I think there is more to this than
simply signing the price attribute. Also important is what we might
call payment method. That also needs to be an (authenticated)
component of the attribute. For example, suppose Provider X has
bilateral peering agreements with Providers Y and Z, and relationships
with brokers (sometimes called "clearinghouses") A and B. Then
it really wants to advertise a price of N, but only if the originator
is provider Y or Z or if the originator is authorized by broker A
or B. (In reality, the price N will likely vary for each option.)
A LS belonging to provider W could take that information, determine,
for example, that although it wasn't Y or Z it did belong to a
common broker, say B, and should thus interpret the call price
accordingly. If we want to get into this in more detail, I would,
of course, be happy to elaborate.

Stephen

____________________________________________________________________

Stephen Thomas                                       +1 404 872 4745
TransNexus, Chief Technical Officer    [email-masked]
____________________________________________________________________

---------