netdev - RE: Can I limit the number of active tx per TCP socket?

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 7 Mar 2014 10:17:54 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Rick Jones' <rick.jones2@...com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: Can I limit the number of active tx per TCP socket?

From: Rick Jones
> On 03/06/2014 04:28 AM, David Laight wrote:
> > Is it possible to stop a TCP connection having more than one
> > tx skb (in the ethernet tx ring) at any one time?
> > The idea is to allow time for short sends from the application
> > to accumulate so that the transmitted frames are longer.
> 
> That is precisely what Nagle is supposed to be doing - at least where
> the definition of "time" is the round-trip-time rather than "time it
> takes to get transmitted out the NIC."

No, enabling Nagle leads to unacceptable delays in sending packets.
Try sending one short message every 5ms (without any return data),
the 2nd message gets delayed until the remote ack timer, or Nagle
timer expire. Both these timers are far too long, and the Nagle
timeout isn't specifiable on a per socket basis.

> > Basically I have a TCP connection which carries a lot of separate
> > short 'user buffers'. These are not command-response so
> > TCP_NODELAY has to be set to avoid long delays.
> 
> When you are saturating the receiver and/or the 64K line, are you
> certain that not setting TCP_NODELAY means long delays?

Yes, because it delays data for at least 10s of milliseconds (100ms?)
(I can't remember the Nagle delay - I know it is visible if you
'page forward' when running 'vi' in a large xterm.)

We've had issues with 'slow start' being affected by 'delayed acks'.
IIRC 'slow start' will only send 4 frames without receiving an ack.
The 'delayed ack' code waits 50ms? before sending one out.
By that time we are discarding data received on the slow link!
I avoided that one by requesting an application level data ack
every 4 packets rather than every 8.

>  From a later message:
> 
> > The data is sent out on a 64k line so 1ms is only 8 byte times.
> 
> Are you still using a 1460 byte MSS on such a connection?

The 64k line isn't carrying TCP, the TCP connection is carrying
the data that will be sent over the 64k line.
(It is actually SS7 - telephony signalling data.)
The reason there are a lot of small packets on the TCP connection
is that the 'mtu' for those links it 273, and typical packets are
much shorter.

Also the traffic for multiple (max 64) 64k links is sent over the
same TCP connection, so the aggregate packet rate is considerable.
(Especially when I'm running performance tests!)

	David

--
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