From: Wenji Wu <wenji@fnal.gov>
To: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Cc: 'Sangtae Ha' <sangtae.ha@gmail.com>,
'John Heffner' <johnwheffner@gmail.com>,
'Netdev' <netdev@vger.kernel.org>
Subject: Re: RE: A Linux TCP SACK Question
Date: Tue, 08 Apr 2008 09:30:14 -0500 [thread overview]
Message-ID: <fba201de4228.47fb3b26@fnal.gov> (raw)
In-Reply-To: <Pine.LNX.4.64.0804081623500.21784@wrl-59.cs.helsinki.fi>
> > Yes, the adaptive tp->reordering will play a role here.
>
> ...What is not clear to me why NewReno does not go to recovery at
> least
> once near the beginning, or at least it won't result in a retransmission.
The problem cause me two weeks' time to debug!
With 3 DupACKs, tcp_ack() calls tcp_fastretrans_alert(), and which in turn calls tcp_xmit_retransmit_queue().
Within tcp_xmit_retransmit_queue(), there is a line of code that would cause the problem above:
......................................................................................................
/* Forward retransmissions are possible only during Recovery. */
1999 if (icsk->icsk_ca_state != TCP_CA_Recovery)
2000 return;
2001
2002 /* No forward retransmissions in Reno are possible. */
2003 if (tcp_is_reno(tp))
2004 return;
.....................................................................................................
if you look at "tcp_is_reno", you would see that with SACK off, Reno does not do retransmit, it will return!!!
Really do not understand why these two lines of code exist there!!!
Also, this code still in 2.6.25.
> In which kernel version this dump comes from? 2.6.24 newreno is
> crippled
> with TSO as was recently discovered, ie., it won't mark lost super
> skbs
> at head and thus won't retransmit them. Also 2.6.25-rcs are still
> broken
> (though they'll transmit too much, I'll not go detail in here), DaveM
> now
> has the fix for 2.6.25-rcs in net-2.6.
The dumped file is from 2.6.24. 2.6.25's is similiar.
> > You can reverse the order of the tests, with SACK option on/off. The
>
> > results are still the same.
>
> Ok. I just wanted to make sure so that we don't end up trace some test
>
> setup issue :-).
>
> > Also, according to the source code, tp->reordering will be
> initialized
> > to "/proc/sys/net/ipv4/tcp_reordering" (default 3), when the new
> > connection is established.
>
> In addition, in tcp_init_metrics():
>
> if (dst_metric(dst, RTAX_REORDERING) &&
> tp->reordering != dst_metric(dst, RTAX_REORDERING)) {
> tcp_disable_fack(tp);
> tp->reordering = dst_metric(dst, RTAX_REORDERING);
> }
Good to know this, thanks
wenji
next prev parent reply other threads:[~2008-04-08 14:36 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-04 4:54 A Linux TCP SACK Question Wenji Wu
2008-04-04 16:27 ` John Heffner
2008-04-04 17:49 ` Wenji Wu
2008-04-04 18:07 ` John Heffner
2008-04-04 20:00 ` Ilpo Järvinen
2008-04-04 20:07 ` Wenji Wu
2008-04-04 21:15 ` Wenji Wu
2008-04-04 21:33 ` Ilpo Järvinen
2008-04-04 21:39 ` Ilpo Järvinen
2008-04-04 22:14 ` Wenji Wu
2008-04-05 17:42 ` Ilpo Järvinen
2008-04-05 21:17 ` Sangtae Ha
2008-04-06 20:27 ` Wenji Wu
2008-04-06 22:43 ` Sangtae Ha
2008-04-07 14:56 ` Wenji Wu
2008-04-08 6:36 ` Ilpo Järvinen
2008-04-08 12:33 ` Wenji Wu
2008-04-08 13:45 ` Ilpo Järvinen
2008-04-08 14:30 ` Wenji Wu [this message]
2008-04-08 14:59 ` Ilpo Järvinen
2008-04-08 15:27 ` Wenji Wu
2008-04-08 17:26 ` Ilpo Järvinen
2008-04-14 22:47 ` Wenji Wu
2008-04-15 0:48 ` John Heffner
2008-04-15 8:25 ` Ilpo Järvinen
2008-04-15 18:01 ` Wenji Wu
2008-04-15 22:40 ` John Heffner
2008-04-16 8:27 ` David Miller
2008-04-16 9:21 ` Ilpo Järvinen
2008-04-16 9:35 ` David Miller
2008-04-16 14:50 ` Wenji Wu
2008-04-18 6:52 ` David Miller
2008-08-27 14:38 ` about Linux adaptivly adjusting ssthresh Wenji Wu
2008-08-27 22:48 ` John Heffner
2008-08-28 0:53 ` Wenji Wu
2008-08-28 6:34 ` Ilpo Järvinen
2008-08-28 14:20 ` about Linux adaptivly adjusting dupthresh Wenji Wu
2008-08-28 18:53 ` Ilpo Järvinen
2008-08-28 19:30 ` Wenji Wu
2008-04-16 14:40 ` A Linux TCP SACK Question John Heffner
2008-04-16 15:03 ` Ilpo Järvinen
2008-04-16 14:46 ` Wenji Wu
2008-04-15 15:45 ` Wenji Wu
2008-04-15 16:39 ` Wenji Wu
2008-04-15 17:01 ` John Heffner
2008-04-15 17:08 ` Ilpo Järvinen
2008-04-15 17:23 ` John Heffner
2008-04-15 18:00 ` Matt Mathis
2008-04-15 17:55 ` Wenji Wu
2008-04-08 15:57 ` John Heffner
2008-04-08 14:07 ` John Heffner
2008-04-14 16:10 ` Wenji Wu
2008-04-14 16:48 ` Ilpo Järvinen
2008-04-14 22:07 ` Wenji Wu
2008-04-15 8:23 ` Ilpo Järvinen
2008-04-04 21:40 ` Wenji Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fba201de4228.47fb3b26@fnal.gov \
--to=wenji@fnal.gov \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=johnwheffner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sangtae.ha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).