RE: [PATCH v4 0/10] bql: Byte Queue Limits

 
...

We spent all that engineering time making TCP go fast and minimized

the

hardware impact of that - why not spend a little more time - in the
next generation of hw/sw - making TCP work *better* on the network?

One problem I've seen is that a lot of the 'make TCP go fast'
changes have been focused on bulk transfer over long(ish) latency
links - typical for ftp and http downloads.

Interactive (command+response) works moderately, but async
data requests suffer badly.

Typically these connections will have Nagle disabled (because
you can't stand the repeated timeouts), and may be between
very local systems so the RTT is efectively zero and packet
loss unexpected.
Under these conditions the 'slow start' and 'delayed acks'
conspire against you.

What is more, if you have a high request rate there is little
that can be done to merge tx packets, even the sender is
willing to let some data be queued until (say) the next 1ms
clock tick.

I have seen 30000 packets/sec on a single tcp connection!
(The sender doesn't know there is another message to send.)
The sender was a dual, running 'while :; do :; done'
reduced the packet count considerably!

	David