Re: [tcpm] AD Review of draft-ietf-tcpm-hystartplusplus-09

Martin Duke <martin.h.duke@gmail.com> Wed, 07 September 2022 19:40 UTC

Return-Path: <martin.h.duke@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 78DA0C15790B; Wed, 7 Sep 2022 12:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztPimnUSj8Mj; Wed, 7 Sep 2022 12:40:47 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 DF07EC157902; Wed, 7 Sep 2022 12:40:47 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id g16so11266923qkl.11; Wed, 07 Sep 2022 12:40:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=PWiuz2A0CbQLgzmug0TTd7KqGRY+V8mAzxDJ0/zK398=; b=dCBovHgzAtVI1rBwroXfGZioLcOn1XFr7AZHq1ua5uL1dJU0F2a6GrhhK4dlCyFFi0 Su4INli3HNyfga8dwniv0fUFv9AoPhvK1+tNQbsSX4jUFfRyVTi5jnNmmSMNBJ8TC35v fPjiIQ8/nxtGB1uHO9v0aKkg/mV+JfTbT3vcseIe3P09gTUjqVEGltpjG2t2IDu+6egx He6JFDbe8n/KxYR+SSCIFUXun1lnSiVYeRU9xe9T+Mt/PJOF7JxT86ufWz5vzbMRp5uG s/glqZB7tcaq01tBsvq2EKhkYtxAzBaBONMHoNY0andB7v0cidyBkqlTCGI9kX2b0J+k fdlA==
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; bh=PWiuz2A0CbQLgzmug0TTd7KqGRY+V8mAzxDJ0/zK398=; b=60FH6uqPHtZJbr2a/hbjNefDoocwthoUEMtrZ56oIIygpYNavBPSipH/3mtVl5LfgB fZes8UtMpUxOaikxJ4GPSHiLYnrzgWTYQv/YFgPdARIn19asMDkWdO0EX+U1+EXED7pU fUJVNBTVT5npKllEHJdEJhyQ/bQm+ZpRt3Qe4pRQVCEoCacz+88042cRO4F8q2/zNVC/ MiAe7JFvAj8jJ1WxLuIvAuQtLg9Qf89w5QeyNXIpLclZ8U1ERlsbxFmXfi5bS2O2OV4G X6af+xF4+0ctjEbq1soi0t/tAc26N4uDoVPFiWLc3EIkDUSyevN6uTdhSu2HdyPdjBCh 1SAw==
X-Gm-Message-State: ACgBeo1KR4dTk3ClOWJnWlW7nTQn42OkIvjdCev+WFs5+h85GEONaoUI kWRrR8VujN0OtoBl+p9ZFu00CHCBnH1ZVgiip2yVdaMs
X-Google-Smtp-Source: AA6agR5EKTrUHW8stakTziFXSwipVSM4IL4RgURUPr0Xpu2YkIKj0TmdKGt1WBpdDM/IcnbEdmpP8yL40dJj017jMpc=
X-Received: by 2002:a37:8603:0:b0:6bb:54ab:4334 with SMTP id i3-20020a378603000000b006bb54ab4334mr4016417qkd.431.1662579646912; Wed, 07 Sep 2022 12:40:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxTikRRRLOtmO4bezXvjjDiQ3cpRNqtT_2YaEUQrFUrECw@mail.gmail.com> <0E94A985-516C-4287-9789-50D3A682211B@fh-muenster.de>
In-Reply-To: <0E94A985-516C-4287-9789-50D3A682211B@fh-muenster.de>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 07 Sep 2022 12:40:36 -0700
Message-ID: <CAM4esxS-3kZDLp-1n3JM3jOH=4ZLNaf0vsszMgqrJ7ss=jxcCg@mail.gmail.com>
To: Michael Tuexen <tuexen@fh-muenster.de>
Cc: draft-ietf-tcpm-hystartplusplus.all@ietf.org, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000043ddc905e81b7d44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/2RRoeCxwDx9tIn-U-c38XBY9Hz8>
Subject: Re: [tcpm] AD Review of draft-ietf-tcpm-hystartplusplus-09
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: Wed, 07 Sep 2022 19:40:48 -0000

I would be happier with some sort of limit on L. Maybe: the positive
integer L SHOULD be 2 and MUST be no more than 8(?) But whatever numbers
the community is comfortable with are fine with me.

I'd also be happier with a cut-and-paste of those considerations from 3465,
which should not be a lot of work.

The lower-effort approach is just to strike L from the document and let
people do what they've doing, which is use Ls well in excess of 2. But I'd
prefer we'd actually write it down because
(1) our standards are better if they reflect widespread behavior in the
internet; and
(2) it means we can finally make 3465 historic, as we have standards-track
documents that cover virtually all of its material.

If the community really cannot converge on sensible limits for L, then I'd
rather publish with no L than wait for a deadlock to resolve.

But as a way forward, I'd suggest:
1) the authors propose text that sets bounds on L (a SHOULD and a MUST) and
cut-and-pastes the considerations.
2) We do a consensus call on that in TCPM

if we have less than rough consensus, we can consider next steps.


On Sat, Sep 3, 2022 at 2:50 AM <tuexen@fh-muenster.de> wrote:

> > On 3. Sep 2022, at 00:52, Martin Duke <martin.h.duke@gmail.com> wrote:
> >
> > Thank you for this concise and very readable document.
> >
> > My only major concern is the old subject of RFC3465 (ABC) being
> Informative, but a downref if we make it Normative. In my opinion, the
> document as written is not implementable without 3465 and it should be a
> normative reference.
> >
> > If I am correct about the status quo, the only part of 3465 that is not
> in 5681 (and therefore still Experimental) is the use of L > 1 in slow
> start.
> >
> > There are three approaches to handling this problem.
> >
> > 1. Eliminate L from the spec, and use the RFC5681 slow start formula.
> What's bad about this is that IIUC we have no data with L=1. But we could
> say in Section 5 that the tests also used RFC 3465 with L=8 and the market
> decide what to do with that.
> >
> > 2. Send to the RFC Editor with a normative reference; the doc will be
> "done", but will not publish until ABC goes to PS (which is not imminent,
> to say the least).
> >
> > 3. What I think you've actually done here is standardized RFC3465
> behavior only when combined with CSS (i.e. a partial promotion of ABC). I
> think this is the best course of action, but if we're going to do that, we
> should go all the way:
> >
> > (a) Add a definition of L and a discussion of how to set it -- basically
> Sec 2.3 of RFC3465 but presumably with no L=2 limit. If we're going to
> publish a standard with a higher cap on L we really ought to have that
> discussion.
> >
> > (b) It can "update" or "obsolete" 3465 depending on whether or not the
> WG cares to keep the experimental status of ABC-without-CSS.
> >
> > The community apparently has consensus that L > 1, even L >  2, *in this
> context* is safe, so I don't see it as reckless to make this change.
> >
> > I'm happy to have a dialogue about this.
> Hi Martin,
>
> I think the intention was (3), at least it was my intention.
>
> What about only doing (a) by:
>
> i) Remove
>    The following pseudocode integrates Appropriate Byte Counting as
>    described in [RFC3465].  In particular, see [RFC3465] for the
>    definition of the variable L.
> ii) After the first usage of L:
>     Update the cwnd:
>       cwnd = cwnd + min (N, L * SMSS)
>     Add:
>     The positive integer L SHOULD be 1 and MAY be larger than 1.
>     See [RFC3465] for details of choosing L.
>
> That way we are  consistent with RFC 5681 and allow for higher values.
> The text in Section 5 gives a clear hint that L > 1 has been used.
> At least we used the above text in RFC 9260.
> We could also use
> See [RFC3465] for a discussion related to the choice of the value of L.
> or just leave out the reference to RFC3465 at all. I guess people are
> setting L differently anyway.
>
> What do you think?
>
> Best regards
> Michael
> >
> > NITS:
> > (3) s/definition/definitions
> >
> > (4.1) "The Inter Packet Arrival algorithm does not perform well." If
> there's a useful citation here (or for the results discussed in Section 5)
> that would be nice to include.
> >
> > (4.1) s/it's concluded that/the algorithm concludes
> >
> > Thanks again!
> > Martin
>
>