More Sidgemore on per-bit pricing (fwd)
Vadim Antonov
> The argument about billing based on destination being very expensive is
> not entirely true. Whether on not they bill on this data, most any one
> planning a global IP backbone measures traffic distributions very
> carefully, not only for network engineering but also to understand the
> cost of business. The granularity required to bill on this data may
> have to improve -but it is not a big leap to make.
Generally speaking, it is impossible, because aggregation removes
information. I.e. the better aggregation is, the harder is to pinpoint
the exact location of the destination.
In other words, even destination-based charging (except very special
cases like ISP in the middle of nowhere connected by one wire to the
rest of the world) requires cooperation of many parties, since no
party has any accurate cost-of-transport information locally.
--vadim
Alex Bligh
>
(rather elegant piece of text removed)
>
> Why does then paying for many "information appliances" that tap into
> an "IP service pipe" in a similar fashion seem so outlandish ?
I don't disagree with much of what you have written, but playing
devil's advocate I think it *seems* outlandish to some because:
1. Ostrich-with-head-in-sand change-resistance is rife.
2. From a superficial point of view, it seems that the costs are not
usage sensitive. Tier 1 (whatever that mean) backbone's are building
network as fast as they can get OC-12s deployed / hire engineering staff
etc.; The planning process itself for (say) taking an OC-3 network to
an OC-12 network is not a short one, let alone the deployment. If you
have a small number of high bandwidth customers connected to one POP,
your costs of connecting a few customers who are guaranteed (by SLA) to
be able to get an DS-3 if they want it, but are billed at a rate of
(say) a few Mb/s, is the same(*) cost as connecting customers billed
for a flat rate DS-3. (*)=OK it may not be the same as usage based charging
may well give you a higher port speed contention ratio, but the point
here is with port speeds which are significant compared to backhaul speed,
there is a significant risk cost in not deploying sufficient backhaul to
cope with customer usage growth you can't predict due to not having a
large enough statistical sample to work with. If you sell at flat rate,
you can refuse or delay upgrades which would otherwise impare QoS to other
customers.
If you think about this in the context of any other good, so called
usage tariffing is actually a relatively simple derivative product. If
you are buying coal for a power station, you won't get a contract (or
not at a decent price), where you can have however much coal you can
physically get in trucks down the road at guaranteed price X, but you
can instead order none at all. Instead, you might commit to buying
Y amount of coal a month at price P per ton, have an option on amount Z
more per month at price Q per ton (where P<Q). In a traditional market
if you didn't misplanned, and didn't want X amount after all, you'd
either have to store it (and incur costs), return it (and incur costs)
or return it to the market at a possibly lower price (hence arbitrage).
The situation is *not* entirely similar to electricity. If electricity
was charged the way some providers charge per bit, I could order a power
line and normally be charged for 300W of continuous consumption with
no fixed charge. Then suddenly one day I could plug in a steelworks
with no prior warning, eat many megawatts, and expect the same supply to
work. If electricity was installed like this, you would have a huge
fixed cost per month. If there were only a few homes per smaller
substation, the fixed cost would be even greater (risk).
However, neither ISPs nor consumers have sufficiently (yet) analysed
the market to find out how this works. As you point out, every bit sent
is likely to have a different cost, depending not only on destination,
but on time of day too (think about the electricity example). If ISPs
can't work out how to charge eachother per bit for peering arrangements
(where, how, and to whom one offloads traffic in a peering context has
substantial cost based implications) how can we expect them to not only
develop realistic charging schemes for their customers, but also explain
them to a relatively immature market?
3. Fixed cost charging is popular with customers. Many customers do not
understand what they are buying. They do not understand the bandwidth (and
thus cost) implications of (say) changing their web sites. They are
frightened their bills might be astronomically increased by some
activity on the line which isn't benefiting them proportionately (i.e.
DoS attack, rogue employees etc. as opposed to extra web site hits,
more employees finding useful information from the net, whatever). And
the customer facing tools to analyse *why* bandwidth usage is what it
is are, at best, primative. We don't yet have a ready market in programs
to automatically recompress the .GIFs on your web site as JPEGs
prior to transmission (or whatever) to save bandwidth costs. When the
IT people (or whoever) attempt to get budget for their line internally,
a fixed cost is more easily justified to the relevant bean-counter.
An open-ended liability (which is what I've heard usage based charging
referred to as) is unpopular. The people posting to NANOG 'disagreeing'
with usage based charging are presumably merely voicing their
dissatisfaction
with it as a product offering.
4. The market will decide. Trite this may seem, but it's true. There are a
lot of products which are half way between pure per bit charging and
pure flat rate (you know this, CERFnet has at least one; I know this,
I buy them from you :-) ), and these are essentially first hacks at
a derivative market in bits (the way I see it). But just like derivatives,
they aren't yet especially comprehensible.
Awaiting cross-US bits to be listed with pork bellies...
--
Alex Bligh
GX Networks (formerly Xara Networks)
Bradley Reynolds
Two things:
1. When was the last time I billed a customer?
2. Perhaps we should create a list for those who
who want to investigate price discrimination and
global domination through telecom pricing/infrastructure
and leave the network operation to the operators?
(while there still are distinct networks to operate).
Vadim Antonov
>
> One could use something like MPLS to determine the Ingress and Egress
> points of the network if it had a robust enough MIB.
Goodbye scalability.
Please tell me what happens when a link carrying a million MPLS-ed
flows does flap.
--vadim
Paul Vixie
I can't. But scalability isn't important in the modern era. MPLS and to
some extent QOS are all intranet standards, and if they are ever applied to
the true universal Internet in an end to end way we'll see a pretty much
vertical rise in the complexity of things like BGP and record-route and
traceroute. No matter how bad an idea it seems like, the fact remains that
to push public data networking to the next level of functionality, vendors
and pundits and especially venture capitalists are deliberately waffling on
the definition and extent of the word "public."
Stateful internets are bad. Stateful intranets aren't so bad. The last
voice-over-IP story I heard was just a way to increase cost efficiency in
the last mile -- it wasn't an end-to-end thing. The one before that was
just to increase cost efficiency in a long distance carrier -- it wasn't
an end-to-end thing.
Vendors of both equipment and services are thinking of new technology in
terms of what it can do for large VPN-consumers or for networks which mostly
just move data for their own direct customers. And of course, most of the
so-called first tier expects there to just be one network in the endgame,
with all others as customers of it.
The people who, six years ago, yelled about NAT, and ten years ago, yelled
about firewalls, all because "internet" means "network of networks" and
anything which couldn't scale to universal end-to-enditude shouldn't be
used (and certainly not standardized!) probably had the unspoken worry
that we were headed for a "network of VPNs" or a "network of NAT clouds"
or a "network of its own customers".
I had to think my way through all of this in order to understand the last
batch of Internet industry investment analysis briefs I slogged through.
Nobody, anywhere, expects to see a million MPLS'd flows going over a single
link before 2004, and by that time, the problems will be very different from
today's.
--
Paul Vixie <pa...@vix.com>
Vadim Antonov
>
> > Please tell me what happens when a link carrying a million MPLS-ed
> > flows does flap.
>
> and the pain is felt by all.
Yep, and how much time does it take? (A: with simplistic oblivious VC
routing which was shown to produce absymally bad utilization in general
topologies it'll take O(N), optimal VC routing is NP-complete (i.e. at
least O(exp(N)); there's a number of heuristics working in polinomial
time). N here stands for number of end-points in the network.
For comparison, rerouting in per-hop routing network takes O(log N).
Yeah, MPLS may work in private networks; but assuming it'll be of any
use in public Internet backbones is a serious delusion. The only way
to make it work is to avoid dynamic rerouting by building a double-redundant
full mesh-like network (by mapping PVCs in SONET, for example).
That is exactly what telephone companies are doing for voice SVCs.
Unfortunately it also wastes at least 70% of useable bandwidth.
In other words, use SVCs of any kind - and if you want to build a large
reliable network, you're up to sacrificing most of your network's capacity.
_Not_ doing SVCs provides enough "spare" capacity to provide much better
quality of service to all customers.
(There's one mode of usage in MPLS, downstream demand tag allocation, which
is equivalent to destination-only forwarding; all it is doing is eliminating
IP address lookup. Which can easily be done in 1.5 memory reads on average;
so the "savings" here are not worth the additional complexity (and related
bugs) of a MPLS code. Another usage of MPLS in large networks is to
create arcane routing policies (for example, to circumvent "routing fish"),
but, frankly, i never had any problem of that kind which couldn't be fixed
with a length of wire and a crimp tool.)
MPLS shares one common property with ATM: it introduces a lot of complexity
which can be gainfully used only in places where traffic is not very large.
The complexity _always_ has a way of biting back, so the net result is
networks which are less manageable, software which has more bugs,
interesting failure modes and guaranteed employment for network consultants.
Which is all what that MPLS hype is about. This one will come to pass, too.
I guess many folks fogrot the Magic Rule Of Reliable Networking:
Keep It Simple, Stupid.
--vadim
Vadim Antonov
> > Goodbye scalability.
> >
> > Please tell me what happens when a link carrying a million MPLS-ed
> > flows does flap.
>
Let us agree to disagree.
The way i see the future, private networks will eventually give way
to universal public utility network. It will simply be cheap, fast and
reliable enough for most businesses.
Therefore, a relevant technology should be scalable.
--vadim
krishn...@my-dejanews.com
Bradley Reynolds <br...@qual.net> wrote:
> 2. Perhaps we should create a list for those who
> who want to investigate price discrimination and
> global domination through telecom pricing/infrastructure
> and leave the network operation to the operators?
> (while there still are distinct networks to operate).
Perhaps you might want to check our webforum at
http://www.infozech.com/forum.html.
Please be warned, this is a new forum and messages are
still coming. But the objective is to provide a forum for
discussing such billing and rating related issues for
telecom companies.
We welcome your posts there.
Best regards
Krishnan iyer
Infozech -- Software for Telecom Service Providers
D-30 Press Enclave, Saket, New Delhi 110017
Tel: 91-11-6283113, 6234664
91-11-6513757, 6863321 (after working hours)
kris...@infozech.com; http://www.infozech.com
____________________________________________
Free Telecom & Technology Newsletter: http://www.infozech.com/telcomine.html
To subscribe send a mail to n...@infozech.com
"Anything Telecom" discussion forum : http://www.infozech.com/forum.html
Your answer to any telecom queries.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own