[Bloat] generic tcp - window scaling limits

[Matthias Tafelmeier]

Hello,

before bringing it forward to LNX netdev and with the risk of restating
something, I wanted to hearken for the take of this here, since it's
also bloating related - when looking at it from the link
clogging/flowyness point of view.

I first surmised some DQL (as done for driver rings - BQL) introduction
to the TCP hard limit could improve perceived flow latency - though the
current hard limit is perfectly enough in conjunction with the window
advertisement/scaling.

As of what I measured here

https://matthias0tafelmeier.wordpress.com/2017/08/24/linux-tcp-window-scaling-quantification-rmemwmem/

it rather appears introducing a kind of per socket settability of the
advertising hard limit maybe organized on a link/receive side realm (be
it a subnet or a flow group) for performance can improve the scene.
Sure, it's not possible to align both ends (RCV/SND) always, but for the
back end world and therefore as a general statement it should hold true.

Let me know if I'm totally going astray.

-- 
Besten Gruß

Matthias Tafelmeier

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8ADF343B.asc
Type: application/pgp-keys
Size: 4729 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171104/1d4ee4d1/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171104/1d4ee4d1/attachment.sig>