Re: [tcpm] About Cubic when slow start exits with no loss

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Fri, 15 September 2017 09:27 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925BB13308B for <tcpm@ietfa.amsl.com>; Fri, 15 Sep 2017 02:27:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YdJynmVMsDk for <tcpm@ietfa.amsl.com>; Fri, 15 Sep 2017 02:26:58 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F8813306D for <tcpm@ietf.org>; Fri, 15 Sep 2017 02:26:57 -0700 (PDT)
Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6D54C2784C4 for <tcpm@ietf.org>; Fri, 15 Sep 2017 18:26:55 +0900 (JST)
Received: by mail-yw0-f176.google.com with SMTP id v137so1094510ywg.5 for <tcpm@ietf.org>; Fri, 15 Sep 2017 02:26:55 -0700 (PDT)
X-Gm-Message-State: AHPjjUi1yNytg678j9TnOPLhxo70X9/eVOTGv0jKZ8AbaQDE3MfYoPuq xVvUr/OVa14TmOfRvMa2IKOrVmnNx3q/50zCX18=
X-Google-Smtp-Source: AOwi7QAjwGilpgkKN5bWjF6zoD+TGSk81E6xFD309aOjOk/Rt5lkzUe0TuxEXHh69H5E94JUqgF4ozpwHKl3T6KRtas=
X-Received: by 10.37.221.135 with SMTP id u129mr20176780ybg.260.1505467613958; Fri, 15 Sep 2017 02:26:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.64.145 with HTTP; Fri, 15 Sep 2017 02:26:53 -0700 (PDT)
In-Reply-To: <807840A3-8F95-44FB-8037-87F92F64F747@ifi.uio.no>
References: <ce55d81d-0989-6907-1d1b-d63f87afdbad@epfl.ch> <cc55fcbb-0ea2-0958-679e-772e5ac9a31a@unl.edu> <78ed3ceb-9814-994c-e4ed-e0c8a145cfe3@epfl.ch> <807840A3-8F95-44FB-8037-87F92F64F747@ifi.uio.no>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Fri, 15 Sep 2017 02:26:53 -0700
X-Gmail-Original-Message-ID: <CAO249ycw45i3KHradmZTx6YhQjd=M2gHfBgJn1unZdn+hKtMkg@mail.gmail.com>
Message-ID: <CAO249ycw45i3KHradmZTx6YhQjd=M2gHfBgJn1unZdn+hKtMkg@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Cc: Le Boudec Jean-Yves <jean-yves.leboudec@epfl.ch>, "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="001a114bc9d659dc06055936fe57"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/js52esE7H30Z7opD8mjGSTYifEA>
Subject: Re: [tcpm] About Cubic when slow start exits with no loss
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Sep 2017 09:27:01 -0000

I also agree. I believe it won't affect our consensus on the draft as it is
a small additional tip.
Although the doc already has been requested for publication several days
ago, I prefer adding it to the draft if there's no problem for the
procedure.
I hope we still have a little time before IESG starts reviewing it.

Thanks,
--
Yoshi



On Fri, Sep 15, 2017 at 12:44 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
> Hi,
>
> I give a +1 to this request: I remember searching an answer to the same
> question, long (actually a few years) ago - I looked at the (old) I-D,
found
> nothing, and gave up after a bit of Linux code reading, at that time.
>
> I should have remembered to request this being added when the Cubic draft
> was picked up again - indeed this is an important thing to add, IMO.
>
> Cheers,
> Michael
>
>
>
> On Sep 15, 2017, at 8:57 AM, Le Boudec Jean-Yves
> <jean-yves.leboudec@epfl.ch> wrote:
>
> Dear Lisong
>
> thanks for the pointer. Shouldn't that be also described in the ID ?
>
> Best, JY
>
>
> On 14.09.2017 20:10, Lisong Xu wrote:
>
> Dear Jean-Yves,
>
> Yes, if the first slow start ends with no loss, Cubic enters congestion
> avoidance. In this case, both K (i.e., bic_K) and W_max (i.e.,
> bic_last_max_cwnd) are still their initial values (i.e., 0), and the
origin
> of the cubic function (i.e.,bic_origin_point) is set to the current
> congestion window size (i.e., cwnd). In addition, in this case, Cubic
> maintains a minimum cwnd increase speed of 5% per RTT (line 308-309 at
> http://elixir.free-electrons.com/linux/latest/source/net/ipv4/tcp_cubic.c
).
>
> Thanks
> Lisong
>
> On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote:
>
> Hi,
>
> in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I did
not
> find what Cubic does if slow start ends with no loss. I guess congestion
> avoidance is entered, but then how does Cubic computes W_max and K when
> congestion avoidance is entered following slow start with no loss ? It
seems
> reasonable to have K=0 and W_max set to a very large value, right ?  Did I
> miss anything ?
>
> JY
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>