From: Wenji Wu <wenji@fnal.gov>
To: "'Ilpo Järvinen'" <ilpo.jarvinen@helsinki.fi>
Cc: 'Netdev' <netdev@vger.kernel.org>
Subject: RE: RE: A Linux TCP SACK Question
Date: Mon, 14 Apr 2008 17:47:21 -0500 [thread overview]
Message-ID: <000301c89e81$80124570$6b5ee183@D2GT6T71> (raw)
In-Reply-To: <Pine.LNX.4.64.0804081742270.21784@wrl-59.cs.helsinki.fi>
Hi, Ilpo,
Could the throughput difference with SACK ON/OFF be due to the following
code in tcp_ack()?
3120 if (tcp_ack_is_dubious(sk, flag)) {
3121 /* Advance CWND, if state allows this. */
3122 if ((flag & FLAG_DATA_ACKED) && !frto_cwnd &&
3123 tcp_may_raise_cwnd(sk, flag))
3124 tcp_cong_avoid(sk, ack, prior_in_flight, 0);
3125 tcp_fastretrans_alert(sk, prior_packets -
tp->packets_out, flag);
3126 } else {
3127 if ((flag & FLAG_DATA_ACKED) && !frto_cwnd)
3128 tcp_cong_avoid(sk, ack, prior_in_flight, 1);
3129 }
In my tests, there are actually no packet drops, just severe packet
reordering in both forward and reverse paths. With good tcp_reordering
auto-tuning, there are few retransmissions.
(1) With SACK option off, the reorder ACKs will not cause much harm to the
throughput. As you have pointed out in the email that "The ACK reordering
should just make the number of duplicate acks smaller because part of them
get discarded as old ones as a newer cumulative ACK often arrives a bit
"ahead" of its time making rest smaller sequenced ACKs very close to on-op."
If there are any ACK advancement, tcp_cong_avoid() will be called.
(2) With the sack option is on. If the ACKs do not advance the left edge of
the window, those ACKs will go to "old_ack" of "tcp_ack()", no much
processing except sack-tagging the corresponding packets in the
retransmission queue. tcp_cong_avoid() will not be called.
However, if the ACKs advance the left edge of the window and these ACKs
include SACK options, tcp_ack_is_dubious(sk, flag)) would be true. Then the
calling of tcp_cong_avoid() needs to satisfy the if-condition at line 3122,
which is stricter than the if-condition at line 3127.
So, the congestion window with SACK on would be smaller than with SACK off.
If you run tcptrace and xplot on the files I posted, you would see lots ACKs
will advance the left edge of the window, and include SACK blocks.
Not quite sure, just a guess.
wenji
next prev parent reply other threads:[~2008-04-14 22:47 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
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 [this message]
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='000301c89e81$80124570$6b5ee183@D2GT6T71' \
--to=wenji@fnal.gov \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=netdev@vger.kernel.org \
/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