Priority Pricing of Integrated Services Networks
Another author who looks to the growth of traffic in the future and predicts that demand will create congestion on the network (quote: "the Internet backbone is comprised of T1 and T3 lines"), overlooking the possibility that increasing demand for services will push the supply side to offer them.
EN: Since it's another variation on the same theme as the past four chapters, I'll skip all but the unique details of this proposal.
The Future of the Computer Networks
Worth mentioning: this author is a little better informed that the others, in that he doesn't see the internet as a chaotic cloud where signals travel at random over various wires, but an interconnection, such that the packets from a user to a server travel along the access provider's network to a point where they are handed off to the hosting provider's network.
He does, however, believe that "the receiving application waits until it has all the packets before presenting it [sic] to the user", which is a problem that has not existed for quite some time for most media.
He also indicates that service providers have networks of various qualities, and while there is general concern among the customer base (particularly business customers), there is not an existing grading system for networks: one must accept that advertising claim of a "high-quality network" or examine a cryptic topography diagram that backs such a claim.
Priority-Pricing Approach
The author suggests a pricing approach that would be based on priority: it is possible for a network service provider to configure its routers to give priority to traffic to and/or from certain IP addresses, and a model suggests a four-tiered approach that sets different price points for customers who would pay a premium to have their traffic routed first.
This can be done as a set-price, but would be more accurate if it could be metered to provide near-optimal prices in real time (such that a customer who sends data at night will pay for his prioritization only when he needs it, not during the hours of the day when priority access is not critical).
EN: This is possible, and is even in practice on internal networks (such that data among critical business systems takes precedence over employee e-mail). However, it may suffer from the weakest link: a hosting provider can pay for high-priority access to his systems, but there will be a hand-off to an access provider whose customer may have gone the cheap route, and as the user does not distinguish between the legs of his connection, his perception will be that the access is not appreciably faster than the slowest part of the route.
Iterative Price Computation and the Simulation Model
The author provides rather a complex equation for calculations, which I'll skip, except to suggest that it provides a ratio that accounts for the supply of and demand for priority service at any given instance, and uses this as a method of adjusting a basic price.
Fundamentally, a customer would pay a premium rate for priority service at times when the network is most congested, but a standard (or discounted) rate for priority service at times where congestion is low.
One problem he finds is that there would be a bottleneck effect: where packets "back up" at a given router, it will take time to clear them, such that the flow rate through that router would remain high for a period of time after network congestion has otherwise died down.
The net result would be premium pricing to the consumer, with no incentive for the supplier to invest in infrastructure to break up the congestion (in fact, since he is being paid more for congestion, it is in his interest to allow the congestion to perpetuate). This would only be offset by competition among suppliers: to offer the same level of service at a lower price point, a provider would need to manage his supply of bandwidth to consumers.
EN: One problem with supply-and-demand working in this manner is the incremental nature of supply (bandwidth is purchased in chunks) as well as demand (in many instances, the cost of switching is prohibitive).
Simulation Results
The author ran a mathematical simulation to test the performance of his model against other pricing schemes, and found that it delivered a better net benefit per unit value that other models.
EN: This happens all too frequently: a mathematical test proves the validity of a mathematical model. I categorically dismiss such nonsense.
Implementation Issues
The author describes some of the applications that would need to be developed to implement a system that would monitor network usage, control the prioritization of traffic, and collect the information needed to implement priority-based pricing to consumers. It's interesting, and fairly good thinking, but ultimately moot.