Sorry for the belated reply:
instead of shaping the incoming traffic and estimate rate from the
outgoing traffic, you can 'delay' the outgoing ACK, and estimate the rate
from the raise of the sequence number.
I like the sound of this idea, but I don't follow the details?
Certainly it seems to me that you can do most of the work by only looking at outgoing ACK packets. For example with certain assumptions we can simply measure the outgoing ACK rate, assume this is dependent on the amount of data being controlled by our bandwidth throttling, and therefore we get a really good estimate of the effect of our current incoming rate. However, this breaks down if for example the sender was not sending data as fast as possible.
Also simply delaying ACK's doesn't seem to be the whole answer because the sender should simply see this as a longer RTT and increase the window size to keep more data in transit. Seems that we need to do a little of both, eg examine outgoing ACK speed, reduce the window to the approx correct size and then our RED/tail drop takes care of the fine tuning
As others have said, it's stuff like Bittorrent which really shows the weaknesses in the current system. I find that even throttling bittorrent to say, half the incoming bandwidth still shows regular increases in latency, no doubt to the effects of the sudden rush of incoming connections. (or slow start effects basically).
In the BWMGR product (or whatever it is called), I get the impression they do more work on controlling initial windows to try and throttle slow start back some? Seems to me that one could do more work around the time of the initial ACK to get a window size more in keeping with the flow for that tcp class? If we only allocate 10Kb of our connection to that class, and we are connected via some broadband device, then nowhere in the world is more than 350ms away, and hence a window size of 65535 is clearly wayyy to large - lets fix this early?
How do we fit this thing into the linux QOS architecture anyway?
Ed W
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
