[LINK] Question: volume charges/interconnection and peering
bscott at gtlaw.com.au
bscott@gtlaw.com.au
Wed Nov 20 07:28:10 EST 2002
Kevin wrote:
> On Wed, 2002-11-20 at 15:16, bscott@gtlaw.com.au wrote:
>
> > presenting them as a flat rate. In my view carriers, if they were
honest,
> > would give a separate rate for domestically sourced content and a
separate
> > rate again for on net content (ie content from within their own
network).
> > Bunded prices do nothing to discipline the market to reflect the
underlying
> > costs (ie give people a disincentive to download international
content).
>
> The cost to develop a system that can actually count the different
> charges on traffic like that is often prohibitive. Telstra have enough
> trouble actually counting all their traffic, let alone differentiating.
I concede it's not a trivial problem. I have been told that Telstra offers
a bundled price because it's incapable of doing that differentiation.
However a solution only needs to be workable, not perfect... unless of
course Richard and his bananas are involved.
> Counting traffic in an ISP environment is a lot harder than you might
> think. For instance (to take a case from an ISP I used to work at), say
> I have two customers, and I want to count the traffic being delivered to
> each of them separately. I find out what IP numbers they're using, and
> I count the traffic to each IP number, and bill them accordingly.
>
> Now what happens if my two users get links to each other, and start
> dragging traffic down through each other? Do I still bill customer A
> even though I'm sending the traffic down customer B's link, and he's
> on-sending (and quite possibly charging) to customer A?
[snip]
This bit I don't follow. What is wrong with charging the recipient (R),
even if that recipient is onsending to someone else downstream (D)? This
will only be a problem if R gets a better rate than D. This, in turn, will
only be a problem if the rate that R gets is so bad that, taking into
account any cannabilisation of your own market from D you still can't turn
a profit. It seems more an actuarial problem than anything else. It does
present a bit of a challenge for offering discounted rate structures. Have
I misunderstood? Are you saying you're charging D?
I guess it can also be a problem where there's a cheap return path that
customers can utilise.
> it goes down). The customers, on top of all of that, probably expect to
> be billed for the traffic that goes down their link, not the traffic
> that enters my network destined for them - rightly so, those are two
> different things).
Why do you say "rightly so"? You're carrying something from A to B. Why
shouldn't you get a service charge from someone (perhaps not the ultimate
recipient) for that? Conversely why should you expect visibility of where
the data is ultimately destined for?
> > The final thing about volume based charges is that while charges remain
> > bundled and there are restrictons on home servers it is my view that
the
> > growth of broadband in Aus will be unnecessarily limited. Everyone but
> > everyone wants to communicate with their peers, but models which
attempt to
> > encourage this have been soundly ignored or actively stymied by
carriers.
>
> One of the funny ones which comes up periodically is that marketing
> people, by and large, dislike the idea that a business with two offices
> in a given city might get two low-rental-per-month accounts and do
> automated backups + VOIP between the two offices - basically run the
> pipes flat out and pay nothing for the privilege. Certainly, that sort
> of model is cheaper than buying dedicated lines between the offices off
> Telstra, if you can do it...
The limit on this is the upstream capacity on the low cost accounts, and
probably also the lack of support they come with and (now) useage caps. It
seems that the problem is that the low cost accounts are either being
charged too low or profit expectations are too high. It's a really good
example of the "no communication between peers" issue.
The view seems to be that there is a set level of data consumption and if
you start mucking around too much you'll simply cannabalise your market.
My belief (and I can't prove it) is that data consumption will increase as
limiters are removed. People won't pay so much for carriage, but they won't
be bothered to maintain their own networks so they'll get carriers to
manage them. I think overall telco $ spent will remain more or less the
same, but its apportionment will change, as will who is paying. In your
example what happens is that the offices simply don't take anything so
everyone is worse off.
In the ideal world carriers would price on the basis of carriage and
standardise that price . If they want to charge for value add, then add
that as a separate product offering on top of carriage, rather than
bundling the carriage with the value add into a product. I guess the
problem here is sensibly apportioning costs against carriage.
As a home user I want carriage that I can run a server off the back of. I
want a price which reflects the fact that it's not making a profit. If that
means I have a service which is poorly supported, or is subject to more
outages I'd prefer that to paying premium prices for products with support
and QoS which I won't use. If the carrier gets my community of interest on
their network they can get download charges from them.
Brendan
still my opinions
=======================================================================
This electronic mail is solely for the use of the addressee and may contain
information
which is confidential or privileged. If you receive this electronic mail
in error, please
delete it from your system immediately and notify the sender by electronic
mail or using
any of the following.
Brendan Scott
Lawyer
GILBERT + TOBIN Phone: +612 9263 4230
GPO Box 3810 Facsimile: +612 9263 4111
SYDNEY NSW 2001 Email: bscott@gtlaw.com.au
AUSTRALIA Website: http://www.gtlaw.com.au
Liability limited by the Solicitors Scheme approved under the Professional
Standards
Act 1994 (NSW).
=======================================================================
More information about the Link
mailing list