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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 17 Dec 2007 13:44:25 +0000
From:	Gavin McCullagh <>
Subject: [PATCH/RFC] TCP: use non-delayed ACK for congestion control RTT

When a delayed ACK representing two packets arrives, there are two RTT
samples available, one for each packet.  The first (in order of seq number)
will be artificially long due to the delay waiting for the second packet,
the second will trigger the ACK and so will not itself be delayed.

According to rfc1323, the SRTT used for RTO calculation should use the
first rtt, so receivers echo the timestamp from the first packet in the
delayed ack.  For congestion control however, it seems measuring delayed
ack delay is not desirable as it varies independently of congestion.

The patch below causes seq_rtt to be updated with any available later
packet rtts which should have less (and hopefully zero) delack delay.  The
lower seq_rtt then gets passed to ca_ops->pkts_acked().  

For non-delay based congestion control (cubic, h-tcp), rtt is sometimes
used for rtt-scaling.  In shortening the RTT, this may make them a little
less aggressive.  Delay-based schemes (eg vegas, illinois) should get a
considerably cleaner, more accurate congestion signal, particularly for
small cwnds. The congestion control module can potentially also filter out
bad RTTs due to the delayed ack alarm by looking at the associated cnt
which (where delayed acking is in use) should probably be 1 if the alarm
went off or greater if the ACK was triggered by a packet.

I seem to be undoing a design decision here so perhaps there is some reason
this should not be done?  Comments/explanations appreciated...

Signed-off-by: Gavin McCullagh <>

--- a/net/ipv4/tcp_input.c	2007-12-15 00:22:23.000000000 +0000
+++ b/net/ipv4/tcp_input.c	2007-12-17 13:35:16.000000000 +0000
@@ -2691,11 +2691,9 @@ static int tcp_clean_rtx_queue(struct so
 				    (packets_acked > 1))
 			} else {
-				if (seq_rtt < 0) {
-					seq_rtt = now - scb->when;
-					if (fully_acked)
-						last_ackt = skb->tstamp;
-				}
+				seq_rtt = now - scb->when;
+				if (fully_acked)
+					last_ackt = skb->tstamp;
 				if (!(sacked & TCPCB_SACKED_ACKED))
 					reord = min(cnt, reord);
@@ -2709,11 +2707,9 @@ static int tcp_clean_rtx_queue(struct so
 			    !before(end_seq, tp->snd_up))
 				tp->urg_mode = 0;
 		} else {
-			if (seq_rtt < 0) {
-				seq_rtt = now - scb->when;
-				if (fully_acked)
-					last_ackt = skb->tstamp;
-			}
+			seq_rtt = now - scb->when;
+			if (fully_acked)
+				last_ackt = skb->tstamp;
 			reord = min(cnt, reord);
 		tp->packets_out -= packets_acked;

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists