From: Damian Lukowski <damian@tvk.rwth-aachen.de>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 0/3][v2] tcp: fix ICMP-RTO war
Date: Mon, 08 Feb 2010 13:34:38 +0100 [thread overview]
Message-ID: <op.u7s6j0qup498uc@nexus> (raw)
In-Reply-To: <20100131.233338.254690877.davem@davemloft.net>
Am 01.02.2010, 08:33 Uhr, schrieb David Miller <davem@davemloft.net>:
> From: Damian Lukowski <damian@tvk.rwth-aachen.de>
> Date: Fri, 29 Jan 2010 23:15:51 +0100
>
>> This patches fix the current RTO calculation routine, when
>> srtt and rttvar are zero, yielding an RTO of zero
>> Under some circumstances, TCPs srtt and rttvar are zero,
>> yielding a calculated RTO of zero.
>> This is particularly unfortunate for ICMP based RTO recalculation
>> as introduced in f1ecd5d9e736660 (Revert Backoff [v3]: Revert RTO
>> on ICMP destination unreachable), as it results in RTO retransmission
>> flooding.
>>
>> Thanks to Ilpo Jarvinen for providing debug patches and to
>> Denys Fedoryshchenko for reporting and testing.
>>
>> Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
>
> I still haven't seen a detailed enough analysis of why these
> tiny RTOs can come to exist in the first place.
>
> Please show me a list of events, function by function, the value of
> relevant variables and per-socket TCP state, in the TCP stack, that
> show how this ends up happening.
>
> Thanks for all of your work on this so far.
I might have figured it out, but could not verify it, so maybe you can
comment my thought.
When a listening TCP receives a SYN, it will send a SYN+ACK
and wait for an ACK to complete the handshake.
Look at tcp_rcv_state_process::step 5::case SYN_RECV::acceptable
and the code after the comment "tcp_ack considers this ACK as duplicate
and does not calculate rtt".
If the connecting client has disabled timestamps, the rtt statistics
won't be updated here, while the state is changed above.
I printk'ed at the very end of TCP_SYN_RECV and got the following:
state 1 (ESTABLISHED), srtt 0, rttvar 0.
So my suspicion is: If connectivity breaks right after a listening TCP
has completed the handshake without timestamps, and the listening TCP
sends data after establishing the connection, we will get the observed
behaviour.
Regards
Damian
next prev parent reply other threads:[~2010-02-08 12:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-29 22:15 [PATCH 0/3][v2] tcp: fix ICMP-RTO war Damian Lukowski
2010-02-01 7:33 ` David Miller
2010-02-08 12:34 ` Damian Lukowski [this message]
2010-02-08 21:58 ` Damian Lukowski
2010-02-09 12:37 ` Ilpo Järvinen
2010-02-09 22:29 ` Damian Lukowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.u7s6j0qup498uc@nexus \
--to=damian@tvk.rwth-aachen.de \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox