Subject: [Tsvwg] TCP-over-UDP draft

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 11 May 2009 14:07:01 -0400 (EDT)

We have submitted a new draft titled TCP-over-UDP. The abstract is 
attached below. The draft is available at:
http://tools.ietf.org/html/draft-baset-tsvwg-tcp-over-udp-00

Comments are appreciated.

Abstract:
We present TCP-over-UDP (ToU), an instance of TCP on top of UDP.  It
provides exactly the same congestion control, flow control,
reliability, and extension mechanisms as offered by TCP.  It is
intended for use in scenarios where applications running on two hosts
may not be able to establish a direct TCP connection but are able to
exchange UDP packets.

-salman

---

From: Mitchell Erblich <[email-masked]>
Date: Mon, 11 May 2009 17:45:31 -0700

Author & Group,

	IMO, these are the first items that are possible issues within the  
draft.

	This draft seems to indicate that ToU is a defaulted behaviour.

	A transparent emulation of TCP may not be as simple to implement
	as stated in this draft and thus should be an alternative behaviour.
	Thus, IMO, ToU COULD be considered if a TCP (peer to peer application)
	fails to establish a connection and a NAT is known to be the root  
cause.

	Which I seem to miss, As how it is determined that a type of NAT is
	is the cause?

	If a another type of intermediate system is within the path and it
	is establishing an end-point and then generating a new connection,
	I see a major issue wrt slow start.

	My experience has shown when two different orders of magnatude
	of round-trip-times are encountered due to one being local to
	one end point and the other connection being WAN based, thus
	at least one connection (the faster rtt connection) becomes idle during
	each transfer and thus never leaves slow-start. It will then keep the
	other connection in slow-start type bandwidth.

	Without achieving CA phase of a connection with the corresponding
	bandwidth, the effort of ToU may not be justified.

	Thus, if the application needs to infrequently burst small amounts of
	data, UDP MAY be a more logical choice when a NAT is preventing
	TCP establishment and the application performing whatever needed
	rexmits/requests.

	Mitchell Erblich
	=======================

---

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 11 May 2009 21:56:51 -0400 (EDT)

There is already an I-D about NAT behavior disovery.
http://tools.ietf.org/html/draft-ietf-behave-nat-behavior-discovery-06

It is quite possible that a small burst of data can overwhelm a slow WAN 
connection. To prevent this, flow control is needed which ToU provides.

If maximum payload size is known in advance, and if the payload size does 
not exceed MTU, an application designer can use a stop-and-wait like 
protocol. Unfortunately, it is not always possible to predict the 
payload size in advance. To achieve reasonable throughput and to avoid 
relaying message over TCP through an intermediary, ToU is probably the 
only available option.

-salman

On Mon, 11 May 2009, Mitchell Erblich wrote:

>> We have submitted a new draft titled TCP-over-UDP. The abstract is attached 
>> below. The draft is available at:

---

From: Mitchell Erblich <[email-masked]>
Date: Mon, 11 May 2009 20:43:28 -0700

Group,

	TCP will initially default 4 MTU size segments for fast rexmit support.
	with 3 dup acks.

	Then because they are xmited ASAP and no delayed acks, it can
	then burst 8 MTU sized segments. The acks will be almost back to
	back.

	Thus is called slow-start.

	Any time idles occur, we many implementations did a multiplicative
	decrease.

	Thus, knowing this behaviour UDP with infrequent xmits of small
	amounts of data will most likely not generate a larger LOAD than
	any normal TCP.

	Mitchell Erblich
	===================

On May 11, 2009, at 6:56 PM, Salman Abdul Baset wrote:

> It is quite possible that a small burst of data can overwhelm a slow  
> WAN connection. To prevent this, flow control is needed which ToU  
> provides.
>
> If maximum payload size is known in advance, and if the payload size  
> does not exceed MTU, an application designer can use a stop-and-wait  
> like protocol. Unfortunately, it is not always possible to predict  
> the payload size in advance. To achieve reasonable throughput and to  
> avoid relaying message over TCP through an intermediary, ToU is  
> probably the only available option.
>
> -salman
>
>

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 12 May 2009 00:49:41 -0400 (EDT)

What do you suggest to do when message size is greater than 8-MSS? How 
do you propose to do loss recovery when multiple segments in a 8-MSS 
message get lost? Yes, one can do retransmissions and cwnd reduction but 
that is reinventing selective TCP mechanisms. The whole point of ToU is 
*not* to reinvent selective TCP mechanisms.

For 1500 byte packets (1460 bytes MSS assuming no IP or TCP options), the 
maximum initial window size is 4380 bytes or 3-MSS and not 4-MSS as you 
suggest. A TCP sender defaults initial window to 4-MSS only when MSS is 
below 1096 bytes.

-s

On Mon, 11 May 2009, Mitchell Erblich wrote:

>> protocol. Unfortunately, it is not always possible to predict the payload 
>> size in advance. To achieve reasonable throughput and to avoid relaying 
>> message over TCP through an intermediary, ToU is probably the only 
>> available option.
>> 
>> -salman
>> 
>>

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 12 May 2009 09:30:14 +0200

Hi Salman,

looking at figure 2 I think you can not run TLS/UDP since
TLS requires a reliable transport which UDP is not.
So I do not think that Option-2 is possible at all.
Not using option-4 because you do not know the overhead added
by DTLS is something I do not understand. Why can't your ToU
can not request this from the DTLS layer? You still need to
figure out the MTU the UDP can use.

Another question: How should path MTU discovery be done?

Best regards
Michael

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Tue, 12 May 2009 08:38:01 -0500

Support for ECN should also be a goal for new Internet transports and
transport encapsulations, IMHO.  This draft doesn't yet approach the
topic of ECN, though it may be possible if a UDP API supports ECN bit
access.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Michael Tüxen
>Sent: Tuesday, May 12, 2009 3:30 AM
>To: Salman Abdul Baset
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Tsvwg] TCP-over-UDP draft
>
>Hi Salman,
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 May 2009 16:49:23 +0300

[speaking as an individual]

Hi,

> may not be able to establish a direct TCP connection but are able to

my main concern about this draft is that although it's deceptively  
simple in terms of writing the specification ("slap a UDP header on  
each TCP segment"), it puts a huge burden on the implementer: TCP is  
*not* easy to implement. I'm fully convinced that we'd be facing  
serious interoperability issues, not to speak of slightly or majorly  
broken congestion control implementations.

Lars

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 12 May 2009 11:05:12 -0400 (EDT)

TLS does not require the use of TCP; it only requires a reliable transport 
protocol. Layering TLS on top of ToU is preferable since ToU provides the 
same reliable inorder delivery semantics as TCP.

Currently, the draft does not specify path MTU discovery. However, the 
discovery mechanisms should not be any different from TCP MTU discovery 
mechanims.

-s

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 12 May 2009 17:13:02 +0200

On May 12, 2009, at 5:05 PM, Salman Abdul Baset wrote:

> TLS does not require the use of TCP; it only requires a reliable  
> transport protocol. Layering TLS on top of ToU is preferable since  
> ToU provides the same reliable inorder delivery semantics as TCP.
Yes, but option 2 of figure 2 is ToU/TLS/UDP. So you want to run TLS/ 
UDP,
or am I wrong...
>
>
> Currently, the draft does not specify path MTU discovery. However,  
> the discovery mechanisms should not be any different from TCP MTU  
> discovery mechanims.
OK.

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 12 May 2009 11:13:33 -0400 (EDT)

Indeed.

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 12 May 2009 11:16:04 -0400 (EDT)

> Yes, but option 2 of figure 2 is ToU/TLS/UDP. So you want to run TLS/UDP,
> or am I wrong...

The draft favors Option-1. I agree that Option-2 is incorrect and will be 
removed or will add appropriate text. Thanks for pointing this.

-s

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 12 May 2009 11:22:31 -0400 (EDT)

What is the alternative for hosts behind NAT that need to establish a 
direct TCP connection but are unable to do so?

What are your thoughts on the Design Alternatives section in the draft?

-s

On Tue, 12 May 2009, Lars Eggert wrote:

> my main concern about this draft is that although it's deceptively simple in 
> terms of writing the specification ("slap a UDP header on each TCP segment"), 
> it puts a huge burden on the implementer: TCP is *not* easy to implement. I'm 
> fully convinced that we'd be facing serious interoperability issues, not to 
> speak of slightly or majorly broken congestion control implementations.
>
> Lars
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 May 2009 17:30:36 +0200

> http://tools.ietf.org/html/draft-ietf-behave-nat-behavior-discovery-06

Worth noting that I don't think this draft works to do what you need  
here.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 May 2009 18:03:02 +0200

Pull up an IPvX-in-UDP tunnel and run the kernel TCP.

Lars

On May 12, 2009, at 17:22, "Salman  Abdul Baset" <[email-masked]>  
wrote:

>> simple in

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 12 May 2009 12:18:03 -0400 (EDT)

Peer-to-peer applications are user-space applications and are the likely 
users of ToU because they suffer from NAT issues the most.

Are you suggesting each p2p application to run IPvX-in-UDP tunnel and run 
kernel TCP? I am not a tunneling expert but as far as I can tell 
configuring tunnels is not a seamless operation. It is difficult to 
imagine a user configuring a tunnel for every new Skype connection.

-s

On Tue, 12 May 2009, Lars Eggert wrote:

> On May 12, 2009, at 17:22, "Salman  Abdul Baset" <[email-masked]> wrote:
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 13 May 2009 09:38:11 +0300

Hi,

> imagine a user configuring a tunnel for every new Skype connection.

what I'm saying is that implementing a mechanism for pulling up an  
IPvX-over-UDP tunnel is not going to be more complex than correctly  
implementing a full TCP in user space, and it lets you run *any*  
protocol inside (e.g., SCTP or DCCP could offer transport features  
that a P2P app might really like).

I'm trying to get folks from Apple/MS/Cisco/Nokia/etc. together (who  
all have tunnel establishment solutions) in order to discuss if there  
is something the IETF could standardize in this space.

Lars

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 May 2009 02:55:13 -0400

I'm not sure whether the implementation issue is likely to be a major  
issue. I don't expect each application to write its own version of  
ToU. Just like with other protocols of more-than-trivial complexity,  
we're likely to see libraries that are re-used by apps writers. Among  
protocols I'm somewhat familiar with, DNS, TLS (OpenSSL), SIP (a  
handful of libraries) and NSIS seem to follow this pattern. These C/C+ 
+ or Java libraries are then the foundation for the wrapper versions  
in Python, PHP and Ruby.

I have no objection to pursuing tunneling as another option, but they  
tend to require kernel upgrades to work if they are not supported by  
whatever kernel you are running. Not a plausible option for an  
application that is trying to get deployment traction.

Henning

On May 13, 2009, at 2:38 AM, Lars Eggert wrote:

> all have tunnel establishment solutions) in order to discuss if  
> there is something the IETF could standardize in this space.
>
> Lars

---

From: Michael Welzl <[email-masked]>
Date: Thu, 14 May 2009 11:10:13 +0200

Hi,

I changed the subject to avoid mixing with the ongoing
thread, as my comment is slightly different: I see
another benefit of using this scheme.

Right now, window scaling is usually disabled or limited
by default (*). When using TCP-over-UDP, there wouldn't
be a reason to do so, because surely no device in the
network would exhibit the reported faulty behavior for
TCP-over-UDP yet. This could be a significant performance
gain.

Cheers,
Michael

PS: I already apologize for having started the longer
architectural debate that I expect to follow. Such
a debate should perhaps move to e2e-rg, where it
will be a re-iteration of things already said, and
therefore lead to nothing  :-)   My suggestion here
is to actually try what I wrote above, and see what
happens in the long run...

----

(*) I once summarized this discussion for a
presentation, see slides 30-32:
http://www.welzl.at/research/publications/caia-jan08.ppt
http://www.welzl.at/research/publications/caia-jan08.pdf

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 May 2009 03:23:22 -0600

Salman,

Perhaps a silly question, but: why not just change the IP protocol
number on TCP packets from 6 to 17 and leave the rest of the packet
unchanged?

--brian

Salman Abdul Baset wrote:                    (Mon, 11 May 2009 14:07:01)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 May 2009 09:01:10 -0400

One of the goals is to avoid changing the OS kernel (or switch to a  
different OS), as the ability of applications to make kernel changes  
is limited and likely to decrease as the idea that random applications  
can make global changes seems ever less a good one.

Henning

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 May 2009 07:05:46 -0600

Henning,

But if, as the draft suggests, one puts a cookie into an application
header in the UDP packet, NATs, middleboxes and firewalls will soon
make it as inaccessible as the regular TCP that this ploy attempts
to sidestep.  No?

--brian

Henning Schulzrinne wrote:                  (Thu, 14 May 2009 09:01:10)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 14 May 2009 16:23:31 +0300

> number on TCP packets from 6 to 17 and leave the rest of the packet

First, the UDP checksum has a different offset than the TDP one. Second, the 
UDP length is actually parsed by some (if not all) IP stacks; I know for a 
fact that Linux will trim the payload resp discard the packet, if the UDP 
length field value is too small resp too big.

That's why I wrote this not so long ago:
http://tools.ietf.org/html/draft-denis-udp-transport-00
This is very much the same as what Salman is proposing *again*.

That's also why I suggested that we IANA should reserve a range of transport 
protocol numbers for as yet unspecified transport protocols with port numbers 
and checksum. That would allow NAT to translate, and firewall to filter based 
on port numbers, for would-be future transport protocols.

In the mean time, I figured out that TCP over UDP would have nasty problems 
with the Maximum Segment Size. Most if not all consumer NATs sitting in front 
of PPPoE or PPPoA DSL lines do MSS clamping... of real TCP packets. That is 
ugly. But in reality that's how TCP path MTU discovery is "performed". Any 
transport protocols that needs path MTU discovery is bound to exhibit some 
issues. Packetization-layer PMTUD is an obvious solution, but it's not as 
"fast" as MSS clamping, and I suspect most TCP stacks don't do it at all.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 14 May 2009 16:35:27 +0300

> + or Java libraries are then the foundation for the wrapper versions

TLS requires inventing a new I/O abstraction. Indeed, OpenSSL has reinvented 
the wheel with its BIO stuff. Where applications expected a socket, TLS 
requires an opaque library-specific pointer... and events handling gets messy 
and intricate in the case of non-blocking I/O.

Running the transport protocol in the kernel avoids this problem, and enables 
running unmodified applications. In fact, already today you can run any IPv6-
capable applications free of firewalling and NAT constraints if you have 
Teredo.

> application that is trying to get deployment traction.

As a matter of fact, layer-3 tunneling does not require operating system 
modifications. As long as it runs over UDP, you can always reimplement it on 
top of UDP sockets. If you can have a TCP stack in userland, you can have a 
minimalistic IP network layer as well. So that's a non-issue.

However, layer-3 tunneling does make operating system and API support a lot 
easier, as it enables reuse of the TCP/IP stack and socket API.

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 14 May 2009 11:23:54 -0400 (EDT)

Hi Remi,

Sorry, I was completely unaware of this draft. Where was this presented? 
What was the outcome? Are you still interested in pursuing this approach?

I think that Linux dropping small UDP packets depends on how the 
iptables/firewall is configured. I am not sure if such packet drops can be 
termed as a default UDP stack behavior. Am I missing something?

MSS clamping is an issue because routers in the path of a packet can 
rewrite MSS option in a TCP SYN packet. Clearly, this cannot be done for 
ToU. However, ToU can obviously take advantage of packetization 
layer PMTUD. For 'fast' discovery, a ToU stack can default to a 1492 MSS 
instead of 1500 MSS.

-s

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 14 May 2009 12:06:48 -0400 (EDT)

The use of a cookie in ToU is to demultiplex it from other protocols such 
as STUN. While including a cookie in ToU can certainly be discussed, note 
that STUN protocol also uses a magic cookie.

The existing NAT devices should not block ToU because they only see ToU as 
a stream of UDP packets. The new NAT devices, if they are BEHAVE compliant, 
should also not block it.

In general, your comment implies that any identifiable portion in a 
protocol is likely to make it easier to block it. Yes, this is true but 
there is hardly any protocol which will not escape this censure...

-s

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 15 May 2009 09:46:03 +0300

> Sorry, I was completely unaware of this draft. Where was this presented?

It was presented in TSVAREA at IETF#73.

> What was the outcome?

The outcome was that this needs to be further studied, in other words, there 
was no outcome.

> Are you still interested in pursuing this approach?

The document has expired because nobody seemed to have any immediate interest 
in it. I guess the last P2PSIP meeting has woken some people up.

> termed as a default UDP stack behavior. Am I missing something?

No. It is the default behavior, and you cannot change it without modifying the 
core kernel. You can check __udp4_lib_rcv() from net/ipv4/udp.c by yourself 
(look for pskb_trim_rcsum). 

> layer PMTUD. For 'fast' discovery, a ToU stack can default to a 1492 MSS

That's true. However, I suspect this will be unpopular in this particular 
venue (IETF TSVWG).

---

From: Salman Abdul Baset <[email-masked]>
Date: Sat, 16 May 2009 19:16:44 -0400 (EDT)

> (look for pskb_trim_rcsum).

I looked at the 2.6.29 kernel code at lxr.linux.no and I do not think if 
this is the default behavior as you say. The condition which you are 
refering to (1) checks if the length of the received UDP packet is less 
than a UDP header (2) if the checksum of the received packet is 
still valid after the operation.

if (ulen < sizeof(*uh) || pskb_trim_rcsum(skb, ulen))
   goto short_packet;

(1) is not true because ToU is layered on top of UDP and every ToU 
header will be present in every UDP packet.

(2) is not true because ToU never updates UDP packet checksum.

May be, we are not communicating our assumptions properly?

-s

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 18 May 2009 09:22:35 +0300

On Sunday 17 May 2009 02:16:44 ext Salman Abdul Baset wrote:
> >> iptables/firewall is configured. I am not sure if such packet drops can
> >> be termed as a default UDP stack behavior. Am I missing something?
> >
> > No. It is the default behavior, and you cannot change it without
> > modifying the core kernel. You can check __udp4_lib_rcv() from
> > net/ipv4/udp.c by yourself (look for pskb_trim_rcsum).
>

And then what? The point is, changing the IP protocol number as Brian 
suggested simply will not cut it.

---

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 18 May 2009 08:11:29 -0400 (EDT)

> suggested simply will not cut it.

TCP-over-UDP uses TCP's reliable, congestion control and flow control 
algorithms on top of UDP. It does not change the IP protocol number.

Perhaps, you are hinting at the reuse of kernel TCP stack by changing IP 
protocol numbers? Such reuse requires a kernel change. As Henning already 
pointed, 'the ability of applications to make kernel changes is limited 
and likely to decrease as the idea that random applications can make 
global changes seems ever less a good one.'

-s

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 18 May 2009 15:43:23 +0300

> number on TCP packets from 6 to 17 and leave the rest of the packet

My point is simply that _this_specifically_ does not work. That's all.

You are over-reading my mail.

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2009 16:05:48 -0700

Lars Eggert wrote:
> simple in terms of writing the specification ("slap a UDP header on each
> TCP segment"), it puts a huge burden on the implementer: TCP is *not*
> easy to implement. I'm fully convinced that we'd be facing serious
> interoperability issues, not to speak of slightly or majorly broken
> congestion control implementations.

My concern is that this is NOT TCP. E.g., someone running Telnet over
TCP couldn't run Telnet over this, because it lacks the URG pointer and
PSH bit.

I wonder why this can't be done a lot more simply:

a) ask IANA for a UDP service port for "TCP over UDP"

	define the packet handling recursively, i.e.,
	upon receipt of a UDP packet, if there is
	a listener on the socket pair hand the packet to it,
	otherwise extract the UDP header and
	process conventionally as if the packet just arrived

b) define TCP as using the UDP's IP header in its (TCP) pseudoheader for
checksumming

c) stop. no changes to TCP. no need for a magic cookie. no need to
ensure that UDP checksumming is on. no need to have TCP gather UDP's
port info, etc., or check UDP's checksum.

I.e., why isn't this just "TCP as is over UDP"?

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2009 16:06:58 -0700

> users of ToU because they suffer from NAT issues the most.

This is confusing to me as well. Most NATs allow TCP where they prohibit
UDP, not the converse. Are there really NATs that favor UDP?

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2009 16:10:39 -0700

FWIW, this won't work because NATs often try to be smart, and they'd
interpret the TCP's sequence number as faulty UDP checksums and lengths.
It also begs the question of how to recognize that these are TCP packets
at the receiver, which presumably is also capable of receiving real UDP
packets.

Joe

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 20 May 2009 10:34:47 +0300

> TCP couldn't run Telnet over this, because it lacks the URG pointer and

Is there anything that *actually* uses urgent data, except for Telnet? This 
"feature" of TCP is plagued with interoperability problems anyway - the 
infamous RFC vs BSD urgent pointer offset. Pardon my ignorance, but is URG and 
the urgent pointer of any use other than for out-of-band data?

In the unlikely event that someone wants to run a remote shell over TCP over 
UDP, I would guess they're more likely to use SSH or another more 
modern/secure thing.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 20 May 2009 10:38:50 +0300

> UDP, not the converse. Are there really NATs that favor UDP?

TCP definitely works better than UDP when the initiator is behind a NAT and 
the responder is _not_. In particular, TCP offers better binding lifetimes, 
"benefits" from MSS clamping, and does not suffer from UDP NAT implementation 
bugs.

But if both parties are behind a NAT, then TCP hardly works at all, whereas 
UDP often does work (Teredo and ICE both use UDP). This is especially true if 
the NAT includes some form of crude firewalling.

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 May 2009 05:57:46 -0400

> the NAT includes some form of crude firewalling.

ITU H.460.18 / .19 also use UDP for firewall/NAT traversal, for the  
same reason.
(H.460.17 uses DNS and TCP.)

Regards
Marshall

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 May 2009 07:33:42 -0700

> UDP, I would guess they're more likely to use SSH or another more 

Well, if you want to design foo-over-UDP, you get to decide this.

If you want to run TCP over UDP, either you do or you don't. If you
start being selective about *required* protocol properties, you're not
running TCP anymore.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 May 2009 07:50:44 -0700

Rémi Denis-Courmont wrote:
> UDP often does work (Teredo and ICE both use UDP). 

That has less to do with the NAT and more to do with the pair of
endpoints. It'd be useful to update the intro with this detail.

> This is especially true if

That cuts both ways; some NATs dump anything that isn't TCP (except,
e.g., for DNS that they proxy rather than translate).

Joe