From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <kuniyu@amazon.com>
Cc: <davem@davemloft.net>, <edumazet@google.com>,
<kerneljasonxing@gmail.com>, <kuba@kernel.org>,
<kuni1840@gmail.com>, <netdev@vger.kernel.org>,
<pabeni@redhat.com>
Subject: Re: [PATCH v2 net-next] tcp: Refine SYN handling for PAWS.
Date: Wed, 29 Mar 2023 13:07:30 -0700 [thread overview]
Message-ID: <20230329200730.78159-1-kuniyu@amazon.com> (raw)
In-Reply-To: <20230328184257.62219-1-kuniyu@amazon.com>
From: Kuniyuki Iwashima <kuniyu@amazon.com>
Date: Tue, 28 Mar 2023 11:42:57 -0700
> Our Network Load Balancer (NLB) [0] has multiple nodes with different
> IP addresses, and each node forwards TCP flows from clients to backend
> targets. NLB has an option to preserve the client's source IP address
> and port when routing packets to backend targets. [1]
>
> When a client connects to two different NLB nodes, they may select the
> same backend target. Then, if the client has used the same source IP
> and port, the two flows at the backend side will have the same 4-tuple.
>
> While testing around such cases, I saw these sequences on the backend
> target.
>
> IP 10.0.0.215.60000 > 10.0.3.249.10000: Flags [S], seq 2819965599, win 62727, options [mss 8365,sackOK,TS val 1029816180 ecr 0,nop,wscale 7], length 0
> IP 10.0.3.249.10000 > 10.0.0.215.60000: Flags [S.], seq 3040695044, ack 2819965600, win 62643, options [mss 8961,sackOK,TS val 1224784076 ecr 1029816180,nop,wscale 7], length 0
> IP 10.0.0.215.60000 > 10.0.3.249.10000: Flags [.], ack 1, win 491, options [nop,nop,TS val 1029816181 ecr 1224784076], length 0
> IP 10.0.0.215.60000 > 10.0.3.249.10000: Flags [S], seq 2681819307, win 62727, options [mss 8365,sackOK,TS val 572088282 ecr 0,nop,wscale 7], length 0
> IP 10.0.3.249.10000 > 10.0.0.215.60000: Flags [.], ack 1, win 490, options [nop,nop,TS val 1224794914 ecr 1029816181,nop,nop,sack 1 {4156821004:4156821005}], length 0
>
> It seems to be working correctly, but the last ACK was generated by
> tcp_send_dupack() and PAWSEstab was increased. This is because the
> second connection has a smaller timestamp than the first one.
>
> In this case, we should send a dup ACK in tcp_send_challenge_ack()
> to increase the correct counter and rate-limit it properly.
>
> Let's check the SYN flag after the PAWS tests to avoid adding unnecessary
> overhead for most packets.
>
> Link: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html [0]
> Link: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#client-ip-preservation [1]
> Fixes: 0c24604b68fc ("tcp: implement RFC 5961 4.2")
Sorry, I forgot to remove Fixes tag.
I'll post v3.
prev parent reply other threads:[~2023-03-29 20:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 18:42 [PATCH v2 net-next] tcp: Refine SYN handling for PAWS Kuniyuki Iwashima
2023-03-29 20:07 ` Kuniyuki Iwashima [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230329200730.78159-1-kuniyu@amazon.com \
--to=kuniyu@amazon.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=kuni1840@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.