face Processor) interfaces, and the "knobs" seem insufficient. However, RED clearly works to improve customer line utilization. We therefore want to deploy it on all lines that see non-zero average queue lengths and drops.
Ebone's engineering policy is to ensure that bandwidth contention in normal circumstances only happens at the edges (i.e., the customer connections all can be full and the average queue lengths in the networks will be very near zero).
Ebone is therefore QoS-transparent in normal circumstances - but what about abnormal circumstances? We obviously try to minimize these through overcapacity and redundant topology, but things do tend to fail. When they fail, there is a chance that aver age queue lengths will grow until RED can shrink them. However, at this point QoS becomes practicable for the duration of the fault.
Does practicable mean useful? We don't know yet, and it is probably more useful for us to solve a bigger problem.
Ebone's biggest service problem is not quality (we do a good job) but price: we are hideously expensive (about 200k$/1Mbps/year).
The price is the same in all locations. This favours customers connecting to smaller sites, such as Bratislava, but disfavours customers clustered together in large locations.
Ebone is in effect owned by its customers and is not-for-profit; it is easy to become an Ebone customer and easy to walk away. Multihoming is expected. Customers clustered together in large locations are therefore likely to colocate around exchange p oints and interconnect directly, using Ebone for long-distance connectivity (to places like Bratislava). This, of course, can be inefficient.
If instead a customer can connect directly to Ebone and pay a price comparable to IX fees and capital equipment costs for purely local connectivity, and our normal (expensive) cost-based price for international connectivity, this is a good thing.
There is a price-perversity at work in Europe; U.S. capacity is cheaper from some locations than European capacity. This is particularly true in the UK and the west coast of Europe. Consequently, most Ebone customers have their own lines of various s izes (ranging from 155Mbps to 2Mbps or smaller) to U.S. providers.
Ebone does provide U.S. capacity; it is cheaper to offer in several locations than European capacity is. The pricing scheme has been based on an arrangement that has a customer take 2/3 of its capacity from U.S.-based sources, and 1/3 from European-ba sed sources, and leads to a percentage discount.
It would be more flexible to use the same mechanism that allows local and long-distance traffic to be separated to further divide long-distance traffic into European and U.S. categories. Also, it would be competitive price-wise with the thin circuits across the ocean.
There are two approaches; one is more radical economically, the other is more radical technically, and relies on QoS-like mechanisms.
PROPOSAL #1: Use separate rate-limited/rate-controlled queues. The goal is a bill with three separate categories (local, long-distance (Europe, transatlantic) each with its own flat-rate price.
- Customer traffic towards a prefix we hear from the U.S. will go out one rate-limit.
- The other approach is to use diff-serv, which somewhat liberates the TOS byte in IPv4 headers. Mark each packet at ingress with a description of where the ingress is and use those marks to sort traffic into rate-limit queues.
- This solves the asymmetry problem and also gives flexibility -- we can make certain traffic more droppable, so when there are abnormal circumstances "expensive" traffic will take precedence over less-expensive traffic (WRED). The problem: markin g packets at ingress is expensive, and has a scalability problem. There are only so many codepoints in diff-serv.
- The final approach (in some future world): use MPLS. Diff-serv, after all, is a breeding ground for MPLS ideas.
- [plug: we will also want a fourth queue for traffic that remains within North America]
- On each VIP maintain an accurate AS*AS traffic matrix
- This solution is scalable, not hard on routers, and has some useful side effects (encourages bigger and fewer packets, encourages content replication, etc.) The flaws: requires accurate counting/billing ceilings. Other flexibility packages are hard to maintain. We have the "pandora's box" attitudes to settlements.