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 delayed acks complicate things a bit - If you are not going to deconstruct and spawn new acks then you will always be working with pairs. If I had a meg I guess I wouldnt care (and for those with highly asymmetric dsl links they are almost a must) but for slow links it's nice to be able to get 1 ack = 1 packet.
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).
IIRC you have 1 meg - I always assumed that this would be nicer that
my 1/2 meg. I'll have to do some tests when I get time and make some graphs to see how my setup behaves, it's a bit tricky with bt though as things can change alot over time on the same torrent.
If you are throttling to 50% and not using RED then it's going to be more aggressive WRT over dropping and maybe this causes problems by its self.
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?
I'm not sure about this one but if you are p2p with someone whose buffer is flooded and you are competing for their bandwidth with others you may actually over throttle yourself by reducing window.
The way broadband in the UK is going - higher bandwidth and usage caps I think we may also see more contention and not knowing what your bandwidth is, is going to be tricky :-) (policers to classify?)
Andy.
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/
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
