[songgao]

Right. What I'm saying is that, by keeping alive both path, you need to use some traffic. Although when there's WiFi available, you are primarily using WiFi, there are traffic going through cellular network in order to keep the path alive.

[signa11]

would be really cool if slower / more expensive connections could ultimately be drained, and the whole data transfer just switches over to a single more faster connection.

edit-1: note that this is not the same as subflow 'deletion' that would happen if an access mechanism was not available at all.

edit-2: section-3.4 of the mptcp paper indicates that FIN has a more limited 'no more data on this subflow' semantics. so, in theory it should be possible to do just that. would be so much better to not go the ANDSF route at all ;)

[songgao]

Hey! I didn't go into that deep! So if FIN is used in a subflow, does it terminate that path? Is it possible to wake this path up again?

[signa11]

the shorter answer first: i don't think there is any possibility of resurrecting a subflow once it is gone.

longer one: with mptcp, there needs to be some way to distinguish connection-teardown vs subflow-teardown. with, RST the subflow is terminated. FIN is more subtle (since it occupies the sequence space in normal tcp) however. FIN is handled via an explicit DATA-FIN within TCP option to indicate the end of data-sequence-space (which maps subflow sequence numbers to data sequence numbers in TCP options). gracefully terminating a connection, thus involves sending DATA-FIN on all subflows together with a FIN.