Joe,
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)
TCP is intended to protect TCP, not turn all TCP users into
Multipath-lite users.
With this kind of mechanism, a TCP variant can have the ability to react
to spurious resets.
Only if you substantively protect those connection ID tokens. Which
means you're protecting "header" information - and you;ave' made it
worse by protecting a header that doesn't even exist yet.
>
It's a lot easier to protect the headers we alredy have.
The key issue is when there is a middlebox on the path and that
middlebox sees a spoofed RST (without checking any authentication in the
RST) and reacts by removing state for the associated connection. Event
if the the endhost ignore the RST because it does not contain any
authentication, the connection is blocked in the middle of the network.
At this point, there are two options :
- TCP informs the application that the connection is gone and the
application is assumed to be intelligent to restart a new connection
(and resend all the data sent over the previous connection)
- TCP restarts a new connection without informing the application and
the bytestream continues without any interruption. This requires some
form of connection id that is negotiated at the beginning of the
connection and exchanged during the establishment of the second connection.
I believe that most application developpers will prefer the second
solution to the first one.
Olivier
--
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
