lkml.org 
[lkml]   [1998]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] delayed acks decrease performances in congestioned networks
   Date: Sat, 14 Nov 1998 12:50:44 -0800 (PST)
From: Kaz Kylheku <kaz@cafe.net>

Just because you have been receiving segments are regular intervals,
and there is a sudden lapse, doesn't mean that a packet has been lost.

Yes, we all know this.

But what he is implying is something all people who work on TCP
queueing theory know, that "recovery from loss will always be better
if delayed ACKs are not used". The reason is simple, it provides the
maximum amount of feedback to the sender, and the more feedback the
sender gets the faster fast retransmit and other recovery strategies
can react.

Check out all TCP research done on loss recovery, almost all of their
analysis is done with delayed acks turned off for this very reason.
(For this core reason I consider %99 of all research papers on TCP
completely bogus because they all show that their suggested scheme
works extremely well in an unreal world, one where delayed acks are
not the norm, whereas in the real world every host I have every
watched on the wire speaks delayed acks) They do this for another
reason, to eliminate a variable in the BSD stack. Depending upon when
_exactly_ in time you run the tests, even with controlled and exact
same network conditions, you'll get different results. This is due to
BSD's extremely coarse and inexact timer implementation (ie. when you
set the "200ms" timer to go off in BSD, it may go off any time between
right now and 200ms in the future) Perhaps this is another argument
for more TCP research to be done using Linux? :-)

For extremely shitty networks (I mean here, every other packet always
dropped etc.), delayed acks are worse than non-delayed ones. But as
you mention it contributes to congestion and degrades performance for
people with at least half-way decent connectivity.

Later,
David S. Miller
davem@dm.cobaltmicro.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.080 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site