Re: [tcpm] I-D Action: draft-ietf-tcpm-hystartplusplus-12.txt

Neal Cardwell <ncardwell@google.com> Thu, 12 January 2023 01:08 UTC

Return-Path: <ncardwell@google.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 A2C4DC18F7FC for <tcpm@ietfa.amsl.com>; Wed, 11 Jan 2023 17:08:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.596
X-Spam-Level:
X-Spam-Status: No, score=-17.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu02zh5d2xKU for <tcpm@ietfa.amsl.com>; Wed, 11 Jan 2023 17:08:23 -0800 (PST)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88E6C14CEFD for <tcpm@ietf.org>; Wed, 11 Jan 2023 17:08:23 -0800 (PST)
Received: by mail-vs1-xe2d.google.com with SMTP id k4so17574775vsc.4 for <tcpm@ietf.org>; Wed, 11 Jan 2023 17:08:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=u+Y877ZM+Pcm2BaYtqFPOWpZxPgl4EbXAPcILhyNAgY=; b=mZlvJCfxjsfvu18Lrs35gt76uHp+FaOxNKIvQwJfF8jwGQMuR4cZzXG2gViOi2A4/A RtCz2X7CHI5TJDiXHe0ReD/yYqY/sslpvT6zFW2I+QBRQkmeb5Bg6m52J1a5eEDebunr de8FVgTBWfqTPYonNovQ3vZD3V7Ov+GwWcKNYyHndz7yGAxnAK3Pg59wIQ0Ajn3VqS4c +Bgr9WlTl3dSFPOf0QCfFJYssnIpPaqxWMHIZnkqpRONulwKLg/nz31HKfmiQd/A/iC1 qcjoeGSR2uMDURbXXELWX9LiHGroZcHEVAQqoZjyoX2IXnmXt8UUBq9eobQbN/RMoCSk BlRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=u+Y877ZM+Pcm2BaYtqFPOWpZxPgl4EbXAPcILhyNAgY=; b=32D1/UGXDlzcqRQD/PURn4SU3g153kPYd6ODDLAKUwIQjzORO1V1KSOvuN/OQ5TF7Y 6Bi2Gvt+PiucJtBjpj/UMLFhd+Q3X1YLEZbC6CIyjwL7cy6qDQjfcTBJCqwwylQNzqWH nrQQ2lM5cjVRf3M0O8Eu8I2V0gxkKj7FoHr73lihhkn0uJ7kEhbMKvhUGx9Tx72OvgJo lPJ+C40Jfyz0qmfWkbAi2DpwcjUHy5ki/+zNQ+ya7y2HKMpYDYCP5X1Zv+/w8eAeehAJ La5nkRw6P8eZ7x5TwEz0zj8fbP7r/ZCgcuTRPNqDKZoZ+r7NOOzHyNOiRHpR4WMFNPaM WgbQ==
X-Gm-Message-State: AFqh2koN3pdf6FVhsYeOXiAYOOPbz6YiJgILeLfXHdBLkxJqAmLDlXSY qlANwBwN5fGHz8v719Q20Lpmkeq79Z1K802NVy8TdA==
X-Google-Smtp-Source: AMrXdXu6ID4wvCkKphauxd0g+xiSBEom/CEdsjFh6OEOazGDTuCFsBksrRqnh8Q/ufYYIWRQELqHgaN9wMcddyjDTu4=
X-Received: by 2002:a05:6102:36c4:b0:3d0:b301:2cce with SMTP id z4-20020a05610236c400b003d0b3012ccemr1921570vss.65.1673485702800; Wed, 11 Jan 2023 17:08:22 -0800 (PST)
MIME-Version: 1.0
References: <167330410669.3759.12442685855520700837@ietfa.amsl.com> <CADVnQymKgWE+Jx8-eTw=1nZmpgb2tAYbSUxxKVm=Rgw6W8jmVw@mail.gmail.com> <CADVnQy=W+_nOk9rPPuV0yqqh1CxNz_J_d53tL40Er462CafDaw@mail.gmail.com> <CAL=F3y+9CNBX1+LSAG+TzvW_Hc8KgZOdurNB6x7CF5ROMZ_Gsg@mail.gmail.com>
In-Reply-To: <CAL=F3y+9CNBX1+LSAG+TzvW_Hc8KgZOdurNB6x7CF5ROMZ_Gsg@mail.gmail.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Wed, 11 Jan 2023 20:08:06 -0500
Message-ID: <CADVnQy=ONj57poWHeQA4d=jduvpGU3vNA73JcmCcSfu1QkbKMA@mail.gmail.com>
To: Praveen Balasubramanian <pravb.ietf@gmail.com>
Cc: tcpm@ietf.org, huanyi@microsoft.com, Matt Olson <maolson@microsoft.com>
Content-Type: multipart/alternative; boundary="000000000000da7bda05f206c005"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/oySisPp-GZMR-ZPdGYtvfkpQmvg>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-hystartplusplus-12.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
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, 12 Jan 2023 01:08:27 -0000

Your proposal to remove the description of the Linux TCP experience from
the "Deployments and Performance Evaluations" section sounds very
reasonable to me. I don't have any concerns with removing that completely.
I agree that it mostly just seems to cause confusion.

thanks,
neal


On Wed, Jan 11, 2023 at 6:47 PM Praveen Balasubramanian <
pravb.ietf@gmail.com> wrote:

> I see, thanks Neal for the clarification. I then suggest that we eliminate
> this deployment experience line completely because its not with the
> proposed algorithm in this document and that it will confuse new developers
> as to why the document suggests using pacing with L=infinity when the
> default in Linux contradicts it.
>
> Any concerns with just removing this line entirely?
>
> On Wed, Jan 11, 2023 at 2:07 PM Neal Cardwell <ncardwell@google.com>
> wrote:
>
>> Martin pointed out out-of-band that my various attempts at explaining
>> this point have not been clear, so let me try to express this a different
>> way:
>>
>> For about the last decade the Linux TCP default has been: [ CUBIC +
>> Hystart + L=infinity + unpaced ]. This is because the commonly deployed
>> qdiscs for the major Linux distributions do not implement pacing.
>>
>> For 2013-2016 Google/YouTube Linux TCP ran with: [ CUBIC + Hystart +
>> L=infinity + paced ]. This was using the fq qdisc to implement pacing.
>>
>> best regards,
>> neal
>>
>>
>> On Tue, Jan 10, 2023 at 10:24 AM Neal Cardwell <ncardwell@google.com>
>> wrote:
>>
>>> Looks like there is still one significant word in the "Deployments and
>>> Performance Evaluations" section that needs to be updated to be accurate.
>>>
>>> Existing draft-ietf-tcpm-hystartplusplus-12 text:
>>>
>>>   There has been over a decade of experience using the
>>>   original Hystart algorithm for all TCP connections in the
>>>   Linux operating system with pacing *enabled* and an
>>>   actual L = infinity.
>>>
>>> Suggested text:
>>>
>>>   There has been over a decade of experience using the
>>>   original Hystart algorithm for all TCP connections in the
>>>   Linux operating system with pacing *disabled* and an
>>>   actual L = infinity.
>>>
>>> I mentioned the rationale in the "Re: [tcpm] Changes to
>>> draft-ietf-tcpm-hystartplusplus after WGLC" thread on Nov 29:
>>>
>>>
>>> https://mailarchive.ietf.org/arch/msg/tcpm/CSzCgxxSLrO9u63dymyyxqB6bD4/
>>>
>>> cheers,
>>> neal
>>>
>>>
>>> On Mon, Jan 9, 2023 at 8:53 PM <internet-drafts@ietf.org> wrote:
>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the TCP Maintenance and Minor Extensions
>>>> WG of the IETF.
>>>>
>>>>         Title           : HyStart++: Modified Slow Start for TCP
>>>>         Authors         : Praveen Balasubramanian
>>>>                           Yi Huang
>>>>                           Matt Olson
>>>>   Filename        : draft-ietf-tcpm-hystartplusplus-12.txt
>>>>   Pages           : 9
>>>>   Date            : 2023-01-09
>>>>
>>>> Abstract:
>>>>    This document describes HyStart++, a simple modification to the slow
>>>>    start phase of congestion control algorithms.  Traditional slow start
>>>>    can overshoot the ideal send rate in many cases, causing high packet
>>>>    loss and poor performance.  HyStart++ uses a delay increase heuristic
>>>>    to find an exit point before possible overshoot.  It also adds a
>>>>    mitigation to prevent jitter from causing premature slow start exit.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-hystartplusplus/
>>>>
>>>> There is also an htmlized version available at:
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-hystartplusplus-12
>>>>
>>>> A diff from the previous version is available at:
>>>>
>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-hystartplusplus-12
>>>>
>>>>
>>>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>>>> :internet-drafts
>>>>
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>