or data for more than the initial window: this implies a DATA_ACK has been received from the other side.
Reason: If we fallback after that point, there is a risk of corruption: even if that looks weird, an implementation could do a reinjection at the MPTCP level on the same subflow, so from TCP point of view, that's considered as new data (I guess it's an issue if this re-injection is done when the fallback is going to happen).
I suggest not to change the "fully established" logic to continue allowing sending ADD_ADDR ASAP, etc.: if it is received and a new subflow is created, we can also consider this as "MPTCP has been verified". IOW, I suggest continuing using allow_infinite_fallback, but it should be disabled once "MPTCP has been verified".
This is what is recommended (SHOULD) by the RFC.
"MPTCP has been verified" means:
DATA_ACKhas been received from the other side.Reason: If we fallback after that point, there is a risk of corruption: even if that looks weird, an implementation could do a reinjection at the MPTCP level on the same subflow, so from TCP point of view, that's considered as new data (I guess it's an issue if this re-injection is done when the fallback is going to happen).
I suggest not to change the "fully established" logic to continue allowing sending
ADD_ADDRASAP, etc.: if it is received and a new subflow is created, we can also consider this as "MPTCP has been verified". IOW, I suggest continuing usingallow_infinite_fallback, but it should be disabled once "MPTCP has been verified".(Linked to #518)