[e2e] Can we revive T/TCP ?

[Bob Briscoe]

Mark,

There's a wrinkle that argues against demux at the TCP layer, and instead 
argues for demux at the app layer in these cases: Equal Cost Multipath 
Routing (ECMP).

Some vendor implementations of ECMP forward flows deterministically on the 
same path by hashing packets based on ip addr & port numbers to choose 
which interface to forward out of. Others ignore port numbers. But changing 
port numbers can mean your packet ends up crossing different routes. So, 
changing port numbers can imply the congestion information learned from the 
previous connection is no longer valid.

The alternative is to be more prescriptive by saying ECMP algorithms MUST 
NOT use port numbers, but these algs are already out there.

Another answer is encryption, to stop these boxes fishing around where they 
have no business anyway. Or you could use a role-based architecture :)


Bob



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

____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196