The infinite mapping support: kernel side

[geliangtang]

Split from #52 "MP_FAIL support", to deal with the single subflow case MP_FAIL.

As defined in RFC8684, 3.7 Fallback:

A special case is when there is a single subflow and it fails with a checksum error. If it is known that all unacknowledged data in flight is contiguous (which will usually be the case with a single subflow), an infinite mapping can be applied to the subflow without the need to close it first, essentially turning off all further MPTCP signaling. In this case, if a receiver identifies a checksum failure when there is only one path, it will send back an MP_FAIL option on the subflow-level ACK, referring to the data-level sequence number of the start of the segment on which the checksum error was detected. The sender will receive this information and, if all unacknowledged data in flight is contiguous, will signal an infinite mapping. This infinite mapping will be a DSS option (Section 3.3) on the first new packet, containing a Data Sequence Mapping that acts retroactively, referring to the start of the subflow sequence number of the most recent segment that was known to be delivered intact (i.e., was successfully DATA_ACKed). From that point onward, data can be altered by a middlebox without affecting MPTCP, as the data stream is equivalent to a regular, legacy TCP session. While in theory paths may only be damaged in one direction -- and the MP_FAIL signal affects only one direction of traffic -- for simplicity of implementation, the receiver of an MP_FAIL MUST also respond with an MP_FAIL in the reverse direction and entirely revert to a regular TCP session.

https://www.rfc-editor.org/rfc/rfc8684.html#section-3.7-11

---

TODO list

• Improvements around the tests for patch 8/8:
  • Comment around the TC command
  • Add 'tcp_flags 0x10/0xff'
  • Comment around the parsing (example of what you are parsing)
  • Break if jq returns 'null' or nothing.
  • Sleep in the while loop for "tc show"
  • Look for "pedit" counter ("packets" - "overlimits")
  • Not compare the output file if it is normal they are different
  • Remove/Reduce data sent by the host not having the tc command (send only in one direction)
  • Insert the TC rules, then start the test, then look at counters
  • Force checksum=1 for "fail_tests()"
• "MP_FAIL echo" MP_FAIL echo and retrans #261
• "MP_FAIL retrans" MP_FAIL echo and retrans #261
• Drop more data from the receive queue c.f. https://lore.kernel.org/mptcp/[email protected]/T/#u
• packetdrill tests Packetdrill: add MP_FAIL coverage #266

[mjmartineau]

Regarding mailing list review at https://lore.kernel.org/mptcp/[email protected]/ here's the relevant pcap:

mp_join-01-ns1-0-nxL4ZI.pcap.gz

[matttbe]

(I just updated the TODO list in the initial message. Feel free to check points when done and/or add new one ;-) )

TODO list

• Drop more data from the receive queue c.f. discussions with Mat and Christoph on the ML on v7
• Improvements around the tests for patch 8/8:
  • Comment around the TC command
  • Add 'tcp_flags 0x10/0xff'
  • Comment around the parsing (example of what you are parsing)
  • Break if jq returns 'null' or nothing.
  • Sleep in the while loop for "tc show"
  • Look for "pedit" counter ("packets" - "overlimits")
  • Not compare the output file if it is normal they are different
  • Remove/Reduce data sent by the host not having the tc command (send only in one direction)
  • Insert the TC rules, then start the test, then look at counters
  • Force checksum=1 for "fail_tests()"
• "MP_FAIL echo"
• "MP_FAIL retrans"
• packetdrill tests

[geliangtang]

Mat's comments about the infinite mapping on Oct 22 2021:

---

For "infinite mapping fallback", there seem to be two separate parts of
fallback to keep track of:

• Transmit fallback: This peer has sent an infinite mapping already
  (after receiving an MP_FAIL) and should not send any new MPTCP options.

• Receive fallback: This peer has received an infinite mapping, and will
  ignore MPTCP options on all incoming packets.

The RFC does say that a receiver of MP_FAIL must send an MP_FAIL so both
directions fall back, but with packets in flight there's still some time
where fallback has only happened in one direction:

1. Peer A sends MP_FAIL
2. Peer B receives MP_FAIL
3. Peer B sends MP_FAIL (on an ack or data packet) and infinite mapping
   (on next data packet)
   • Peer B enters "transmit fallback" at this time.
4. Peer A receives MP_FAIL, sends infinite mapping on next data packet.
   • Peer B enters "transmit fallback" when sending infinite mapping
5. Peer A receives infinite mapping
   • Peer A enters "receive fallback", fallback complete on this peer
6. Peer B receives infinite mapping
   • Peer B enters "receive fallback", fallback complete on this peer

Steps 4 and 5 could be reversed, we can't assume which order Peer B will
send the mapping and the MP_FAIL.

Another layer of complexity is that MP_FAIL can be lost if it's not in a
data packet, so we probably need to keep sending MP_FAIL until an infinite
mapping is received (like multipath-tcp.org does). This also implies that
the receive code should ignore repeated MP_FAILs.

I also noticed that the multipath-tcp.org kernel does something
interesting with connections that are entering fallback with MP_FAIL:
packets that contain a regular mapping (not infinite) are dropped after
MP_FAIL is sent but an infinite mapping has not been received yet. Look at
mptcp_detect_mapping() and "Ignore packets which do not announce fallback"
comment text in mptcp_input.c.

I think the reasoning may be that the bad checksum that triggered the
MP_FAIL has dropped some data, so to get the data stream back in a good
state we need to wait for the infinite mapping as a signal that the other
peer received the MP_FAIL and has resent data starting from the last
DATA_ACKed byte.

---

[matttbe]

the packetdrill part will be done as part of #266