About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

Re: Very fast IP, no ATM...

  • To: Paul Bryant <
    >
  • From: Jon Crowcroft <
    >
  • Date: Tue, 03 Dec 1996 15:36:56 +0000
  • Cc: Paul Christ <
    >,
    (Christian Huitema), Guy T Almes <
    >,


 >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





 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | Copyright Statement
RIPE.NET Homepage LIR Portal RIPE Community