diff options
| author | Christoph Paasch <cpaasch@apple.com> | 2020-05-14 18:53:03 +0300 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2020-05-16 23:51:10 +0300 |
| commit | a0c1d0eafd1ef1ada3b588ea205e5bc37ae0d8d9 (patch) | |
| tree | 9e6c4e1406a00559b1dd4ef04cf502d65e5cb3e7 /net/mptcp/subflow.c | |
| parent | 9efd6a3cecdde984d67e63d17fe6af53c7c50968 (diff) | |
| download | linux-a0c1d0eafd1ef1ada3b588ea205e5bc37ae0d8d9.tar.xz | |
mptcp: Use 32-bit DATA_ACK when possible
RFC8684 allows to send 32-bit DATA_ACKs as long as the peer is not
sending 64-bit data-sequence numbers. The 64-bit DSN is only there for
extreme scenarios when a very high throughput subflow is combined with a
long-RTT subflow such that the high-throughput subflow wraps around the
32-bit sequence number space within an RTT of the high-RTT subflow.
It is thus a rare scenario and we should try to use the 32-bit DATA_ACK
instead as long as possible. It allows to reduce the TCP-option overhead
by 4 bytes, thus makes space for an additional SACK-block. It also makes
tcpdumps much easier to read when the DSN and DATA_ACK are both either
32 or 64-bit.
Signed-off-by: Christoph Paasch <cpaasch@apple.com>
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/mptcp/subflow.c')
| -rw-r--r-- | net/mptcp/subflow.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 53c75b0e5dce..0020d356233d 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -667,9 +667,11 @@ static enum mapping_status get_mapping_status(struct sock *ssk) if (!mpext->dsn64) { map_seq = expand_seq(subflow->map_seq, subflow->map_data_len, mpext->data_seq); + subflow->use_64bit_ack = 0; pr_debug("expanded seq=%llu", subflow->map_seq); } else { map_seq = mpext->data_seq; + subflow->use_64bit_ack = 1; } if (subflow->map_valid) { |