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 [off-list ref] wrote:

On Monday 14 March 2011, John Heffner wrote:

quoted

On Mon, Mar 14, 2011 at 3:10 PM, Yuchung Cheng [off-list ref] wrote:

quoted

On Mon, Mar 14, 2011 at 3:06 AM, Carsten Wolff [off-list ref]

wrote:

quoted

quoted

quoted

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________