netdev
[Top] [All Lists]

Re: [RFT] BIC TCP delayed ack compensation

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

> 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 
> ignored
> for header prediction fast path checking).

The point is it appears to be delaying ack even when PSH is set.


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

Yep.  The Mac behavior is clearly bizarre. :)

  -John

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