Re: [PATCH v2 net-next] tcp: introduce a new MIB for CLOSE-WAIT sockets

[Jason Xing <kerneljasonxing@gmail.com>]

Hello Eric，

On Wed, May 29, 2024 at 11:42 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Wed, May 29, 2024 at 5:31 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
> >
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > CLOSE-WAIT is a relatively special state which "represents waiting for
> > a connection termination request from the local user" (RFC 793). Some
> > issues may happen because of unexpected/too many CLOSE-WAIT sockets,
> > like user application mistakenly handling close() syscall. It's a very
> > common issue in the real world.
> >
> > We want to trace this total number of CLOSE-WAIT sockets fastly and
> > frequently instead of resorting to displaying them altogether by using:
> >
> >   ss -s state close-wait
> >
> > or something like this. They need to loop and collect required socket
> > information in kernel and then get back to the userside for print, which
> > does harm to the performance especially in heavy load for frequent
> > sampling.
> >
> > That's the reason why I chose to introduce this new MIB counter like
> > CurrEstab does. With this counter implemented, we can record/observe the
> > normal changes of this counter all the time. It can help us:
> > 1) We are able to be alerted in advance if the counter changes drastically.
> > 2) If some users report some issues happening, we will particularly
> > pay more attention to it.
> >
> > Besides, in the group of TCP_MIB_* defined by RFC 1213, TCP_MIB_CURRESTAB
> > should include both ESTABLISHED and CLOSE-WAIT sockets in theory:
> >
>
> We (Neal and myself) prefer to fix TCP_MIB_CURRESTAB to include
> CLOSE_WAIT sockets.
> We do not think it will annoy anyone, please change tcp_set_state() accordingly.

Thanks for your reply. Honestly, I was worried about what you said.
Now, I'm relieved.

It seems that I should add a Fixes: tag...

>
> Rationale is that adoption of a new MIB in documentations and various
> products will take years.
>
> Also make a similar change for mptcp.

I will check that part tomorrow morning, too.

Thank you :)

Jason