Re: [LARTC] TCP window based shaping

[Andy Furniss <andy.furniss@dsl.pipex.com>]

Ed Wildgoose wrote:
> 
>> i'm just trying to slow the traffic (it's for my master|degree|pedigree
>> thesis, so i don't want to waste all my life on this) without changing
>> the window size.
>>
>>  
>>
>>> How do we fit this thing into the linux QOS architecture anyway?
>>>   
>>
>>
>> i'm writing a scheduler that just delay the ack rate (it's in a very
>> preliminar state, so nearly nothing was done).
>>
>> now i'm looking for a place where to put the flow information (in a
>> conntrack module, maybe?)
>>  
>>
> 
> Have a look at the BWMGR qos product.  They have some interesting thoughts.

They seem to have some strange ones too -

from http://www.etinc.com/bwcompare.htm

"Suppose you have a T1 line and a single server. Suppose that 2 remote 
clients request the same page simultaneously, and that page has 15,000 
bytes of information. With a typical TCP window of 16K, the entire page 
will be sent without requiring an ACK from the client."

Conviniently forgets that slowstart exists - stopping the above is what 
it's for isn't it? Then later -

"What is important to understand is that bandwidth management devices 
which do not utilize window manipulation at all cannot reduce your 
network latency on an overall basis. They will simply shift the latency 
from one type of traffic to another."

They are still talking about egress shaping here - I say - so what if 
latency gets shifted, as long as you arrange for it to be "shifted" to 
bulk then it doesn't matter.

Egress shaping is sorted without window manipulation - As long as 
whatever you define as interactive traffic is < your bandwidth then you 
can arrange for it never to be delayed by bulk traffic any more than the 
bitrate X length of bulk packet.


> 
> Basically their idea seems to be that you only need to get the window
> shaping (or ACK shaping) roughly right.  The fine tuning happens just as
> now with the queue simply filling up a little.  Seems to me that this is
> right, if you just get the window even +/- 50% of the target bandwidth
> then you can do fine tuning by delaying ACK and buffering data.  The
> trick is basically to avoid the huge splurge of data during slow start
> which can cause queuing on the ISP end.

It would be nice to slow slowstart like this, to some extent linux TCP 
already does this (well it does at LAN speed, it advertises a smaller 
window then grows it). Not much help for WAN rates or forwarded Windows 
traffic though.

> 
> Otherwise I am broadly speaking very happy with the default QOS.  It's
> just this queueing which occurs when a bunch of connections all start
> together which is the problem.  This isn't really just a bittorrent
> issue though because a busy webserver would likely see the same conditions?

I don't get the webserver bit - "heavy" browsing on 512kbit link hurts - 
typically 4 simultaneous connections over and over. Sortable by sending 
new connections to a short, lowish rate sfq (tweaked for ingress). But 
only if there is no other bulk aswell. If there is then I think you need 
   some sort of prediction/intelligence or a dumb queue will react too 
late and over aggressivly - resync bursts aswell then.

> 
> Are we all on the same page as to what the problem is?  Any more
> thoughts on how to tackle it?  I'm still not convinced that delaying
> ACK's is really any better than the current option to buffer incoming
> data.

I suppose the gain for marco is that he will not just be delaying acks - 
OK he could do the same for data and I agree that there isn't much 
difference and it could be better to work with date in some ways eg. you 
can really drop whereas with acks it would be harder to simulate a drop.

I don't think he will be just buffering though - thats the advantage for 
him - to build in intelligence to handling the problem of shaping from 
the wrong end of a bottleneck without the handicap of using dumb queues 
that are seeing traffic that's allready shaped by a fifo and whose fill 
rate is determined by what percentage of the fifo rate you set their rate.

I still think that dumb queues can be improved for this situation, though -

Making an htb/hfsc class that behaves as full as soon as it sees 
traffic, so other classes that are sharing get throttled before it's too 
late.

Making an eesfq - preferably without the s - perturb is horrible really, 
the packet reordering alone causes resync bursts in tests I've done.
It is also pretty pointless dropping a whole bunch packets from the same 
window, one per slot with some timed immunity would be nice - they 
already used the link anyway. That is more like sfred or fred I suppose.

Being able to detect existing connections that go back into slowstart - 
don't know how to do that as such, but I suspect bittorrent causes this 
as it cycles through existing connections trying to find better for you.

De piggybacking acks from full duplex bulk traffic - again bittorrent, 
though you can make the effects of bt using full duplex for bulk a bit 
better by using shorter egress queues for it.


   I guess the receiving machine TCP stack gets it earlier so the
> app looks more responsive, but other than the lower lag I don't see much
> difference really?
> 
> Curious to hear how your project gets on though!  Please keep us informed!

Me too - Thomas Graf is also playing with delaying acks - see the dummy 
replacing imq thread this & last month on a netdev archive.

I also remember seeing another shaper that uses delay pools for acks 
bandwidth arbiter or arbitrator IIRC. If you can't find it say, I 
probably have it squirreled away somewhere on my old PC.

Andy.

> 
> Ed W
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/