Dead of the Net predicted GIF, at 11.
If you believe Business Week, August 26, "Above all
finacial incentives for investment must ome into line. Right now,
customers who pay a mere $20 a month, can blast the net with untold
megabytes of data, voice and video. Without usaged-based charges service
providers are called on to upgrade their infrastructure with no clear promise of a return on investment."
Under the section "Dirty Secret" "One dirty little secret is that most
phone calls and videoconferences ram their way past data transmissions
by using a bully of a communications method called UDP. Unlike the more
polite Transmission Control Protocol, TCP, which drops back
when it detects congestion, UDP continues at full speed, elbowing
ahead of TCP traffic. Yet UDP customers aren't paying anything extra for
their fast lane".
Sigh, you should see the section on peering. Its worse.
Its a good thing none of these journalist used the train, telegraph,
or telephone systems when they were growing at these extact same rates,
or we wouldn't have trains or telephones today. A little research
into the growth of the telephone network reveals very similar patterns.
Clue seems to be a conserved quanitity in the universe, such that
as the net gets lager the clue-denisty gets lower, thus causing
most of the problems we see today.
If only we had been able to get the Network Clue Transport Protocol
going in time.
OK, I will bite. What is wrong with this comparison of UDP with TCP? As
far as I can see the only error is that it implies incorrectly that UDP
traffic is not affected by congestion. But it is quite valid in the
statement that UDP will tend to crowd out TCP. (Except for short TCP
transmissions for which congestion control does not have time to take
effect.) Per megabyte of traffic, UDP will tend to cause more delay to
other traffic stream than will TCP. What am I overlooking?
Roger Bohn
P.S. Remember the flap 6 months ago when EUNet basically tried to ban
CuSeeMe for exactly this reason.
stuff omitted
this seems to reverberate with comments made just a few days
ago... About how, when services are delivered at a flat rate, the
provider's most fiscally responsible SOP is to run their network to as
close of a breaking point as possible. When services hit 100% resource
usage, there is no economic loss (aside from subscribers cancelling,
which I won't deal with here). If, on the other hand, services are
delivered at a metered rate, and there is demand that is greater than
the resources available, then the difference between that demand and
the available resources is potential revenue which is lost.
Unmetered usage develops an environment which puts some sort
of backpressure on the end user, to discourage or prevent the usage
of too much resource.
Metered usage develops an environment which *encourages*
resource use. You want to make more money, right? If you've ever
read Compuserve's subscriber magazine, they highlight many files they
*want* you to download. Why? Because they charged a metered rate,
and they made money on every download.
Think about it.
The journalist may be stupid, but the point has some merit.
Ed
Small factual correction: this was in fact well over a year ago (time
flies, huhh?:-), and an outright ban wasn't on the table; rather,
that users wanting to use realtime A/V applications should ask
first.
That aside, ill-behaved traffic will forever be a problem in whatever
network with whatever technology, etc, etc, no matter what is the
cause of the poor behaviour. The key issue is that things break if a
balanced interplay between networking technologies, devices, and
applications isn't maintained; consider eg the ethernet capture
effect as an example of a new slant on the problem.
There is a tendency to equate "TCP" with "well-behaved", which really
only is the case if the TCP implementation itself is good, and the
stream of some duration. In former times that was practically always
the case, but today's HTTP traffic, consisting of multiple
short-lived streams, is for most intents and purposes ill-behaved,
though nowhere near as dramatically as earlier versions of CU-SeeMe
(we're talking about a difference of 1-2 orders of magnitude).
When services hit 100% resource
usage, there is no economic loss (aside from subscribers cancelling,
which I won't deal with here).
This is pretty dumb! If you are going to talk about the economic systems
aspect of tier 1 providers then you have to include subscriber
cancellations and company reputation. Not to do so is roughly equivalent
to discussing why people should use Cisco 75xx boxes and saying something
like:
"aside from the 75xx's BGP features which I won't deal with here"
the resources available, then the difference between that demand and
the available resources is potential revenue which is lost.
In an economic system, lost revenue is lost revenue whether it comes from
subscriber cancellations or elsewhere.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
I take offense at your tone. Subscribers cancelling due to a
lack of resources is a drop in the bucket compared to other reasons, and
even despite cancellations, all ISP's are growing.
The point remains: flat rate systems will operate to discourage
resource use, metered rate systems will encourage resource use. When
was the last time AT&T suggested you *not* make that LD call?
Ed
The point remains: flat rate systems will operate to discourage
resource use, metered rate systems will encourage resource use. When
was the last time AT&T suggested you *not* make that LD call?
Who cares about AT&T? When was the last time that your spouse encouraged
you to make that LD call?
From the user viewpoint, flat-rates encourage resource use and metered
rates discourage it. This is widely found to be the case in the ISP
industry. The closer an ISP is to pure flat-rate pricing the more problems
they have with resource shortages, mainly dialup lines and modems but
sometimes server capacity and T1's if their flat-rate pricing extends to
server-based services like WWW servers.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
One dirty little secret is that most
phone calls and videoconferences ram their way past data transmissions
by using a bully of a communications method called UDP. Unlike the more
polite Transmission Control Protocol, TCP, which drops back
when it detects congestion, UDP continues at full speed, elbowing
ahead of TCP traffic.
Sigh, I guess you need to have part of your network shut down by the
above-described effect to appreciate just how unusually accurate a
portrayal that description is.
Its a good thing none of these journalist used the train, telegraph,
or telephone systems when they were growing at these extact same rates,
or we wouldn't have trains or telephones today. A little research
into the growth of the telephone network reveals very similar patterns.
What research into the growth of telephone, telegraph, and train
systems immediately reveals is usage-based pricing generating revenue
to pay for the infrastructure to handle the growing traffic. At the
net's edges a large portion of use is purchased with usage-based
pricing right now, where usage is measured by connect time for dialup
users and by data transfer for servers.
Clue seems to be a conserved quanitity in the universe, such that
as the net gets lager the clue-denisty gets lower, thus causing
most of the problems we see today.
The people with a clue are those who can tell the difference between
predicting the death of the net and predicting the end of the free
lunch.
What research into the growth of telephone, telegraph, and train
systems immediately reveals is usage-based pricing generating revenue
to pay for the infrastructure to handle the growing traffic.
It also reveals that pay-per-message (telegraph) is not as successful a
model as pay-per-month (telephone). The same things could be said about
trains (pay-per-trip) and cars (basically flat-rate). Of course neither
cars nor telephone are purely flat-rate models but then, neither is any
ISP that I am aware of.
The people with a clue are those who can tell the difference between
predicting the death of the net and predicting the end of the free
lunch.
The economic models of telephone systems are very complex and it is
difficult to figure out what true costs are to provide service. No doubt
this is because generations of telco employees have been working on
obfuscating the whole thing in order to justify the widespread use of
metered rates.
But one thing is certain. It costs more money to meter and to bill based
upon metering than it does to bill flat rates. Perhaps this is why the CEO
of Canada's largest telco conglomerate chose the following quote from an
economist article to open a recent talk
The significance of the issues in play was summed up as follows in a
major feature on telecommunications in the Economist last September
[1995]:
“ The death of distance as a determinant of the cost of communications
will probably be the single most important economic force shaping
society in the first half of the next century. It will alter the
decisions about where people live and work; concepts of national
borders; patterns of international trade. Its effects will be as
pervasive as those of the discovery of electricity.”
IMHO the phrase "death of distance" is another way of saying that the
current metered billing infrastructure collapses. And if this happens how
can we be sure that metering itself will survive? Already the costs of
billing are becoming close to 50% of a telco's expenses due to the
plummeting costs of switching gear and other hard goods used in
telecommunications. The best the future could hope for is that metering
survives alongside flat rates but only for higher quality services. This
could mean that metering is only found outside the public global Internet.
You can read the talk by Red Wilson of Bell Canada Enterprises and some
comments by an industry consultant at
http://www.angustel.ca/future/fut.html
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com