netdev - Re: [PATCH net-next] tcp: add tcpi_segs_in and tcpi_segs_out to tcp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 May 2015 17:37:11 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Rick Jones <rick.jones2@...com>
Cc:	Marcelo Ricardo Leitner <mleitner@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>,
	"David S. Miller" <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Yuchung Cheng <ycheng@...gle.com>,
	Matt Mathis <mattmathis@...gle.com>,
	Craig Gallek <cgallek@...gle.com>, Martin Lau <kafai@...com>,
	Chris Rapier <rapier@....edu>
Subject: Re: [PATCH net-next] tcp: add tcpi_segs_in and tcpi_segs_out to
 tcp_info

On Wed, 2015-05-20 at 17:06 -0700, Rick Jones wrote:
> On 05/20/2015 04:35 PM, Eric Dumazet wrote:
> > From: Marcelo Ricardo Leitner <mleitner@...hat.com>
> >
> > This patch tracks the total number of inbound and outbound segments on a
> > TCP socket. One may use this number to have an idea on connection
> > quality when compared against the retransmissions.
> >
> > RFC4898 named these : tcpEStatsPerfSegsIn and tcpEStatsPerfSegsOut
> >
> > These are a 32bit field each and can be fetched both from TCP_INFO
> > getsockopt() if one has a handle on a TCP socket, or from inet_diag
> > netlink facility (iproute2/ss patch will follow)
> 
> I suppose it is far-fetched, but is it a concern that at 100 Gbit/s and 
> 1500 byte MTU the 32 bit segment counter would wrap in something like 
> 500 seconds and change?


Like SNMP counters, applications are responsible to adapt snapshot
intervals and deals with wraps around.

For these counters, applications are probably not interested in absolute
numbers, but deltas every couple of seconds to study the behavior of a
flow during time.

The byte counters are 64bits and shall not overflow.

Anyway, if we can send tcp data at 100Gbits on one flow, I guess we are
doing a terrific job and do not need to tweak TCP stack anymore ;)



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html