Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

packetdrill: coalescing feature doesn't take into account MPTCP options #476

Open
matttbe opened this issue Feb 15, 2024 · 0 comments
Open

Comments

@matttbe
Copy link
Member

matttbe commented Feb 15, 2024

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.

See: multipath-tcp/packetdrill#132

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?)

Once a solution has been found, revert: multipath-tcp/packetdrill#133

matttbe pushed a commit to pabeni/packetdrill that referenced this issue Feb 22, 2024
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant