[Top] [All Lists]

Re: [RFT] BIC TCP delayed ack compensation

To: John Heffner <jheffner@xxxxxxx>
Subject: Re: [RFT] BIC TCP delayed ack compensation
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Wed, 23 Feb 2005 14:10:32 -0800
Cc: hubert.tonneau@xxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.58.0502231436170.28189@xxxxxxxxxxxxxx>
References: <052Q0TU11@xxxxxxxxxxxxxxxxxxxxx> <200502231835.j1NIZX2T020606@xxxxxxxxxxxxxxxxxxxxxx> <20050223112611.60561121.davem@xxxxxxxxxxxxx> <Pine.LNX.4.58.0502231436170.28189@xxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Wed, 23 Feb 2005 17:04:08 -0500 (EST)
John Heffner <jheffner@xxxxxxx> wrote:

> Maybe this has something to do with the bi-directional nature of the flow?
> Mac OS delaying ACK to try to piggyback on data or something like that.
> One signature I noticed is that it seems the last packet sent by the Mac
> before the long delack timeout is always a small data packet.  (I didn't
> rigorously verify this but it seems true.)

I should be more specific when I say "PSH".  Mac OS-X's algorithm is basically
that it always delays ACKs to the delayed ACK timeout when the header prediction
fast path is hit.  One way to "miss" the header prediction fast path is to
set PSH (this is actually a bug, Linux fixed this long ago, PSH should be 
for header prediction fast path checking).

When the fast path is missed, it does the usual "every 2 full sized frames"

Out of order data can cause the missing of the fast path as well.
That can only be determined if we had dumps from the Mac's perspective

Anyways, this Mac OS-X behavior has pretty much been universally agreed
to as a severe bug, at least on this list :-)

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