RE: VOIP Peering Questions

["Steve Heap" <sheap@rfidexchange.com>]

Just one comment on the last section where Alex said he would take any price
as long as it was below a certain level - that is exactly how Arbinet works
- the buyer puts in the maximum price they are willing to pay for a
destination, and then the "trading Floor" matches that order with the
available sellers that are under that price and routes the traffic
accordingly. The buyer pays what the actual matched rate is - not what the
max price was. That matching is updated every four hours, and so it would be
feasible to sell US domestic, say, and adjust the price so that you got
traffic when you had spare capacity.

Steve

-----Original Message-----
From: owner-voip-peering@psg.com [mailto:owner-voip-peering@psg.com] On
Behalf Of John Todd
Sent: Thursday, June 03, 2004 3:35 AM
To: Alex Bligh
Cc: voip-peering@psg.com
Subject: Re: VOIP Peering Questions


At 9:11 AM +0100 6/2/04, Alex Bligh wrote:
>John,
>
>--On 02 June 2004 00:00 -0700 John Todd <jtodd@loligo.com> wrote:
>
>>I actually _do_ have someone working ~30 hours a week on TRIP, though 
>>he's making slow progress due to the nature of his experience.
>
>Interesting. Does TRIP as a protocol meet your design requirements?
>
>Specifically
>a) do you think you will have anyone to talk to?

While that may be a short-term practical response to _any_ new 
protocol, it is not a long-term valid argument against TRIP.  As I've 
said, the current methodology of typing in multi-page faxes, 
converting .xls files, and cutting and pasting from web sites only 
encourages VoIP islands to remain islands, and I think that I'd have 
a hard time finding people on this list who would disagree.

Every technology that is expected to work between administrative 
entities has the same problem of "who are the early adopters?"  I 
assert that some type of protocol is required, and it will be adopted 
as soon as it is implemented in a free (BSD-licensed) and 
easily-managed manner.

Your point is taken, though, in that many LD providers will probably 
fight against something that represents an erosion of their pricing 
model.  They may win by ignoring the protocol.  Too bad for all of 
us, then, except for those on this list who make their money out of 
overpriced termination fees.


>b) do you think that is a viable translation between metric minimization
>   and LCR decisions which are presumably taken not only on (financial)
>   cost minimization but also for QoS / policy reasons

I do not assert that TRIP's description in the RFC is sufficient to 
solve the problems I have to deal with right now.  However, 
extensions to the protocol could possibly be sufficient to solve 
those problems, so I continue looking at the spec.

I am not married to TRIP - I could really care less if we use TRIP, 
or if someone comes up with a dynamic XML-based solution, or 
something else.  TRIP exists as an RFC and even as a minimalist 
(non-usable) proof-of-concept code by the Vovida folks, and I have 
neither the time or the inclination to come up with a new protocol, 
so I've got someone dabbling in what currently exists.

>I say that because TRIP is, as I'm sure you are aware, very similar to 
>BGP. We have coded BGP stuff before, and would probably code TRIP stuff 
>if we thought it would be useful. So far I've yet to be convinced that 
>several hundreds of thousands of lines of code later we'd not be left 
>with just several hundreds of thousands of lines of code. But it's 
>quite possible my imagination didn't extend sufficiently far beyond my 
>near requirements.
>
>Alex

Using the "follow-the-money" method, here's what I see as the major 
issue for adoption: carriers are looking for any way possible to fill 
their networks with minutes.  To some degree, it doesn't matter how 
cheaply they sell those minutes (above some administrative floor) 
because any usage is better than zero usage, and as long as they can 
stay at some minimum traffic level then they can realize some income. 
However, the methods for telephony providers (at least, on my level) 
to inform each other as to what routes they have, and what the price 
is for those routes, remains a horribly manual and slow process.  I'm 
sure that there are termination providers who would (as an example) 
jump on the chance to somehow fill their 3am-6am usage trough by 
reducing prices to 30% of the normal rate.  Remember the days when 
there were multiple "rate tables" based on time of day?  We're just 
moving this from a predictive model where there was a discount on 
static timeframes for a rate to a reactive model where there is a 
discount/premium based on actual usage.

Of course, price transmission is only one feature of a dynamic 
telephony routing protocol, and possibly not the most important 
feature depending on your perspective.  Over time, the cost will 
become less important and the routing vector information will become 
more important.

To Duane's fears about "price fluctuation":  yes, that's exactly what 
I want.  I don't care what my outbound price is, as long as it's 
below some minimum I can configure.  Anything below that minimum is 
"gravy".  Is this not a desired result?  Are rapidly-reacting free 
markets a bad thing?

JT

--
To unsubscribe send a message to voip-peering-request@psg.com with the word
'unsubscribe' in a single line as the message text body. An archive is at
<http://psg.com/lists/voip-peering/>.


--
To unsubscribe send a message to voip-peering-request@psg.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.