Interestingly BT claim that their network will never overload as they charge for local calls - ie ration by cost. The corollary is that if the network becomes overloaded they raise the cost.

a voice network nowadays is pretty easily overengineered anyhow afterall, people don;t spend more than 8 hours a day on the phohne, and if one person is speaking, the other is silient, so you only have to support 12th of the worlds population of voice traffic - if yo udo silence suppression actually, the cost mechanism is not necessary if you implement traffic policing, or you use IP and drop pacjkets, TCP backs off anyway to PRECISLEY the same operating point, but it shares the net on a packet basis instead of a call basis, and obviates the need or cost for usage based billing.... you can implement adaptive audio tools that do just the same one problem is that some of the details of TCP's mechanism has a minimum granluarity/rate (this can be fixed) but this makes it very similar to voice which has a minimum rate/quality... you can rely on people simply to stop using a voice call if the overall quality falls below some acceptable level.... the main problem a lot of ISPs have with this is that there is no obvious way to tell that a UDP based voice "call" is adaptive, and nice like a TCP one (should be; there are people who have hacked up TCPs that don't back off - multiple tcp connections a la netscape also are anti-social:-) another problem is that quite a lot of routers are just plain broken, and don;t forward a steadyish packet rate as well as a bursty one, and in any case, occasional losses (e.g. when router is processing route update) don't "appear" to hurt TCP (as far as the ISP is concerned - of course, a lot of users are getting pretty sick of seeing "stalled" messages at the bottom of netscape - often caused by dropout in the forwarding process, or by routing flaps/black holes - around 9% of routes have a MTBF of under an hour accoeding to recent stats.....) all good fun.... jon