Joe,
I don't think "don't protect the headers" is an accurate description
of Honolulu if it also leaves the system exposed to resets, as there
clearly was a fair amount of concern expressed about spurious resets.
IMO, the best approach to deal with suprious resets, caused by
middleboxes, attackers or whatever, is to use the same approach as in
Multipath TCP by considering a TCPINC connection to be composed of
several subflows.
TCPINC isn't limited to Multipath TCP, thus that approach is inappropriate.
I know the charter of the TCPINC working group. When I write "use the
same approach as in Multipath TCP by considering a TCPINC connection to
be composed of several subflows" I mean include in TCPINC a mechanism
that contains :
- a form of connection id as the tokens used in Multipath TCP
- a way to enable a TCP connection to be composed of a series of TCP
connections (i.e. the datastream that started on the previous subflow
continues on the next one)
With this kind of mechanism, a TCP variant can have the ability to react
to spurious resets. It is possible to use for the design of TCPINC the
various lessons that have been learned during the design of Multipath
TCP even if the requirements are different.
Olivier
--
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
