netdev - RE: RE: A Linux TCP SACK Question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <000301c89e81$80124570$6b5ee183@D2GT6T71>
Date:	Mon, 14 Apr 2008 17:47:21 -0500
From:	Wenji Wu <wenji@...l.gov>
To:	'Ilpo Järvinen' <ilpo.jarvinen@...sinki.fi>
Cc:	'Netdev' <netdev@...r.kernel.org>
Subject: RE: RE: A Linux TCP SACK Question

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html