Speaking of this, I am currently thinking about doing some research into shaping of fine grained flows in the reverse direction. My personal itch I'm looking into scratching is using an abundance of spare CPU cycles and memory to help improve the inbound queue situation where bandwidth is limited. In real life situations this would be like a Pentium 266MHz or better class machine is on the end of a connection ranging from 128kbit to 8mbit connection.Shaping your outgoing traffic, which is mostly very small TCP ACK packets, will do little to shape the much larger packets on the "download" side of the stream.
I'm thinking of using the Linux connection tracker, to make predictions about each connection it is tracking based on recent usage and/or well known expected patterns for that particluar service (at connection creation).
This monitoring would then be able calculate some values to weigh in the RTT (from this point to the dest and back) and anticipated reverse payload the destination would return after receipt of this response.
With this information available the outbound packets maybe further processed in times where the inbound link is saturated, by selecting packets to delay and/or re-order based on this information, maybe even performing on the fly TCP window clamping or otherwise altering packets in an acceptable way. I'm not trying to defeat TCP congestion control I'm trying to use it to predict the inbound congestion expected at a time in the immediate future, then tweak the packets I can control to make ther other end alter its behaviour.
So my questions is does anyone know of any starting points I should look at on this topic ?
Thanks
Darryl
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
