[LINK] Question: volume charges/interconnection and peering

[KevinL]

On Wed, 2002-11-20 at 17:28, bscott@gtlaw.com.au wrote:
> 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.

But if it's not accurate or correct, then all hell breaks loose.

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

Customer A owns IP 10.1.1.1
Customer B owns IP 203.20.99.1

Customer A's traffic gets charged to customer A, B's to B, no problem. 
But what if traffic to 10.1.1.1 (A) starts going down the pipe to
Customer B (because B has asked it be routed that way, via BGP which
doesn't involve your billing system directly but is a lower-level
protocol)?  You need to charge B - but you're allocating traffic based
on the ownership of the IP's, and A still owns that IP.  You can't bill
based on what actually goes down the pipes, because the hardware sitting
at that point in the network won't let you break the traffic down based
on IP numbers (and you can't scale like that anyway - too many
collection points).

The proper solution is to build something that includes BGP, and various
other things - but I was trying to display that it's a non-trivial
thing, and that the return on investment is negligible for most
organisations - people won't pay more to have their traffic
differentiated, if anything they want the supplier to put the effort in
so they can pay _less_.

(and yes, the differentiation in the example is not the differentiation
you were discussing - but the principles apply)

I may not be doing a good job of explaining it - there's a lot of
complexity here, and being a techie I'm not good at explaining in real
people-speak.  The crux of it is that what you're asking for is
technically difficult, and there's no market justification for it. 
Unless people are willing to pay extra for that level of detail, it
won't appear.  From what I've seen, people generally demand simpler
bills, not more complex ones - flat rate, not price-per-region-per-Mb
(let alone peak vs. off-peak ;)

> I guess it can also be a problem where there's a cheap return path that
> customers can utilise.

Hehe.  Doing all this in both directions simply adds to the complexity.

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

Um.  I was trying to demonstrate that in attempting to differentiate
traffic, you can open yourself up to other problems - for instance, once
you stop measuring "bulk amount down the pipe" and start trying to
assign IP's to people, you open yourself up to people re-routing under
you, and you charging the wrong person.  That becomes apparent when your
customer asks why you've billed them for all this traffic, but haven't
delivered any down their pipe by their measurements - at which point,
you get into a "compare measurement systems, pick the flaws" situation.

It's one of those things that, if you do it half-way, it's easy but
wrong.  To get it right requires a lot more time and effort than is
sometimes apparent at the start of the process.

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

No disagreement.

KJL