netdev
[Top] [All Lists]

Re: [RFT] BIC TCP delayed ack compensation

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>
In-reply-to: <20050222135046.23f7ec7d@xxxxxxxxxxxxxxxxx>
References: <050QTJA12@xxxxxxxxxxxxxxxxxxxxx> <20050209105909.17da40a9@xxxxxxxxxxxxxxxxx> <20050222135046.23f7ec7d@xxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
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.

Baruch

<Prev in Thread] Current Thread [Next in Thread>