Re: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03

Junho Choi <junho.choi@gmail.com> Thu, 30 April 2020 07:09 UTC

Return-Path: <junho.choi@gmail.com>
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 D1A033A09F3 for <tcpm@ietfa.amsl.com>; Thu, 30 Apr 2020 00:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dcL0vnn76hPS for <tcpm@ietfa.amsl.com>; Thu, 30 Apr 2020 00:09:49 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9833A09F1 for <tcpm@ietf.org>; Thu, 30 Apr 2020 00:09:49 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id z1so3121325vsn.11 for <tcpm@ietf.org>; Thu, 30 Apr 2020 00:09:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0g6V+Qj5+xbattY6V0rCVTh5SnQip20bdGhlY1XSgpI=; b=qL5IIFtVbSHsbVDQI+vqMyOncmqEJJefY/5QC9e/4rxjQkIm4NsZ/vXfxlt7BbCRiO XHm28tGlSCgyTAWEjtRAcZ0j7YfErv/3VC3kc+PCiv5AnI547/oSuibBAPnt+9gp0zeq jxkCDZWB+X8J14hfDjtntmDr6kyGVj0yrm36oGNt8PRwBwyIrfz5ZNnig4rgSsBzIXM0 OqOgyl1wL9kbxHFOurgXxktpULmXYc0+acmzjK6spUo7QMziOo+16vp0hQCHXva7rqNB l0hMLJ3N64/z3KBrVIbmbw2VAAJSmTTB8hIsHUZkOkPbadpVOs44VqzmXjg2UWe2rVSn 7L/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0g6V+Qj5+xbattY6V0rCVTh5SnQip20bdGhlY1XSgpI=; b=B+GRkhhlww9zVroKz3FaVb4rLc+bOIj0WtIEvEbcEw6JjgpUlSo1oX68j8ehrjjRwB ljpBqOigSLO4nzIMnGdlz7Pz9dqj+8ALzHFY2UV0kCsMSJX+4WRcpjLaD0ZtxJ1xAvHd kDJkKBNTekkBb3kDkAF3dXeJwjsWJBu0ES6WSD18vuqZLLROZgZ61DcjbZOh1BPy/al4 yHhD7qg7mmDAr+Jqtdu4RdecUY38neEVqiMFA7TafGTRrnoSkWROYJ+3DVn3aR9s+iDu 6DGk8AOPqZLZxKUw8ZDbJIeEyWcrIOCNkKKG6E1MGnmZBlhlpE+9sZJWKkwhd5qzfswB t9jg==
X-Gm-Message-State: AGi0PuYXAUzFT6W0gkmaLnJEBtFUdpUsfY9zIBSMjhXyDHBjMRFpYP2z 7C4ulMhCdB8mZXHikbgpAj58c5HvVWk3qf9iIq9+LI9B
X-Google-Smtp-Source: APiQypKLaMycpJDspY6KoeVRByk8y4hj2cYlFhdOhc+X5AAfAFz/dXFBVH8iCDto2XZl6yk0gLAYDE/LBBaKUCsMAyA=
X-Received: by 2002:a67:f718:: with SMTP id m24mr1644370vso.236.1588230587888; Thu, 30 Apr 2020 00:09:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxT=0A8MS3-bwsywvxOdix0b8FQPKo+X96abstovBPCyNg@mail.gmail.com> <CAK6E8=dVW_OnSndU=HjBpaxQD-zs2tOYZK4whDc28YQ8N3haOA@mail.gmail.com> <CAK6E8=cZ5Aa6P+mazNSmZ20tmwO+PrDs8YtBeDfu7vOhOP=AAg@mail.gmail.com> <CADVnQyn93VDsLkKnSbZseroMyBAXtYy2=KKVN4XQbqPiA3Z52w@mail.gmail.com>
In-Reply-To: <CADVnQyn93VDsLkKnSbZseroMyBAXtYy2=KKVN4XQbqPiA3Z52w@mail.gmail.com>
From: Junho Choi <junho.choi@gmail.com>
Date: Thu, 30 Apr 2020 00:09:11 -0700
Message-ID: <CAJ5e+HBD=g25vwfcUs34CUCgP+Zv_=Fy1zL7SQ9TCHiQmgLduw@mail.gmail.com>
To: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>
Cc: Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000033aa005a47cc03e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/tzH899lZ1790RxpnVMjk6hXNpDM>
Subject: Re: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 30 Apr 2020 07:09:51 -0000

FYI, my HyStart++ implementation for quiche is just an option for slow
start, so can be set for Reno and CUBIC both.

On Wed, Apr 29, 2020 at 7:30 PM Neal Cardwell <ncardwell=
40google.com@dmarc.ietf.org> wrote:

> I support adoption of this work as well. The HyStart++ algorithm has
> some nice improvements over the original delay-based HyStart
> mechanism.
>
> The draft already seems to do a nice job of stating the algorithm
> generically, without tying it to CUBIC. But I like Yuchung's idea to
> explicitly state that the algorithm can be used for Reno or CUBIC.
>
> neal
>
> On Wed, Apr 29, 2020 at 6:09 PM Yuchung Cheng
> <ycheng=40google.com@dmarc.ietf.org> wrote:
> >
> > btw it might be good to see the draft discusses applying it to other
> C.C. that uses ssthresh too in the draft, particularly RFC5681 reno
> >
> > On Wed, Apr 29, 2020 at 12:09 PM Yuchung Cheng <ycheng@google.com>
> wrote:
> >>
> >> +1 on adoption
> >>
> >> two questions
> >> 1. RttSampleCount. Since the counter is incremented on a per ACK
> >> basis, the receiver behavior may significantly influence the actual
> >> hystart timeline. For example a receiver acking one full cwnd burst vs
> >> acking every packet (or even every byte). it'd be good to clarify if
> >> the intended rounds or time-scale in hystart++ design
> >>
> >> 2. "In practice, the Inter- Packet Arrival algorithm does not perform
> >> well and is not able to detect congestion early, primarily due to ACK
> >> compression." In my experience, another reason is it relies on packets
> >> being pushed out in a window of burst in slow start. Therefore in
> >> paced slow start (e.g. slow_start w/ linux fq/pacing) often produces
> >> premature exit as well. I am curious if the authors have similar
> >> experience?
> >>
> >> Lastly, I am a fan of the BBR startup algorithm for obvious reasons.
> >> The algorithm can be easily ported to produce an ssthresh for
> >> conventional C.C.. It'd be great to see some words describing the
> >> difference and even some real comparisons. BBR startup definitely
> >> requires a lot more states (e.g. to track bw) for example. so there
> >> are pros & cons.
> >>
> >> On Wed, Apr 29, 2020 at 10:32 AM Martin Duke <martin.h.duke@gmail.com>
> wrote:
> >> >
> >> > I support adoption of this work.
> >> >
> >> > I would also encourage anyone in the WG thinking about implementing
> this draft to speak up. If this set is not null, I would encourage Praveen
> to move this draft to the Proposed Standard (preferred) or at least
> Experimental track.
> >> >
> >> > Martin
> >> > _______________________________________________
> >> > 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
>


-- 
Junho Choi <junho dot choi at gmail.com>