[e2e] Can we revive T/TCP ?

Joe Touch touch at ISI.EDU
Tue Mar 28 16:45:21 PST 2006

Hash: SHA1

Mark Handley wrote:
> 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.

That works even for non-cloned connections - e.g., it's what was
described in RFC-2140. ;-)

However, why doesn't cloning require a handshake? I.e., if you send the
data, don't you still need to cache it until the connection is confirmed?

The only benefit seems to be with the sequence numbers; I recall some
trick like this for T/TCP too...

Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the end2end-interest mailing list