All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hagen Paul Pfeifer <hagen@jauu.net>
To: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	Dave Taht <dave.taht@gmail.com>,
	Stephen Hemminger <shemminger@vyatta.com>,
	Thomas Graf <tgraf@infradead.org>,
	netdev <netdev@vger.kernel.org>, Jim Gettys <jg@freedesktop.org>
Subject: Re: [PATCH] sch_red: fix red_change
Date: Wed, 7 Dec 2011 23:57:48 +0100	[thread overview]
Message-ID: <20111207225747.GA4758@nuttenaction> (raw)
In-Reply-To: <alpine.DEB.2.00.1112051221510.31705@wel-95.cs.helsinki.fi>

* Ilpo Järvinen | 2011-12-05 13:42:44 [+0200]:

>I disagree. If there's any slow starting flow that alone can fill the 
>bottleneck, anything significantly larger than RTT just harms. RED is 
>just "too slow" if you follow the recommended parametrization..
>
>In a core router you can probably get away with multiple RTTs, but near 
>edge that is a grave mistake due to how slow-start behaves. With average 
>based on many RTTs, RED still estimates that the link has low load while 
>congestion has escalated to higher dimensions due to slow start. As a 
>result, RED graciously falls back to tail-drop once the physical queue 
>runs out and the flows respond allowing the load to decrease. However, 
>finally RED reaches a state where it starts to "pro-actively" react to an 
>"incipient congestion"?!? :-/ => Problem is made worse by those extra 
>drops/marks happening too late.

But then one question Ilpo: drive IW10 or IW14 the behavior even worse?
Especially if n connections start almost simultanously? You did some analysis
on this topic.


HGN

  reply	other threads:[~2011-12-07 22:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-30 20:25 [RFC iproute2] sch_red: TC_RED_HARDDROP Eric Dumazet
2011-11-30 22:36 ` Stephen Hemminger
2011-12-01 21:06   ` [PATCH] sch_red: fix red_change Eric Dumazet
2011-12-01 21:35     ` Dave Taht
2011-12-01 21:48       ` Jim Gettys
2011-12-01 21:57       ` Eric Dumazet
2011-12-01 22:04         ` Jim Gettys
2011-12-05 11:42         ` Ilpo Järvinen
2011-12-07 22:57           ` Hagen Paul Pfeifer [this message]
2011-12-02  0:25     ` David Miller
2011-11-30 23:29 ` [RFC iproute2] sch_red: TC_RED_HARDDROP Thomas Graf

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=20111207225747.GA4758@nuttenaction \
    --to=hagen@jauu.net \
    --cc=dave.taht@gmail.com \
    --cc=eric.dumazet@gmail.com \
    --cc=ilpo.jarvinen@helsinki.fi \
    --cc=jg@freedesktop.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    --cc=tgraf@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.