Michael Shields writes:
Despite preductions, very few resources have ever actually become "too
cheap to meter".
Television? Local phone service in many places? Matchbooks? Sewer
service?
Can you back up your comment about metering requiring three times the
current CPU capacity of routers?
It wasn't my comment, but I'll point out that routers are NOT in
general built for this task. Indeed, getting them to do what they were
built for is usually hard enough...
Perry
Michael Shields writes:
> Despite preductions, very few resources have ever actually become "too
> cheap to meter".Television?
A broadcast medium with no mechanism for measurement without additional
hardware. There are also pay-per-view events which are certainly metered.
Local phone service in many places?
And the phone company most definitely wants you to switch to metered
local service. That's why they offer additional calling areas for people
that switch to area calling. The stumbling block is that traditionally
it was unmetered because the old switches had no mechanism to measure it.
Matchbooks?
If i go to Walmart to get matches, they are most definitely metered. Just
because some places give them away for promotion doesn't mean they are free
any more than caps and T-shirts are free.
Sewer service?
Don't know where you are from, but I pay for sewage based on consumption.
They don't measure the sewage, but assume it is proportional to water usage.
John Tamplin Traveller Information Services
jat@Traveller.COM 2104 West Ferry Way
205/883-4233x7007 Huntsville, AL 35801
Michael Shields wrote:
> Perry E. Metzinger wrote ...
Can you back up your comment about metering requiring three times the
current CPU capacity of routers?
As a router manufacturer i can assure you that keeping detailed
transfer records at today backbone's speeds is totally infeasible.
(I do not say impossible, but the equipment capable of doing that
doesn't exist, and would cost _at least_ two orders of magnitude
more than conventional routers).
Of course, someone may come up with schemes like the "cost counter"
in the packets, but why bother?
By and large the economic case for fine grained distance-sensitive
Internet service is non-existent.
--vadim
PS If anyone wonders where i got cost estimate consider that full
OC-12c produces about 250kpps, or about 25k flows/sec. That
produces
storage requirement at 0.5Mb / sec, or 43Gb / day. For any
reasonable
billing one have to keep records for at least a year.
> Michael Shields writes:
> > Despite preductions, very few resources have ever actually become "too
> > cheap to meter".
> Television?A broadcast medium with no mechanism for measurement without additional
hardware. There are also pay-per-view events which are certainly metered.
Cable TV is unmetered, although pay. You may pay premiums for tiers,
but it's worthy of note in our context here that Pay per View does in
fact require a significant inventment in smarter hardware on the part
of the cable provider.
And the phone company most definitely wants you to switch to metered
local service. That's why they offer additional calling areas for people
that switch to area calling. The stumbling block is that traditionally
it was unmetered because the old switches had no mechanism to measure it.
Not quite true. It has been the case for years that local switches
could measure this if the LEC wanted to. It really does cost money to
keep track, _and fight the arguments over minutiae that it engenders_.
> Sewer service?
Don't know where you are from, but I pay for sewage based on consumption.
They don't measure the sewage, but assume it is proportional to water usage.
Yeah, that's roughly how they do it here too. But this is a John
Levine question... 
Cheers,
-- jra
Oh. Then it's considerably worse than just "three times the CPU". Ok.
Thanks, Vadim. 
Cheers,
-- jra
Michael Shields writes:
> Despite preductions, very few resources have ever actually become "too
> cheap to meter".Television? Local phone service in many places? Matchbooks? Sewer
service?
Television's incremental cost of another viewer is zero, and always
has been. This is not a matter of being too cheap to meter.
Matchbooks are not given away in unlimited quantities.
I honestly have no idea how sewer service is priced, or how the US
came to have flat-rate local calling.
As a router manufacturer i can assure you that keeping detailed
transfer records at today backbone's speeds is totally infeasible.
Why would it need to be done at the backbone?
Isn't it possible to have a statistically valid sampling of packets
even at the highest speeds? You'd know better than I would. I hope
the answer is yes, because that is valuable data even if not used for
billing.
Michael Shields wrote:
> As a router manufacturer i can assure you that keeping detailed
> transfer records at today backbone's speeds is totally infeasible.Why would it need to be done at the backbone?
Because edges do not have information about the topology and
routing, and so cannot asses distance-sensitive charges.
Distance-insensitive per-bit charging is certainly feasible and
is being practiced by some ISPs (typically as "burstable" T-1
or T-3 service).
In fact, even those charges aren't likely to stand against close legal
scrunity. Example of a scenario of a rationale for action against
ISP X - they count received and transmitted packets on a user link.
Unfortunalely, they also count packets they didn't deliver due
to some packet loss in their backbone. Bingo - they charge
customers for service not provided. This is fraud, pure and simple.
Sorry if i gave the idea to lawyers...
Isn't it possible to have a statistically valid sampling of packets
even at the highest speeds?
Good luck doing billing based on statistical sampling.
You'd know better than I would. I hope
the answer is yes, because that is valuable data even if not used for
billing.
Yep, that is somewhat useful data. Fortunaltely, you do not need to
identify particular customers for the purposes of traffic engineering,
so the problem is much simpler.
Unfortunately, traffic matrices are rather useless in the
Internet world - because congestion control nicely compensates
for overloaded paths. I've seen T-3s getting introduced into
a not particularly overloaded-looking T-1 backbone, just to get
filled right away.
BTW, I have a (relatively) simple solution to the Internet traffic
engineering problem, but you'll have to sign an NDA if you want to
know it. I already have a long list of people who "forgot" to give
me any credit for things i invented.
--vadim
>
> Why would it need to be done at the backbone?Because edges do not have information about the topology and
routing, and so cannot asses distance-sensitive charges.
Since most of this distance stuff is being calculated by IP address or ASN,
why wouldn't the edge routers have SRC IP, DST IP, and "MY IP." And why
couldn't a collector make any other adjustments necessary?
Distance-insensitive per-bit charging is certainly feasible and
is being practiced by some ISPs (typically as "burstable" T-1
or T-3 service).In fact, even those charges aren't likely to stand against close legal
scrunity. Example of a scenario of a rationale for action against
ISP X - they count received and transmitted packets on a user link.
Unfortunalely, they also count packets they didn't deliver due
to some packet loss in their backbone. Bingo - they charge
customers for service not provided. This is fraud, pure and simple.
Sorry if i gave the idea to lawyers...
A lot of people like the word fraud. I am not sure many ISP contracts
guarantee delivery of packets to their final destination, but most seem
to say that the burstable rate is based on how many packets enter your
connection port, or "enter the ISP's backbone." Even service level
agreements are generally based on link loss to the customer and not
end-to-end backbone loss.
Anyone who opens themselves up for loss inside a backbone is hiring the
wrong set of attorneys. IMO.
>
> Isn't it possible to have a statistically valid sampling of packets
> even at the highest speeds?Good luck doing billing based on statistical sampling.
Hello, Netflow?
-Deepak.
Some crystal ball gazing...
I expect to see an amount of distance billing in the future, but only
alongside QoS billing, for example.
Email - Non urgent, low traffic - I would expect this to remain flat rate
(i.e. Free with connection). As with browsing traffic etc. Caches will
add an intersting factor to this model, e.g Retrieving files from the ISP's
local cache - (Free with connection), Retrieving from distant locations,
perhaps dependant on time of day etc.
Voice over IP - This is starting to get bandwidth and delay sensitive
dependant on the efficiency of the Internet in the future, I expect this
might start to be billed dependant on distance/providers travelled over
etc. As otherwise if two ISP's do not directly connect or peer, an
intermediate ISP would have to carry this traffic. If this traffic
requires a high QoS, I would imagine the intermediate ISP would want to
charge for it.
Video over IP - When it comes around and end users via their xDSL
connections want to receive 1.5Mbs of video traffic - I can see definate
costs being incurred. Of course multicast techniques, caching etc will
make this not a geographical distance based pricing model, but a pricing
model will surely evolve.
Of course this argument of carrying others traffic applies to peering also,
if two ISP's peer a similar amount of data, no problem, but if it is one
sided then billing would have to occur. In other words, we will all buy
and sell our connectivity to each other.
One thing this state of affairs would lead to if it occurs is some scope
for very interesting pricing models, value adds etc.
A topic measured earlier was the ratio between payroll/equipment costs vs
line costs. The ratio of this will depend on the model of the ISP. A
dialup provider will incurr much higher support costs for a much smaller
bandwidth than a transit/backbone provider, which the line costs would be
expected to be the majority of their costs.
... Perhaps a bit more than 2 cents...
Julian Rose
Some crystal ball gazing...
Those who peer too much, into crystal balls, often eat glass <grin>.
I expect to see an amount of distance billing in the future, but only
alongside QoS billing, for example.Email - Non urgent, low traffic - I would expect this to remain flat rate
(i.e. Free with connection). As with browsing traffic etc. Caches will
add an intersting factor to this model, e.g Retrieving files from the ISP's
local cache - (Free with connection), Retrieving from distant locations,
perhaps dependant on time of day etc.
Why would there be a difference? On one hand, ISP disk capacity is used and
OTOH ISP band-width is used. These days, about the same cost. Besides, it's
second-order effect anyway and the market won't stand-still for it.
Voice over IP - This is starting to get bandwidth and delay sensitive
dependant on the efficiency of the Internet in the future, I expect this
might start to be billed dependant on distance/providers travelled over
etc. As otherwise if two ISP's do not directly connect or peer, an
intermediate ISP would have to carry this traffic. If this traffic
requires a high QoS, I would imagine the intermediate ISP would want to
charge for it.
Does that "Intermediate ISP" include such as MAE-WEST? They're already
charging for it, have you seen NAP bandwidth prices lately?
Video over IP - When it comes around and end users via their xDSL
connections want to receive 1.5Mbs of video traffic - I can see definate
costs being incurred. Of course multicast techniques, caching etc will
make this not a geographical distance based pricing model, but a pricing
model will surely evolve.
Until we get decent bandwidth at the end-user site, this simply won't
happen. Modem connections barely support Voice-over-IP. I mean a
preponderance of end-users must have sufficient direct band-width to make
them a decent market. Even when this does happen, they won't want to use it
for video. A classic is the MCI commercial where that gal was telecommuting
(bath-robing at noon), the last thing such would want is a video-based
conference. Been there, doing that.
Of course this argument of carrying others traffic applies to peering also,
if two ISP's peer a similar amount of data, no problem, but if it is one
sided then billing would have to occur. In other words, we will all buy
and sell our connectivity to each other.One thing this state of affairs would lead to if it occurs is some scope
for very interesting pricing models, value adds etc.
I don't think so. We have had remarkable lack of success in moving away
from the flat-rate pricing model, in the face of competition. Customers
want predictable bills. Volume based billing will not give them this.
However, they are more than willing to pay higher flat-rate costs, if there
is value-add.