netdev - Re: [PATCH] tcp: avoid cwnd moderation in undo

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: <AANLkTim_U9CySFQimQ8cG_iHdXCYXSALi9E6ticKztnk@mail.gmail.com>
Date:	Tue, 15 Mar 2011 06:50:47 -0400
From:	John Heffner <johnwheffner@...il.com>
To:	Carsten Wolff <carsten@...ffcarsten.de>
Cc:	Yuchung Cheng <ycheng@...gle.com>,
	David Miller <davem@...emloft.net>,
	Ilpo Jarvinen <ilpo.jarvinen@...sinki.fi>,
	Nandita Dukkipati <nanditad@...gle.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] tcp: avoid cwnd moderation in undo

Anecdotally, I've seen more harm than good from cwnd moderation but I
don't have any data to back that up.  It's hard to categorically say
anything.  But I don't know what makes the cases where cwnd moderation
is applied special.

Some other sources of bursts include
- Send-limited applications that stall for some time but less than an
RTO and do a large write
- Receive-limited applications that stall for some time but less than
an RTO and do a large read
- "Ack compression," when acks are queued somewhere in the network and
flood out at line rate
- "Stretch acks," when the receiving TCP does not ack every segment
(for efficiency, etc.), or acks are lost in the network.

Since all of these may occur in the Open state, cwnd moderation is not applied.

While I'm adding to my wish list ;-), I will also say that the undo
logic seems unnecessarily complicated.  If you expect you might have
to undo what you just did, why not wait a bit?  Something like rfc4653
seems like it might be a better approach and might make the cwnd
moderation discussion moot.

Thanks,
  -John


On Tue, Mar 15, 2011 at 6:20 AM, Carsten Wolff <carsten@...ffcarsten.de> wrote:
> On Monday 14 March 2011, John Heffner wrote:
>> On Mon, Mar 14, 2011 at 3:10 PM, Yuchung Cheng <ycheng@...gle.com> wrote:
>> > On Mon, Mar 14, 2011 at 3:06 AM, Carsten Wolff <carsten@...ffcarsten.de>
> wrote:
>> >> The moderation is in place to avoid gigantic segment bursts, which could
>> >> cause unnecessary pressure on buffers. In my eyes it's already
>> >> suboptimal that the moderation is weakened in the presence of
>> >> (detected) reordering, let alone removing it completely.
>> >
>> > In the presence of reordering, cwnd is already moderated in Disorder
>> > state before
>> >  entering the (false) recovery.
>>
>> I've always been somewhat skeptical of the usefulness of cwnd
>> moderation.  First, I don't know that its behavior is well defined.
>> When *should* tcp_moderate_cwnd() actually be called, and why?
>>
>> Second, I've never liked the idea in general.  Reducing cwnd has an
>> effect lasting many RTTs, so reducing it in response to a transient
>> event like reordering seems dubious.  And it does not address many
>> causes of bursts, such as ack compression or stretch acks.
>
> I think the undo operations are a special case where it absolutely makes
> sense, because the cwnd _already_ has been reduced (down to 1 segment by RTO
> recovery, or, with its special mixture of ratehalving and newreno, Linux
> sometimes reduces cwnd far below half of it even in fast recovery.). The undo
> re-opens the window all at once, which may allow _really huge_ bursts. I don't
> know enough about the other causes of TCPs burstiness, I'm just concerned
> about allowing this special cause.
>
> Carsten
> --
>           /\-´-/\
>          (  @ @  )
> ________o0O___^___O0o________
>
--
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