You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?)
Based on epoll_out_edge_notsent_lowat.pkt, with some adaptation to cope
with MPTCP specificities.
Note that this will cause some random failures around line 43.
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. See verify_tcp() in
run_packet.c.
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.
TL;DR: to solve the failures for good non trivial changes to the core
are required, but sharing the drill early to somewhat covers the pending
kernel patches.
Link: multipath-tcp/mptcp_net-next#476
Signed-off-by: Paolo Abeni <pabeni@redat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
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: multipath-tcp/packetdrill#132
One suggested option: patch packetdrill to fix MPTCP DSS options of the coalesced packet:
run_packet.c:verify_tcp
Maybe there are other options? (forcing packetdrill not to do that at all?)
Once a solution has been found, revert: multipath-tcp/packetdrill#133
The text was updated successfully, but these errors were encountered: