Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Overflow circuit

  • From: Steven M. Bellovin
  • Date: Sat Mar 27 19:41:12 2004

In message <05bb01c41431$dd522e00$6401a8c0@alexh>, "Alexei Roudnev" writes:
>Thanks for the answers about Voip usage over satellite (I did not know, that
>it does not cause unacceptable delays and echo).
>Responses (which I received) shows, that many people deployed such system

Define "unacceptable".

Old-style telcos have delay budgets for their designs; if the 
round-trip time is too long, people find the call unpleasant.  While 
VoIP does have its own delay issues (see below), the big problem here 
is the satellite link.  VoIP doesn't give you an exemption from the 
speed of light laws; if you find satellite phone calls unpleasant -- I 
do -- you're not going to like satellite VoIP calls, for reasons that 
have little to do with the IP.  This is one reason why companies have 
spent fortunes putting in transoceanic fibers instead of launching more 
satellites -- the customers prefer the quality.  Satellite calls are 
cheaper, but they're noticeably -- and for many people, unacceptably -- 
worse in quality.

I should note that many VoIP systems make this noticeably worse, though 
(of course) less so as a percentage of the total delay than for 
domestic US VoIP calls.  The problem is the tradeoff between delay and 
efficiency.  Suppose you're sending 56 Kbps, uncompressed -- the 
equivalent of so-called "toll quality" voice.  That's 7 kilobytes/sec.
If you want nice, big UDP packets with 1K payloads, you've just 
incurred about 143 ms of buffering delay, independent of transmission 
time.  (And on a DS1 line, transmission time for that packet is 
non-trivial.)  The total delay budget is, as I recall, about 150 ms.
You can go to nice, short packets -- say, 100 bytes -- but then your 
IP, UDP, and RTP headers add a substantial amount of bandwidth 
overhead.  Apart from line efficiency, on relatively slow lines that's 
a lot of serialization time going out over the wire.  Compression makes 
the packets nice and short; depending on what you do, it may or may not 
help with the headers, but you have to spend a chunk of CPU time after 
you've collected a large enough voice sample to be worth compressing, 
and that means more delay time.

Bottom line:  VoIP is inherently costly, either in delay time, 
bandwidth, or both.  It doesn't mean it's unacceptably bad, but that 
150 ms delay budget came from many years of psychoacoustic studies.

Cisco has a good web page on this, with lots of numbers.  See

		--Steve Bellovin,

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.