On Mon, 2005-02-14 at 01:27 +0100, marco ghidinelli wrote: > On Fri, Feb 11, 2005 at 06:18:01PM +0000, Ed Wildgoose wrote: > > > > 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. > > basically, we have smaller queue because we are queueing the small ack, not > the big data transfer on the downlink. > > and delaying ack is the first step to do the delay+advertised window resize > that maybe someone (me?) will do in the future. Pardon me for jumping in a month after the last post. but what is the objective of this anyway? My understanding is that we need to priotise acks. (irrespective of which ack it is, eg: bittorrent acks/ssh acks/web acks etc) Isn't the point here is to make sure that what gets sent out, is get sent out faster (in the case of ssh acks where we should get 'minimum delay') In my current implementation at home, I use TC/HTB rules to priortise outgoing acks. This definately helps esp when doing huge Linux ISO dl's through Bittorrent. Why delay Acks?? Just because you want to delay/make/simulate the normal TCP behaviour of making the window smaller?? (unless of course if you can make "Specific" Windows smaller. (i would think this would be useful only if we can tag acks for Bulk traffic like BT) -- Ow Mun Heng Gentoo/Linux on DELL D600 1.4Ghz 98% Microsoft(tm) Free!! Neuromancer 18:05:11 up 21:33, 3 users, load average: 0.22, 0.30, 0.56 _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
