UDP, TCP, and NAT (was...)

[Ben Scott]

On 7/13/07, Thomas Charron <twaffle at gmail.com> wrote:
>>   It is true that UDP is inherently connectionless and one-way, while
>> TCP is inherently connection-oriented and two-way.  At the same time,
>> almost any application protocol is bi-directional by nature (how often
>> do you really only want to talk one way?).  So there's pretty much
>> always going to be a two-way conversion.
>
> ...  UDP is by DEFINITION connectionless, and TCP is by DEFINITION
> connection oriented!

  Um... I just wrote exactly that.  (See the first sentence of the
paragraph you just quoted.)  Am I just not explaining myself clearly
enough, or are you not reading what I'm writing, or what?  :)

> And generally utilizing streamed UDP data *IS* a one way conversation.

  Well, if you're talking about someone consuming an audio and/or
video program using something like RTP, then sure.  But that's hardly
the only use of UDP in the world.  DNS, NTP, etc., are all very much
command/response designs.

  I don't know enough about VoIP to comment accurately on how it
works. From what I've read, I'm guessing each direction of the
conversation is actually handled independently -- essentially two
different instances of the streaming scenario described in the
previous paragraph.  The control channel is separate.  In concept,
it's the same problem as with FTP -- a complex application protocol
with multiple channels isn't going to be NAT-friendly, regardless of
the use of TCP or UDP.

> Any secondary streams, such as a command and control stream are
> *different* in their protocol.

  That depends on the specific application protocol.  Just as an example,
HTTP is often (ab)used for streaming purposes, and then everything is done
in one TCP connection.

> If you need to have a two way conversation, it *generally* is a
> better idea to use TCP, unless you do not care about data
> which may be lost, such as with audio and/or video streams.

  It's not so much that one doesn't care at all.  If one didn't care,
you could just use TCP anyway.

  There are a couple scenarios UDP gets used over TCP:

  One is in real-time applications -- such as people watch video or
listening to audio "live".  In such situations, it's more important to
keep the stream going in real-time than it is to make sure all the
data gets there.  If packets arrive out-of-sequence, you just discard
the late traffic.  Late or lost packets cause small artifacts in the
audio/video, but that's better than having two sides of a phone
conversation get out of sync, or for video playback to pause.  It's
not that one doesn't care about loosing data, it's that one cares more
about keeping things running in real-time.

  The other common use of UDP is for applications where you've got a
very simple request/response design, and there's no need to keep
session state.  In such cases, TCP is just useless overhead.  That's
why DNS and NTP and such use UDP.  If all you're doing is asking for a
name or the time, TCP just gets in the way.

> ... I'm saying that the automatic UDP port forwarding of NAT boxes
> isn't standardized anywhere ...

  Totally incorrect.  RFC-2663 (1999) covers UDP in this way, as does
RFC-3022 (2001).  The original NAT RFC, RFC-1631 (1994) is about
one-to-one NAT, and thus doesn't cover this for TCP *or* UDP.

  Those are all "Informational" RFCs (not "Standards Track"), but if
you want to make that argument, then *all* aspects of NAT are "not
standardized anywhere".

  I also found RFC-4787 (Jan 2007), which is a BCP about how to design
application protocols which use unicast UDP in a NAT-friendly manner.

  No, I didn't know this off the top of my head.  But I typed "NAT
RFC" into Google.

> Some may argue that it's a really bad idea in general.

  This is the Internet.  Some will argue about anything.  Look at us.  :)

  I do think that the Internet would be a better place if we didn't
have to deal with NAT.  Or firewalls, for that matter.  Life is hard.
Get a helmet.

>> ... many application protocols (TCP and UDP) which work just fine over
>> a simple address/port translation which assumes incoming and
>> outgoing are symetrical.
>
>   Except of course, when the initial UDP packet is coming from the
> outside.

  Um.  How exactly does TCP make this better?

  For example: How do I reach the HTTP server (TCP!) behind my NAT box at
home from the outside?

>> (This is all in "active mode" FTP.  In passive mode, the roles are
>> reversed, but you still have the same problem and solution if the
>> server is behind a NAT boundary.)
>
>   I snipped the text as it was informative, but irrelevant.  FTP works
> backwards, but mostly because it was a throwback to days before NAT
> WASN'T short for 'Natalie'.  ;-P

  And like I *just wrote*, passive mode is not "backwards" -- the
client initiates all connections.  But if the server is behind a NAT
boundary, you *still* run into the same problems, just in the other
direction.  Get it?  :)

> However, the list of applications which utilize UDP and
> cannot traverse a NAT is much greater then those which have issues
> with TCP.

  That's a completely unsubstantiated claim.  I suspect it's actually
true, but I can think of no way to check it.  Can you?

  I can make this (mostly philosophical) point, though: DNS is the
most important application protocol on the Internet.  When DNS stops
working, pretty much everything else on today's Internet stops
working.  And DNS over UDP works just fine across NAT without specific
support for DNS in that NAT implementation.  I'm not sure what that
means in practical terms, but it must count for something.  ;-)

> But here is the core point from MY side.  It is generally much
> easier to deal with multiple incoming connections via TCP.

  How so?  Either one is going to need application-protocol support in
the NAT or firewall implementation.

> It [UDP's] original intent wasn't for connection oriented communications.

  Right.  But one of the points I'm trying to make is that even when
things are not connection-oriented at the *transport layer*, they're
still generally going to be two-way *at the application layer*.  It is
very rare for someone to only want to send and *never receive* (or
vice versa).  Even streaming for "broadcast media" needs something to
request the stream.

  Now, it is absolutely true that, in practical use today, many of the
streaming protocols out there use different TCP/UDP ports for control
vs content.  So in practical terms, any NAT or firewall is going to
have to need application-level support to track the sessions for such,
so allow the requested content "back inside".  But that's a result of
how the application protocols are designed, not something inherent in
UDP.

  I suppose it's true that, in the case of streaming A/V, one
generally wants the control channel to be connection-oriented and
reliable, while one wants the content channel(s) to be real-time, so I
guess it's more likely that one will end up with a TCP control channel
and UDP content channels.  But that's even more of an assumption than
the "UDP responses come in on the same port" assumption.  :)

-- Ben