NAT traversal is easier with UDP than it is with TCP. So that would be
why they use UDP outside the NAT.
As for using TCP inside the NAT, why not? It absolves the application of
the responsibility of ensuring reliable, in-order delivery. It plays
nicely with other protocols, unlike UDP unless properly engineered. It
has the wisdom of a decade of tweaks to ensure good performance --
Nagle's algorithm, fast retransmission, limited retransmission, Karn's
algorithm, SWS avoidance, etc. And if your code is properly abstracted,
it shouldn't take too long to re-engineer it to use TCP instead of UDP.
- Mike
Carlos Alberto Kamienski wrote:
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
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
