Dear all,
I've made a mistake. It's not Skype that is using TCP behind NAT, it's
Google Talk. We've been working in a comparison of both VoIP programs,
and we've found out that feature recently.
Anyway, I think my question remains...
If GTalk has a solution using UDP and they use it in most cases, so why have
they changed for TCP only when both peers are behind the same NAT?
Developers resources is not likely to be the reason, because GTalk worked
only with UDP and this was changed for TCP. That is, they spent more
resources to do that!!!
Carlos
On Wed, 12 Jul 2006, Michael Slavitch wrote:
"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
http://www.well.com/~theek
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
--
-------------------------
Carlos Alberto Kamienski
[EMAIL PROTECTED]
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
