Re: [p2p-hackers] Skype, TCP, and UDP

Wed, 12 Jul 2006 12:35:45 -0700

"If they're using TCP, I think it's for reasons other than performance and voice quality."
 
Nothing I said invalidates that. In a broadcast domain packet loss is rare because they are incredibly over-engineered.  Some analysis I did way back in another career showed that taking the mean of peaks gave a typical burst utilization rate in the order of 5-10% or so, and that is in the core backbone. True mean is an order of magnitude less.  LAN bandwidth has grown at a faster rate than the traffic that goes over it.  Gigabit Ethernet is now a commodity.  In a modern layer-2 switched network loss effects on UDP and TCP is negligible, especially given a media stream that has millisecond-range sensitivity in a nanosecond/picosecond environment.
 
That is most certainly not true outside the broadcast domain, but in the LAN it is different.
 
TCP has one major benefit over UDP: No need to code an overlay to maintain persistence because it's done for you by the protocol.
Less code to maintain and more focus for the code that must be maintained, ie stuff that reliably abstracts the NAT and works in all cases.
 
Focus on the goals, remember.
 
It has to be for reasons other than voice quality because there is no difference in voice quality within the LAN. 
 
I suspect the reason is deadlines and developer reasources. Like Douglas Adams said about the HHGG: "it was slightly cheaper", and if it saved them a month of developer time and some reduction in code maintenace it was the right thing to do.  
 
The best code is shipping code that people actually use.
 
 
On 7/12/06, David Barrett <[EMAIL PROTECTED]> wrote:

Hm, I'm not sure I agree.

 

UDP has a feature that TCP simply cannot match: lossiness.  This is a desirable trait for VoIP that TCP lacks.  If a voice packet gets dropped, it's not merely unnecessary to retransmit, it's actually harmful to voice quality.

 

Indeed, I expect they use TCP only on a LAN precisely because they count on there being * no* congestion, because they recognize UDP is preferable in a bandwidth-constrained environment (ie, the internet).  This is because the only real option for VoIP is to notice high packet lost (via something RTCP-ish) and reduce your stream encode rate.  In the event bandwidth is constrained, TCP will just back up and destroy your voice quality, while complicating your ability to detect and resolve the problem (and even if you do back off the encode rate, it'll need to send your huge backlog of data before the new encode rate can kick  in).

 

Granted, I'll entirely admit TCP is superior to UDP for stream data that must be reliably delivered in order (which is its whole point).  Likewise, it is certainly easier to work with TCP streams than reconstruct TCP on top of UDP.  But for VoIP, UDP is the way to go. 

 

If they're using TCP, I think it's for reasons other than performance and voice quality.

 

-david

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Michael Slavitch
Sent: Wednesday, July 12, 2006 6:23 AM


To: theory and practice of decentralized computer networks
Subject: Re: [p2p-hackers] Skype, TCP, and UDP

 

You can encapsulate and overload far more in a TCP stream than in a sequence of UDP packets with less development effort.

 

This is not novel, it is the basis for all communications theory since the stone age of DECNET and SNA.

 

Step back and think of the possibilities.  Stop thinking of voice as the endgame and instead as the beginning.

 

M
 


_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers



_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers

Reply via email to