From: Michal Kubecek <mkubecek@suse.cz>
To: Yuchung Cheng <ycheng@google.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: tcp: multiple ssthresh reductions before all packets are retransmitted
Date: Mon, 16 Jun 2014 22:06:40 +0200 [thread overview]
Message-ID: <20140616200640.GA22301@unicorn.suse.cz> (raw)
In-Reply-To: <CAK6E8=dwh1btNzX80YNre9u7rS+SgochXxHxDhQYQZCvY8yVMQ@mail.gmail.com>
On Mon, Jun 16, 2014 at 12:04:37PM -0700, Yuchung Cheng wrote:
> On Mon, Jun 16, 2014 at 10:47 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
> > On Mon, Jun 16, 2014 at 10:02:08AM -0700, Yuchung Cheng wrote:
> >> On Mon, Jun 16, 2014 at 8:35 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
> >> >
> >> > RFC 5681 says that ssthresh reduction in response to RTO should be done
> >> > only once and should not be repeated until all packets from the first
> >> > loss are retransmitted. RFC 6582 (as well as its predecessor RFC 3782)
> >> > is even more specific and says that when loss is detected, one should
> >> > mark current SND.NXT and ssthresh shouldn't be reduced again due to
> >> > a loss until SND.UNA reaches this remembered value.
> >> >
> >> > Linux implementation does exactly that but in TCP_CA_Loss state,
> >> > tcp_enter_loss() also takes icsk_retransmits into account:
> >> >
> >> > /* Reduce ssthresh if it has not yet been made inside this window. */
> >> > if (icsk->icsk_ca_state <= TCP_CA_Disorder ||
> >> > !after(tp->high_seq, tp->snd_una) ||
> >> > (icsk->icsk_ca_state == TCP_CA_Loss && !icsk->icsk_retransmits)) {
> >> > new_recovery = true;
> >> > tp->prior_ssthresh = tcp_current_ssthresh(sk);
> >> > tp->snd_ssthresh = icsk->icsk_ca_ops->ssthresh(sk);
> >> > tcp_ca_event(sk, CA_EVENT_LOSS);
> >> > }
> >> >
> >> > This seems correct as icsk_retransmits is supposed to mean "we still
> >> > have packets to retransmit". But icsk_retransmits is reset in
> >> > tcp_process_loss() if one of two conditions is satisfied:
> >>
> >> icsk_retransmits indicates the number of recurring timeouts (of the
> >> same sequence). so it is reset when the recovery is done or SND_UNA is
> >> advanced. the variable name however is confusing.
> >
> > In that case, I suppose the problem would be this part
> >
> > (icsk->icsk_ca_state == TCP_CA_Loss && !icsk->icsk_retransmits)
> >
> > of the condition above (in tcp_enter_loss()). As that would mean we
> > would allow further ssthresh reduction as soon as SND.UNA moves forward
> > (not when it reaches high_seq).
>
> Nice catch. That check is incorrect and should be removed. I have used
> packetdrill to verify it fixes the ssthresh problem.
>
...
>
> Do you want to submit a one-liner patch? or I am happy to do that.
I'll submit it. Thank you for your help.
Michal Kubecek
next prev parent reply other threads:[~2014-06-16 20:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 15:35 tcp: multiple ssthresh reductions before all packets are retransmitted Michal Kubecek
2014-06-16 17:02 ` Yuchung Cheng
2014-06-16 18:48 ` Michal Kubecek
[not found] ` <20140616174721.GA15406@lion>
2014-06-16 19:04 ` Yuchung Cheng
2014-06-16 20:06 ` Michal Kubecek [this message]
2014-06-16 21:19 ` [PATCH net] tcp: avoid multiple ssthresh reductions in on retransmit window Michal Kubecek
2014-06-16 22:39 ` Yuchung Cheng
2014-06-16 23:42 ` Neal Cardwell
2014-06-17 0:25 ` Yuchung Cheng
2014-06-17 0:44 ` Neal Cardwell
2014-06-17 12:20 ` Michal Kubecek
2014-06-17 21:35 ` Yuchung Cheng
2014-06-17 22:42 ` Michal Kubecek
2014-06-18 0:38 ` Jay Vosburgh
2014-06-18 0:56 ` Neal Cardwell
2014-06-18 2:00 ` Jay Vosburgh
2014-06-19 1:52 ` Jay Vosburgh
2014-06-19 2:28 ` Eric Dumazet
2014-06-19 6:05 ` Jay Vosburgh
2014-06-18 16:56 ` Yuchung Cheng
2014-06-18 7:17 ` Eric Dumazet
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=20140616200640.GA22301@unicorn.suse.cz \
--to=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=ycheng@google.com \
/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;
as well as URLs for NNTP newsgroup(s).