netdev - Re: [net-next v2 02/13] tcp: tcp_v[46]_conn_request: fix snt

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: <CAE1zot+Oqqw+8m9Pr4R-W5wSqmYU5f6xqykCSaZP+fnTpLVO-Q@mail.gmail.com>
Date:	Tue, 1 Jul 2014 00:00:28 +0300
From:	Octavian Purdila <octavian.purdila@...el.com>
To:	Neal Cardwell <ncardwell@...gle.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 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?
--
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