Subject: [tcpm] draft of tcp over udp

From: Yuchung Cheng <[email-masked]>
Date: Thu, 11 Jul 2013 15:39:04 -0700

http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 makes sense!

Another big advantage of tcp-over-udp is the ability to run user-mode
stack on any OS, allowing (much) faster software updates. For example,
many Linux clients are still running old kernels that don't support
Fast Open :|

Yuchung

---

From: Christian Huitema <[email-masked]>
Date: Fri, 12 Jul 2013 03:53:53 +0000

> http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 makes sense!

It certainly does, and I see the point of a transport protocol that works through NAT. But the draft leaves a big question unaddressed. How is the connection supposed to be set up? How does the remote party know that it should use TCP over UDP?

The draft specifies using ICE, and it also specifies that the TCP over UDP endpoint is identified by the UDP port. But ICE operates by using multiple UDP ports, in order to traverse NAT. The endpoint identifier in ICE is typically a SIP endpoint. How is that supposed to work, exactly?

> Another big advantage of tcp-over-udp is the ability to run user-mode stack on any OS, allowing (much) faster software updates. For example, many > Linux clients are still running old kernels that don't support Fast Open :|

I am not sure that the "application bringing its own stack" is the best argument for TCP over UDP. Applications that need such functions already have the choice of incorporating their own transport, e.g. uTP. The real value is to "reuse well tested TCP implementations." But then the draft should say something about interop between TCP/UDP and TCP/IP...

-- Christian Huitema

---

From: Brian Trammell <[email-masked]>
Date: Fri, 12 Jul 2013 13:17:20 +0200

Greetings, all,

As someone who's followed RFC 6951, due to similar frustration with SCTP's interaction with dodgy middleboxes, I'm (half-facetiously) beginning to wonder whether it makes sense to discuss TCP over UDP on a public mailing list, and publish the details thereof as Internet-Drafts, where any dodgy middlebox implementor might be able to read them, and correct its implementation to break TCP over UDP over IP as well, to maintain compatibility with its broken behavior on TCP over IP, thereby necessitating TCP over UDP over UDP over IP, and so on.

That said, I could see this escalation in the arms race being useful outside the NAT context as well; e.g. supporting multiple separate TCP stacks on the same machine without requiring virtualization (though I can't at the moment think of any not-terrible reason for doing this beyond congestion-control performance experiments). And aside from the _usefulness_ of it in any event, I appreciate the coolness of the hack. :)

A couple of other minor points to consider:

(1) Section 4 specifies a packet format reserving the high nybble value 0x4 for "other transport protocols", so that 0x5-0xf (data offset in the reordered TCP header) can be used to mean "TCP". This does not seem to be compatible with RFC 6951, which sticks an SCTP header directly after the UDP header without reordering: this is the high nybble of the SCTP source port number, which has a 1/16 chance of being 0x4 all other things being equal.

Given that RFC 6951 and this draft have somewhat different assumptions (here there's an overlap between UDP and TCP port space, while 6951 assumes an "SCTP port" for UDP at a given network address), it's not really clear that this is a problem. But the mention of SCTP in section 4 might be read as a proposal that this is an attempt to specify another SCTP over UDP encap incompatible with the first one, which seems a little odd.

(2) The draft seems to make the implicit assumption that if TCP port X is service foo, then UDP port X is free to be used as an overlapping port. This is not the case for e.g. IPFIX, which uses (by default) tcp/4739, udp/4739, and sctp/4739, and may actually be listening on all three of these.

This might be a special case, though; I've spent way too much time paying attention to IPFIX.

Cheers,

Brian

On 12 Jul 2013, at 5:53 , Christian Huitema <[email-masked]> wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 12 Jul 2013 13:33:29 +0200

> As someone who's followed RFC 6951, due to similar frustration with SCTP's interaction with dodgy middleboxes, I'm (half-facetiously) beginning to wonder whether it makes sense to discuss TCP over…
The usecase for SCTP over UDP is to allow userland stack (like in the case for TCP over UDP) and
to provide NAT traversal for NATs not supporting SCTP (properly). However, the SCTP aware NAT
ID isn't still an RFC, so here is a difference to the TCP case. 
> (1) Section 4 specifies a packet format reserving the high nybble value 0x4 for "other transport protocols", so that 0x5-0xf (data offset in the reordered TCP header) can be used to mean "TCP". Thi…
This is correct. In the SCTP case we can't just reuse the UDP port numbers also as the SCTP port numbers.
This would only be possible for single homed SCTP associations. For multihomed associations,
each endpoint has multiple IP-addresses, but a single port number. So only using the UDP port
numbers would require all NAT boxes on different paths to sync the port number translation.
Something which will not happen. Therefore RFC 6951 has a complete UDP header with port numbers
the NAT boxes can change and a complete SCTP common header with SCTP port numbers the NAT box
won't touch. I hope this makes it clearer why RFC 6951 doesn't reuse the UDP port numbers.
> Given that RFC 6951 and this draft have somewhat different assumptions (here there's an overlap between UDP and TCP port space, while 6951 assumes an "SCTP port" for UDP at a given network address)…
Correct. If you want to multiplex/demultiplex SCTP and ICE, you would have to restrict the source / destination
port number usages...
> (2) The draft seems to make the implicit assumption that if TCP port X is service foo, then UDP port X is free to be used as an overlapping port. This is not the case for e.g. IPFIX, which uses (by…
Correct. The UDP and TCP port numbers are normally handled independently.
> This might be a special case, though; I've spent way too much time paying attention to IPFIX.
Best regards
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 12 Jul 2013 15:41:32 +0200

So,

This is pretty similar to:
http://www.remlab.net/op/draft-denis-udp-transport-00.txt
which also didn't address the necessary bits that Christian points out below. I wonder, what happened to this previous proposal, did the author not follow up or wasn't there enough interest?

It could be useful to learn from history here.

Cheers,
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 12 Jul 2013 16:02:35 +0200

> It could be useful to learn from history here.

It won't work for SCTP with multihoming since the UDP ports (which possibly
gets changed on multiple paths without coordination between the NAT box) are also
interpreted as the SCTP ports. Same issue as with draft-cheshire-tcp-over-udp-00
and the reason why we have duplicated port numbers in RFC 6951.

Best regards
Michael

---

From: Brandon Williams <[email-masked]>
Date: Fri, 12 Jul 2013 11:15:03 -0400

w.r.t. the draft's use of ICE, I'm uncertain as to whether it could 
break ICE for this proposal to explicitly reuse 0x4-0x7 in the first 
four bits for a purpose other than TURN channel identification. The 
draft should probably address this question. IIRC, 0x8-0xF are not used 
for any purpose in ICE or an associated protocol, so they could 
conceivably be used without risk of conflict.

--Brandon Williams

-- 
Brandon Williams; Principal Software Engineer
Cloud Engineering; Akamai Technologies Inc.

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Jul 2013 15:09:11 -0700

A big disadvantage is that middleboxes don't know when to tear down state.

And why would this work through a NAT better than TCP?

Sure, it makes sense to run non-TCP transports over UDP (to avoid CC 
interactions, and to enable NAT traversal for unsupported transports 
such as SCTP), but doing this for TCP doesn't make sense.

If you want to run TCP out of user space, then just open a raw IP 
socket. If you're running things that provide services on ports <1024, 
you ought to have root anyway.

Others have noted more than a few problems with the port number 
assumptions in this doc:
	- not all services that are assigned TCP ports are also
	assigned corresponding UDP ports
	- in some cases, the UDP port of a service is already actively
	used
	- in some recent cases, the matching UDP port is assigned '
	only for a discovery service, which could already be running

Other issues:
	UDP allows a zero checksum (IPv4), but TCP does not

Joe