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: <CADVnQyn4X57Tz8GxJRU84=Jr2x1j29ZK8xJfdLjnb2a2g45S0A@mail.gmail.com>
Date:	Thu, 10 Dec 2015 10:37:32 -0500
From:	Neal Cardwell <ncardwell@...gle.com>
To:	Per Hurtig <per.hurtig@....se>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Nandita Dukkipati <nanditad@...gle.com>,
	Tom Herbert <tom@...bertland.com>,
	Yuchung Cheng <ycheng@...gle.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Florian Westphal <fw@...len.de>,
	Marcelo Ricardo Leitner <mleitner@...hat.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	Willem de Bruijn <willemb@...gle.com>,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
	Pasi Sarolahti <pasi.sarolahti@....fi>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Netdev <netdev@...r.kernel.org>,
	Anna Brunström <anna.brunstrom@....se>,
	Andreas Petlund <apetlund@...ula.no>,
	Michael Welzl <michawe@....uio.no>,
	Mohammad Rajiullah <mohammad.rajiullah@....se>
Subject: Re: [RFC PATCHv2 net-next 1/2] tcp: RTO Restart (RTOR)

On Thu, Dec 10, 2015 at 1:51 AM, Per Hurtig <per.hurtig@....se> wrote:
>
>> On 08 Dec 2015, at 14:47, Eric Dumazet <eric.dumazet@...il.com> wrote:
>>
>> On Tue, 2015-12-08 at 10:19 +0100, Per Hurtig wrote:
>>
>>> +static u32 tcp_unsent_pkts(const struct sock *sk, u32 ulimit)
>>> +{
>>> +    struct sk_buff *skb = tcp_send_head(sk);
>>> +    u32 pkts = 0;
>>> +
>>> +    if (skb)
>>> +            tcp_for_write_queue_from(skb, sk) {
>>> +                    pkts += tcp_skb_pcount(skb);
>>> +
>>> +                    if (ulimit && pkts >= ulimit)
>>> +                            return ulimit;
>>> +            }
>>> +
>>> +    return pkts;
>>> +}
>>
>>
>> Considering Yuchung feedback, have you looked at using an approximation
>> instead ?
>>
>> (ie using tp->write_seq - tp->snd_nxt)
>>
>>
>
> Well, an approximation is rather “dangerous” as missing a single packet
> could inhibit the desired behaviour. If looping is undesired, I think a
> better solution is to actually *not* do this check at all and instead rely
> solely on the
>
> tp->packets_out < TCP_RTORESTART_THRESH

Yes, this simpler version seems very much preferable, IMHO. I agree
that it does not seem worth the complexity to try to cover the kind of
corner cases you outline.

I would also suggest a TCP_RTORESTART_THRESH value higher than 4.

In the ID at https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-10 it says:

   The RECOMMENDED value of rrthresh is four, as this value will ensure
   that RTOR is only used when fast retransmit cannot be triggered.

But my sense is that fast retransmit is often not triggered at
in-flight counts of much higher than 4, due to drop-tail queues, TSO
bursts, the initial IW10 being unpaced, etc. It would be interesting
to see A/B experiments for a few TCP_RTORESTART_THRESH values, say, 4
vs 10.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ