[OpenAFS-devel] Rx over TCP to solve some NAT & Firewall issues?
Nickolai Zeldovich
kolya@MIT.EDU
Thu, 20 Nov 2003 17:52:37 -0500 (EST)
On Thu, 20 Nov 2003, Dean Anderson wrote:
> Err, I'm not following you above. Packets _can_ be reordered, especially
> on a wide area network, so I don't see what the problem there is with
> 'still making this assumption'.
I don't think today's TCP implementations work well in the presence of
packet reordering. As a result, today's networks specifically try to
avoid packet reordering by various mechanisms like per-flow route caching
when multiple links are available. I believe that most TCPs (e.g. Reno-,
Vegas-style) do packet retransmission when they get dup ACKs. In the end
it comes down to the probability of a packet being lost vs reordered; I
believe the latter is negligibly small today.
> > Do people really think that Rx over UDP, designed 15 years ago, can be
> > a better reliable stream transport than the TCP in today's kernels?
> > What features of Rx over UDP are so unique that preclude the use of
> > TCP?
>
> Socket setup time is much shorter with UDP. Cleanup time is also much
> shorter.
Right now you end up having a round-trip when you establish a UDP Rx
connection, due to the challenge/response. So I suppose we'll have two
round-trips at connection establishment time with TCP Rx. But this extra
round-trip time would only happen once per client/server (modulo servers
deciding to clean up idle cxns), so perhaps it's still acceptable.
I'm not sure why the cleanup time would matter much. Noone is waiting for
it to complete.
-- kolya