[OpenAFS-devel] Rx over TCP to solve some NAT & Firewall issues?

[Dean Anderson]

On Thu, 20 Nov 2003, Nickolai Zeldovich wrote:

> 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.

Err, as long as the out of order packets arrive before the retransmit
timeout on the window, nothing happens.  Selective ACK allows you to get
packets in the middle of a window which are lost.

Load balancing and normal route changes in core networks guarentees that
some packets will arrive out of order over a WAN.

Per-flow route caching is not intended to insure the order of packets, but
improve the performance of route table lookup and acl processing.

> 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.

A thread is waiting for the socket to be closed before those resources can
be reused.  You are waiting for it just like you wait for that other
process to be swapped out.

		--Dean