[e2e] Can we revive T/TCP ?

[Mark Handley]

On 3/25/06, Michael Welzl <michael.welzl at uibk.ac.at> wrote:
> The delay of these function calls (which is apparently the result
> of SOAP processing more than anything else, but connection
> setup can also take a while if nodes are very far from each other -
> which, for instance, is true for some nodes in the EGEE Grid)
> limits the parallelization granularity in Grids - reducing it would
> be a real win in my opinion.

I think the right solution to the T/TCP problem would be to clone an
existing connection.  This would remove most of the security issues,
and let you bootstrap the congestion control state.

Suppose you have an existing connection from A port p1 to B port p2. A
then wants a new connection, so it sends a message from A port p3 to B
port p2, with the SYN bit set, and a "connection clone" option that
gives port p1 and the current sequence number from the first
connection, together with the first mss of data.

Basically this is data that could have been sent on the first
connection anyway, but demuxing it at the TCP layer makes more sense
for many applications.

As this is a cloned connection, the congestion control state in both
directions can be copied from the first connection (duplicate the RTT,
split cwnd between the two), so there's no need to slowstart, and no
startup transients to disrupt other network traffic.
You can also clone all negotiated options from the first connection,
which is another problem with the original T/TCP.

[Note: as described above, this wouldn't work too well though NATs. 
If we care about this, A simply needs a way to find out port p1 from
B]

 - Mark