Re: [multipathtcp] Questions on fallback/infinite map

[Anumita Biswas <[e-mail]>]

MP_FAIL and Infinite map options can be dropped in just the way that the DSS option (all being option 30) was dropped by the middlebox. So when we are talking of a fallback situation caused by a drop of DSS option, sending MP_FAIL and infinite mapping is good practice but not gauranteed to get the endpoints to a good sync point. MP_FAIL and infinite mapping are more useful when DSS checksum failure occurs - which is a case where options aren't dropped, but data is segmented/reassembled by middle boxes.

Instead, I think we have to break this down into how many subflows exist and make a call based on that.

1. If a single subflow exists, the data is contiguous, so even if no DSS option is received, the data can be accepted. This is true of both senders in a bi-directional connection. I think the RFC also suggests special casing the single subflow case to accept data as being contiguous in both the subflow level and data sequence space level. But this also assumes that the MPTCP layer does not retransmit unacked data on the same subflow - because this breaks the contiguous property of a single subflow. 

2. If multiple subflows exist, and both paths are known to be functional (connected), then when a receiver receives data without the DSS option, then the fully mp capable subflow can be used to fallback with MP_FAIL(from receiver) and Infinite mapping(from sender).

3. In an active/backup mptcp session, where one subflow is used more frequently than another, fallback is more complicated. If data is received on backup path without DSS, when it is known that the primary path is fully mp capable and has not been removed with a REMOVE_ADDR, an attempt can be made to fallback on the primary path. However, if the primary path is no longer available, and the backup path has not sent a REMOVE_ADDR to indicate the loss of primary path, then fallback won't occur correctly. In that case, the MP_FAIL sent down the primary path won't be received by the data sender. It will also not be clear where the backup path is in the Data Sequence space. But the assumption here is that when MP_FAIL is sent on the primary path, the backup path is RST as per RFC. The non-functional primary path will eventually be detected and the MPTCP connection closed/reset. Its ok to let the connection die in this degenerate case - in my view applications and apis supporting them should be capable of handling connection errors already. 

4. In an active/backup mptcp session, if a REMOVE_ADDR was received on a path and it is known that there is only one subflow left in the session, it could be considered to be case 1 above. 

Whatever data is outstanding on the network when fallback occurs, it is expected to fall into one of the cases above - with data being accepted on a single subflow, and data being discarded in presence of multiple subflows, when it arrives without DSS option. It does make the implementation complex to track whether a session has one or multiple subflows but it improves the chances of recovering from lost options in a single subflow scenario.

Until middleboxes are MPTCP compliant, I think it probably makes sense to have the overhead of sending Data ACKs whenever the subflow level ACK also acks new data. Window updates, Keepalives and MPTCP signals like MP_PRIO probably don't need to have Data ACKs.

For a sender that receives subflow level ACKs but no Data ACKs, fallback could be achieved by sending infinite mapping on a known fully MP capable subflow path. Depending on number of subflows on the session, it can fall into one of the cases above to do fallback:

5. If a single subflow exists, data is contiguous, so move the right edge of the Data Sequence Space to match the right edge of the subflow level send window. 

6. If multiple subflows exist, and both paths are known to be functional (connected), send infinite mapping on a known fully mp capable path. Close other subflows.

7. In an active/backup mptcp session, where one subflow is used more frequently than another, follows a similar scheme as Case 3 and Case 4 above except send Infinite Mapping instead of MP_FAIL.

Anumita


On Jun 26, 2013, at 2:33 AM, Krishna Khanal <[e-mail]> wrote:

> Thanks Costin, Yoshifumi for the information.
> 
> For case 2, yes from my implementation/testing experience also its better to fallback in both the direction, but the problem here is that the host A may not have knowledge of from which DSN to start infinite map if there are some unacked packets already on the way because host B may not send MP_FAIL with expected DSN in this case. The simple solution here is to resend all the unacked data with the infinite map in the first packet and if B has already received that data, it can send the corrected DATA_ACK until it receives infinite map with that DSN. This will guarantee both hosts are in sync at mptcp level. Please suggest if there are any alternate way to make sure host A and B are in sync in this situation.
> 
> Regards,
> Krishna
> 
> 
> -----Original Message-----
> From: Costin Raiciu [mailto:[e-mail]] 
> Sent: Wednesday, June 26, 2013 2:48 PM
> To: Krishna Khanal
> Cc: [e-mail]
> Subject: Re: [multipathtcp] Questions on fallback/infinite map
> 
> Hi Krishna,
> 
>> 1. What is the recommended action when a host receives a plain ack or data in the middle of transaction and there is a single subflow? RFC has taken care of receiving plain data or ack before the path is mptcp confirmed but I don't see any recommendation when it happens on middle of transaction.
> 
> Two cases:
> - data segment without mptcp options - the segment should be accepted if it is (subflow) window, and a subflow ACK covering the sequence numbers should be generated. The data obviously cannot be  placed into the connection level receive buffer, since we don't know its mapping. One option is to just drop the data and force the sender to retransmit. Another option, which is used by the Linux implementation, is to save the data in the subflow receive window
> and wait to see if a mapping for that   data arrives on subsequent segments.
> - ack without mptcp options - no problem here; the ack is just processed normally if it is in the subflow's window, as with regular tcp. We didn't want to mandate that all acks carry the Data ACK because in some cases (e.g. unidirectional data transfer) we would be just wasting option space.
> 
>> 2. Is infinite map/mp_fail unidirectional or bidirectional? Lets suppose host A sends mp_fail to host B, host B will send infinite map to host A and after that there is no DSS on the data packets from B to A and host A will send only plain ack to B. But lets suppose host A also has some data to send to host B, can host A still use DSS and host B can send data ack in this case? I don't see RFC mentioning any recommended action in this case, so I believe host A can still use DSS with data and host B can send data ack.
> 
> The spec allows for fallback in only one direction, but in practice I suspect both directions will be affected by the middlebox that cause the fallback. So it makes sense, as an implementation heuristic, to fall back to TCP in both directions as soon as one direction is problematic.
> 
> Cheers,
> Costin
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp