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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 30 Jun 2014 22:24:57 -0400
From:	Neal Cardwell <>
To:	Octavian Purdila <>
Cc:	Netdev <>, Daniel Lee <>,
	Yuchung Cheng <>, Jerry Chu <>
Subject: Re: [net-next v2 02/13] tcp: tcp_v[46]_conn_request: fix snt_synack initialization

On Mon, Jun 30, 2014 at 5:00 PM, Octavian Purdila
<> wrote:
> On Mon, Jun 30, 2014 at 10:11 PM, Neal Cardwell <> wrote:
>> On Mon, Jun 30, 2014 at 7:50 AM, Octavian Purdila
>> <> wrote:
>>> In that case perhaps it is better to add a new field (or rename the
>>> existing one if it is not needed anymore) to store the syn arrival
>>> time? I think it is confusing to store the syn arrival time in the
>>> "synack sent time" field.
>> That would be reasonable, but I think the longstanding "snt_synack"
>> name is also good, since the primary purpose of that field is to
>> measure the RTT of the SYNACK packet.
> So, if we use it to measure the RTT, with this approach, wouldn't the
> RTT estimate be artificially high if sending the syn-ack fails? And
> wouldn't that negatively affect congestion control ?
> On second thought, if we need to retransmit the syn-ack then it does
> not matter much. Is this the reason we don't care?

tcp_synack_rtt_meas() already explicitly checks to see if the SYNACK
was retransmitted before using the time to calculate the SYNACK RTT.
So this kind of scenario should be OK.

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