As reported by Paolo at the last meeting, Packetdrill can coalesce some TCP packets, but it can be problematic: it ignores MPTCP options, aggregate packets that are not continuous from MPTCP view, keeping the DSS option from the first packet
The root cause is that the packetdrill core tries to aggregate eligible TCP packets and can replace the wire packet with the aggregate one to fit the drill under test.
The problem is that the aggregation support is partial/buggy: packets with the same tcp options len, but different tcp options contents will be considered eligible for aggregation, and the aggregate packets will carry the options for the 1st pkt on the wire.
The above works e.g. with tcp stamp options, but does not work with mptcp: packets with different DSS are aggregated carrying the DSS from the 1st one. Note that this is different from what the GRO engine is doing and attempts to mimic what the TCP stack coalescing is doing. With the major difference that such coalescing merges correctly different DSS.
One suggested option: patch packetdrill to fix MPTCP DSS options of the coalesced packet:
we don't care about the data that are carried, so we could aggregate non continuous packets from an MPTCP point of view
but the code is quite "complex" → TCP header matching code only checking that the length of the TCP options are the same, look at: run_packet.c:verify_tcp
Maybe there are other options? (forcing packetdrill not to do that at all?)
As reported by Paolo at the last meeting, Packetdrill can coalesce some TCP packets, but it can be problematic: it ignores MPTCP options, aggregate packets that are not continuous from MPTCP view, keeping the DSS option from the first packet
See: https://github.com/multipath-tcp/packetdrill/pull/132
One suggested option: patch packetdrill to fix MPTCP DSS options of the coalesced packet:
run_packet.c:verify_tcpMaybe there are other options? (forcing packetdrill not to do that at all?)
Once a solution has been found, revert: https://github.com/multipath-tcp/packetdrill/pull/133