|To:||Stephen Hemminger <shemminger@xxxxxxxx>|
|Subject:||Re: [RFT] BIC TCP delayed ack compensation|
|From:||Baruch Even <baruch@xxxxxxxxx>|
|Date:||Tue, 22 Feb 2005 23:38:32 +0000|
|Cc:||Hubert Tonneau <hubert.tonneau@xxxxxxxxxxxxxx>, cliff white <cliffw@xxxxxxxx>, Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, Injong Rhee <rhee@xxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, Yee-Ting Li <yee-ting.li@xxxxxxx>, Doug Leith <doug.leith@xxxxxxx>|
|References:||<050QTJA12@xxxxxxxxxxxxxxxxxxxxx> <20050209105909.17da40a9@xxxxxxxxxxxxxxxxx> <20050222135046.23f7ec7d@xxxxxxxxxxxxxxxxx>|
|User-agent:||Debian Thunderbird 1.0 (X11/20050116)|
Stephen Hemminger wrote:
This patch which was extracted from BIC TCP 1.1 compensates for systems (like MaxOSX) that don't ACK every other packet. It has no impact for normal transfers, but might help with problems with Mac like Hubert found.
We have a version of ABC (Appropriate Byte Counting) implementation of RFC 3465, which we hope to submit soon for inclusion in the kernel which should be a more appropriate solution for this. The RFC is a well defined standard whereas this patch has not received any reviewing by the networking community.
This solution is just a band-aid for only one congestion control, as opposed to a generic solution. It is also prone to make BIC more aggressive according to our testing.
I'll try to post our ABC patch tomorrow, time permitting.One thing to note is that accounting for delayed acking is not an overly important feature, from our testing it only speeds up convergence by a small factor and doesn't change the correctness of the algorithms.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: Frequent Oops on Shutdown 2.6.10, AndyLiebman|
|Next by Date:||Re: Intel and TOE in the news, Andi Kleen|
|Previous by Thread:||Re: [RFT] BIC TCP delayed ack compensation, John Heffner|
|Next by Thread:||Re: [RFT] BIC TCP delayed ack compensation, Yee-Ting Li|
|Indexes:||[Date] [Thread] [Top] [All Lists]|