From: Yuchung Cheng <ycheng@google.com>
To: Kenneth Klette Jonassen <kennetkl@ifi.uio.no>
Cc: netdev <netdev@vger.kernel.org>,
Eric Dumazet <edumazet@google.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Neal Cardwell <ncardwell@google.com>,
David Hayes <davihay@ifi.uio.no>,
Andreas Petlund <apetlund@simula.no>,
Dave Taht <dave.taht@bufferbloat.net>,
Nicolas Kuhn <nicolas.kuhn@telecom-bretagne.eu>
Subject: Re: [PATCH v2 net-next 2/2] tcp: add CDG congestion control
Date: Tue, 9 Jun 2015 16:25:20 -0700 [thread overview]
Message-ID: <CAK6E8=c6Sz-OppmPVFK6G4zHuyZ5vydLACe43bb_gW-rnhWR2w@mail.gmail.com> (raw)
In-Reply-To: <CA++eYdvm3RVOvu4Eg9op7RaBcn0y6-mczTqgAzinto__WvXLWA@mail.gmail.com>
On Tue, Jun 9, 2015 at 3:41 PM, Kenneth Klette Jonassen
<kennetkl@ifi.uio.no> wrote:
> On Tue, Jun 9, 2015 at 7:44 AM, Yuchung Cheng <ycheng@google.com> wrote:
>> On Mon, Jun 8, 2015 at 10:43 AM, Kenneth Klette Jonassen
>> <kennetkl@ifi.uio.no> wrote:
> …
>
>>> +enum cdg_state {
>>> + CDG_UNKNOWN = 0,
>>> + CDG_FULL = 0,
>> why duplicate states?
>
> We explicitly infer a full or non-full queue in tcp_cdg_grad().
>
> The unknown state is semantically different; it is before we infer
> anything about the network.
>
> We could change the full state to have its own value. (It does not
> matter in the current code, but it could be useful for TCP_CC_INFO.)
>
>>> + if (hystart_detect & 1) {
>> Define 1 and 2 like cubic does?
>>> + prior_snd_cwnd = tp->snd_cwnd;
>>> + tcp_reno_cong_avoid(sk, ack, acked);
>>> +
>>> + if (ca->shadow_wnd) {
>>> + u32 incr = tp->snd_cwnd - prior_snd_cwnd;
>>> +
>>> + ca->shadow_wnd = max(ca->shadow_wnd, ca->shadow_wnd + incr);
>> u32 shadow_wnd may overflow?! there might be some bugs ...
>
> CDG can potentially operate without losses over some time, so
> shadow_wnd can reach U32_MAX on normal links.
> The max() should revert any increment that causes overflow/wrapping of
> shadow_wnd.
the situation you described could only happen if we didn't have the
application-limited check (i.e., tcp_is_cwnd_limited() in tcp_reno_cong_avoid).
I am really doubtful, even tho having a max won't hurt anything.
>
> We limit shadow_wnd to min(shadow_wnd / 2, snd_cwnd) in ssthresh().
>
>>> + if (ca->state == CDG_BACKOFF)
>>> + return max(2U, (tp->snd_cwnd * min(1024U, backoff_beta)) >> 10);
>>> +
>>> + if (ca->state == CDG_NONFULL && use_tolerance) {
>>> + bool is_ecn = (tp->prior_ssthresh == 0);
>>> +
>>> + if (!is_ecn) {
>>> + tp->ecn_flags &= ~TCP_ECN_DEMAND_CWR;
>>> + return tp->snd_cwnd;
>>> + }
>> I might be missing something here: cdg_backoff also calls
>> tcp_enter_cwr() that clears prior_ssthresh but it's not triggered by
>> ECE marks?
>
> That is ok. We set ca->state = CDG_BACKOFF in tcp_cdg_backoff() to
> distinguish a delay backoff.
>
>>
>> if the intention is to use loss tolerance only when undo is enabled
>> why not just check undo_marker?
>
> The intention is to not use loss tolerance if we receive an ECN signal.
>
> Inferring ECN from (prior_ssthresh == 0) is far from perfect of
> course, but it is always cleared when receiving ECN.
>
> In tcp_enter_loss(), undo_marker is set after calling ssthresh(). We
> could change that, but undo_marker is also imperfect for detecting
> ECN.
>
> If in doubt, let us remove the ECN check now. Then in a later patch
> set, we could try passing flag to ssthresh like you suggested. We
> should also look at tcp_dctcp if we do that.
+1 to split ecn handling in a separate (future) patch
>
>>> + if (use_shadow)
>>> + ca->shadow_wnd = min(ca->shadow_wnd >> 1, tp->snd_cwnd);
>>> + else
>>> + ca->shadow_wnd = 0;
>> it'd be good to not reset shadow_wnd, but only use it if use_shadow.
>> so we can monitor shadow_wnd
>> in TCP_CC_INFO in the future.
>
> Ok, then we should always set/maintain a shadow_wnd.
prev parent reply other threads:[~2015-06-09 23:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 17:43 [PATCH v2 net-next 1/2] tcp: export tcp_enter_cwr() Kenneth Klette Jonassen
2015-06-08 17:43 ` [PATCH v2 net-next 2/2] tcp: add CDG congestion control Kenneth Klette Jonassen
2015-06-09 5:44 ` Yuchung Cheng
2015-06-09 22:41 ` Kenneth Klette Jonassen
2015-06-09 23:25 ` Yuchung Cheng [this message]
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='CAK6E8=c6Sz-OppmPVFK6G4zHuyZ5vydLACe43bb_gW-rnhWR2w@mail.gmail.com' \
--to=ycheng@google.com \
--cc=apetlund@simula.no \
--cc=dave.taht@bufferbloat.net \
--cc=davihay@ifi.uio.no \
--cc=edumazet@google.com \
--cc=kennetkl@ifi.uio.no \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.kuhn@telecom-bretagne.eu \
--cc=stephen@networkplumber.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 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).