why does tcp_v[46]_conn_request not inc MIB stats

why does tcp_v[46]_conn_request not inc MIB stats

[Rick Jones]

I've been digging around to see about inducing /proc/net/tcp to show 
some "interesting" things for listen sockets (eg backlog depth, its max, 
and dropped connection requests).  While there I've noticed that both 
tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the 
listen queue is full, but only tcp_v[46]_syn_recv_sock increments some 
mib stats for dropped connection requests.

Is that deliberate, or is that a hole in the stats?

rick jones

Re: why does tcp_v[46]_conn_request not inc MIB stats

[Sridhar Samudrala]

On Mon, 2007-09-10 at 11:42 -0700, Rick Jones wrote:
> I've been digging around to see about inducing /proc/net/tcp to show 
> some "interesting" things for listen sockets (eg backlog depth, its max, 
> and dropped connection requests).

backlog depth(acceptq length) for a listening socket should be available
with the newer kernels. The following patch exports this value via the rx_queue
field in /proc/net/tcp.
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=47da8ee681d04e68ca1b1812c10e28162150d453

>   While there I've noticed that both 
> tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the 
> listen queue is full, but only tcp_v[46]_syn_recv_sock increments some 
> mib stats for dropped connection requests.
> 
> Is that deliberate, or is that a hole in the stats?

looks like it is a hole in the stats. I think we should increment
LISTENOVERFLOWS or LISTENDROPS in tcp_v[46]_conn_request too if the
SYN is dropped.

Thanks
Sridhar

Re: why does tcp_v[46]_conn_request not inc MIB stats

[Rick Jones]

Sridhar Samudrala wrote:
> On Mon, 2007-09-10 at 11:42 -0700, Rick Jones wrote:
> 
>>I've been digging around to see about inducing /proc/net/tcp to show 
>>some "interesting" things for listen sockets (eg backlog depth, its max, 
>>and dropped connection requests).
> 
> 
> backlog depth(acceptq length) for a listening socket should be available
> with the newer kernels. The following patch exports this value via the rx_queue
> field in /proc/net/tcp.
>  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=47da8ee681d04e68ca1b1812c10e28162150d453

Yep, I see it in the 2.6.23-rc5 tree I'm using.  At the risk of yet 
another "merely practice" patching excercise I'm putting together a 
patch which will also return that in a TCP_INFO and add the max backlog 
(to the tx_queue field)

While doing that, I've noticed that 
Documenation/networking/proc-net-tcp.txt (?) talks about a tcp6_get_info 
which I cannot find anywhere in the tree.  I'm not sure if that simply 
means that tcp_get_info is what is used for a "tcp6" connection and the 
text can simply be removed from the documentation, or if it is called 
something else.

>>  While there I've noticed that both 
>>tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the 
>>listen queue is full, but only tcp_v[46]_syn_recv_sock increments some 
>>mib stats for dropped connection requests.
>>
>>Is that deliberate, or is that a hole in the stats?
> 
> 
> looks like it is a hole in the stats. I think we should increment
> LISTENOVERFLOWS or LISTENDROPS in tcp_v[46]_conn_request too if the
> SYN is dropped.

OK.  Now, can we get a third to Sridhar's second?-)

rick jones
struggling through the maze of twisty routines for connection establishment

Re: why does tcp_v[46]_conn_request not inc MIB stats

[David Miller]

From: Sridhar Samudrala <sri@us.ibm.com>
Date: Mon, 10 Sep 2007 14:54:43 -0700

> looks like it is a hole in the stats. I think we should increment
> LISTENOVERFLOWS or LISTENDROPS in tcp_v[46]_conn_request too if the
> SYN is dropped.

No we should not.

This is limiting embryonic mini-socket creation.  The listen overflow
should only increment when the 3-way handshake completion is aborted
because the listening socket limit is exceeded, which is entirely
different from the embryonic limit.

Re: why does tcp_v[46]_conn_request not inc MIB stats

[Andi Kleen]

David Miller <davem@davemloft.net> writes:

> This is limiting embryonic mini-socket creation.  The listen overflow
> should only increment when the 3-way handshake completion is aborted
> because the listening socket limit is exceeded, which is entirely
> different from the embryonic limit.

That's true, but I think Rick has a point in that there should 
be some sort of (different) counter counting this.  In general
I believe every point in the stack who drops a packet should
have a statistics counter so that it can be later diagnosed.

Rick, the best way to get such a counter in is to just send a patch,
don't ask for it.

-Andi

Re: why does tcp_v[46]_conn_request not inc MIB stats

[Rick Jones]

Andi Kleen wrote:
> David Miller <davem@davemloft.net> writes:
> 
> 
>>This is limiting embryonic mini-socket creation.  The listen overflow
>>should only increment when the 3-way handshake completion is aborted
>>because the listening socket limit is exceeded, which is entirely
>>different from the embryonic limit.
> 
> 
> That's true, but I think Rick has a point in that there should 
> be some sort of (different) counter counting this.  In general
> I believe every point in the stack who drops a packet should
> have a statistics counter so that it can be later diagnosed.
> 
> Rick, the best way to get such a counter in is to just send a patch,
> don't ask for it.

I will try to work something up after cleaning-up the other listenq 
patch to remove the /proc/net/tcp[6] stuff, and an iproute2 patch I have 
to allow setting rto_min, rtt and rttvar using tc-esque units.

rick jones

Re: why does tcp_v[46]_conn_request not inc MIB stats

[David Miller]

From: Rick Jones <rick.jones2@hp.com>
Date: Mon, 10 Sep 2007 11:42:18 -0700

> I've been digging around to see about inducing /proc/net/tcp to show 
> some "interesting" things for listen sockets (eg backlog depth, its max, 
> and dropped connection requests).  While there I've noticed that both 
> tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the 
> listen queue is full, but only tcp_v[46]_syn_recv_sock increments some 
> mib stats for dropped connection requests.

They are checking two different things.

tcp_v{4,6}_conn_request is checking whether we are hitting the limit
for allowing the initial SYN and creating a new embryonic mini-socket.
Exceeding that is not a listen overflow.

tcp_v{4,6}_syn_recv_sock() is processing the end of the 3-way
handshake and wants to create a full established state socket to queue
into the listening parent.  This is checking the listening socket
queue limits, and indeed is a listen queue overflow if exceeded.

Re: why does tcp_v[46]_conn_request not inc MIB stats

[Rick Jones]

David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Mon, 10 Sep 2007 11:42:18 -0700
> 
> 
>>I've been digging around to see about inducing /proc/net/tcp to show 
>>some "interesting" things for listen sockets (eg backlog depth, its max, 
>>and dropped connection requests).  While there I've noticed that both 
>>tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the 
>>listen queue is full, but only tcp_v[46]_syn_recv_sock increments some 
>>mib stats for dropped connection requests.
> 
> 
> They are checking two different things.
> 
> tcp_v{4,6}_conn_request is checking whether we are hitting the limit
> for allowing the initial SYN and creating a new embryonic mini-socket.
> Exceeding that is not a listen overflow.

I'll risk some toe chewing and ask - is the embryonic limit set based on 
  what one sets in the listen() call and/or system configs?

Seems that _some_ sort of stat should be incremented, even if it isn't 
the listen queue overflow one?

rick jones

> tcp_v{4,6}_syn_recv_sock() is processing the end of the 3-way
> handshake and wants to create a full established state socket to queue
> into the listening parent.  This is checking the listening socket
> queue limits, and indeed is a listen queue overflow if exceeded.

Re: why does tcp_v[46]_conn_request not inc MIB stats

[David Miller]

I'm rebasing a 500 patch tree which has tons of merge conflicts today,
so I lack the time to answer your question.

Suffice it to say you could do a little bit of legwork to figure out
the answer by researching inet_csk_reqsk_queue_is_full() and
determining what sets the state tested by that function.

But you typically don't do this, you always push the queries back
instead of figuring it out yourself, and that doesn't scale.

It can't be all me folks, people have to be as self-sufficient as
possible in order for the work to be distributed properly.