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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 30 Jun 2014 22:24:57 -0400 From: Neal Cardwell <ncardwell@...gle.com> To: Octavian Purdila <octavian.purdila@...el.com> Cc: Netdev <netdev@...r.kernel.org>, Daniel Lee <longinus00@...il.com>, Yuchung Cheng <ycheng@...gle.com>, Jerry Chu <hkchu@...gle.com> 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 <octavian.purdila@...el.com> wrote: > On Mon, Jun 30, 2014 at 10:11 PM, Neal Cardwell <ncardwell@...gle.com> wrote: >> On Mon, Jun 30, 2014 at 7:50 AM, Octavian Purdila >> <octavian.purdila@...el.com> 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. neal -- 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
Powered by blists - more mailing lists