Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis

Yoshifumi Nishida <nsd.ietf@gmail.com> Wed, 23 February 2022 09:17 UTC

Return-Path: <nsd.ietf@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 E85903A0EE1; Wed, 23 Feb 2022 01:17:01 -0800 (PST)
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 y2CNQfQvlILF; Wed, 23 Feb 2022 01:16:57 -0800 (PST)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 CDEDA3A0EDF; Wed, 23 Feb 2022 01:16:56 -0800 (PST)
Received: by mail-qv1-xf2d.google.com with SMTP id e22so7142780qvf.9; Wed, 23 Feb 2022 01:16:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8j2O7tw0kLQZ3Oyb3WF9ntiCkffdq/sJWUJb3dO3VnM=; b=GXjb9jkHUOxSwmJjswb2TpYbmr/UTOvsNlChts4fE3ryN60AH+d5NQpSxMn3xnVNsC clVYExcJccHf7h0+aFQPVWkF37osxg79Yb5f3GRtBAu5fPIbaTAN1cjjToqEGJ/SIYx0 6guW9yrzgnfDWhA5EQG3OT6yfc6a3SLvTVAgxeo74GbHmkkmF79wEOs9drVTZgvCI7+e o0nX0S1faslsXuS2Daw6MYdpSIqRFvdH8I9LtXKs4HW/A+rA6KrVAwkf4Tp3Dixm9LPK 945KyvaRE0e4+aAJyQA6tSZQkrgAARDA4CLO9sJeCJfqFt/TTFVDFxp6uTMRI8Ufhdtx P/nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8j2O7tw0kLQZ3Oyb3WF9ntiCkffdq/sJWUJb3dO3VnM=; b=siPgugcQ7tpYSVenx+C/Ns8iYxednrXGavnV8D0QSn0xoXxTmMCmgY0SBLp4Pa8jXx BtH+5lejJlFnlyMIcbTYgs7l7VBW60yHdDkpj7H13hDoe5TGBYgfsDzDK/Xs7mGMAtOd uIhk5M8zUuQkof0z1jFr5RnbD9lj0YDPZzA4nhb/uTaa6tJU21m8EKwXp0CObXt8v1T3 ViIun4w06Cqm5vukz/w5PErcu5Ict01rEErF9BJUa9KigEOr/g6iSFsvBquewR+EgoQk ozvtGTA9xxsHM6Dmk7XORN+8iPfJy9WzPTwEg0JHNlpAaWRqqMQrGskmWUzlcWbr8Ofn RYKg==
X-Gm-Message-State: AOAM532TuSuMfOfS4d/zAY+Ywla93ih89iJ8pbPzaBiKlebt9/bjZcFV ZfEcS2tgKBWv3QFKSyqia5FjD1pCZFQkwxf71jOUh/sf
X-Google-Smtp-Source: ABdhPJwcHwM8FrgfyqbBralUv5icDce8JlhkyTI2wlg3HtXyaLPcLND+FPzbyUybcHjB0JjVbmcNIEL8Xa+61sBn77c=
X-Received: by 2002:ad4:5de2:0:b0:42c:452b:351d with SMTP id jn2-20020ad45de2000000b0042c452b351dmr22987828qvb.111.1645607815520; Wed, 23 Feb 2022 01:16:55 -0800 (PST)
MIME-Version: 1.0
References: <164318837039.21788.17451980682651967578@ietfa.amsl.com> <EEA435EC-AAAC-4899-8E94-2D54EDE5F72E@eggert.org> <CAAK044S9HQXvfvgM6mBuvOWJPHtCaa6xo6CoP2r8Vq61tKaY5g@mail.gmail.com> <alpine.DEB.2.21.2202120048000.4019@hp8x-60.cs.helsinki.fi> <CAAK044SUv2pjPSi_9jitNdtTHtGR-DVhiEn77yCf8M6B=bgKwQ@mail.gmail.com> <alpine.DEB.2.21.2202171538190.4019@hp8x-60.cs.helsinki.fi> <CAAK044TwWJq0PgVSeHU7LfEwacPuix8KHqrBGXB+TTrVaFh0-Q@mail.gmail.com> <alpine.DEB.2.21.2202181052240.4019@hp8x-60.cs.helsinki.fi> <CAAK044RR6HTHKOgaoh4hkssXugSHMc+dV_2Ru3xLPsLaYRR0aA@mail.gmail.com> <718D13E5-D813-455B-8541-2396EA1F5CA8@eggert.org> <e8d7113c-47fa-7f91-54db-f7571840cd85@bobbriscoe.net>
In-Reply-To: <e8d7113c-47fa-7f91-54db-f7571840cd85@bobbriscoe.net>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Wed, 23 Feb 2022 01:16:44 -0800
Message-ID: <CAAK044RCR6zdVKb602+W0V13_fbmDW5PaEtP+Bgz6OAEUtOifA@mail.gmail.com>
To: Bob Briscoe <in@bobbriscoe.net>
Cc: Markku Kojo <kojo@cs.helsinki.fi>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000048a4cf05d8abedc5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/OArT4VCGKLUEISIdv92y__IUQvE>
Subject: Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis
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: Wed, 23 Feb 2022 09:17:02 -0000

Hi Bob, everyone,

I also think the points raised by Markku are valid and should be
highlighted for future work. But, at the same time, I am not sure it is
reasonable to delay producing standard docs.

What I am wondering is if it would make sense to publish these points as an
RFC to indicate "we believe they are acceptable for PS, but will need long
term analysis and evaluations as the Internet evolves."
Because we know they are a bit more aggressive than what have been done
before, but they are the feature, not bugs as Bob mentioned.
In this way, we don't have to hold the doc for a long time.

I think we can add more points in this doc, for example, initial window.
I believe we'll discuss promoting RFC6928 as a PS in the near future, but
if we apply "wide deployments and experiences are not enough" policy, it
may take a very long time while RFC9002 already allows it.
I am thinking this approach could allow us to treat IW10 for TCP and IW10
for QUIC more or less equally.
--
Yoshi

On Mon, Feb 21, 2022 at 4:11 PM Bob Briscoe <in@bobbriscoe.net> wrote:

> Yoshi, Markku,
>
> Many of the technical points Markku raised were important omissions from
> the rfc8312bis draft. Whatever status we give the eventual RFC, they should
> be highlighted as areas that need further work, either known weaknesses or
> just areas where we don't have enough data to know whether they are
> weaknesses. I tried to help find useful references for experiments already
> done around those points, and I tried to help write such text.
>
> However, I cannot agree with some of Markku's statements about process.
>
> #1: The rules can change It's OK to quote RFCs, but it's also OK for us
> to reach consensus that certain aspects of old RFCs are outdated, as long
> as we give our reasons, and there is rough consensus around that. We are
> all consenting adults - we don't have to be limited by RFCs from the past
> if we collectively don't want to be.
>
> I have not noticed a need for the above "rule #1" in this discussion yet,
> but I'm just putting it out there, so if anyone needs to invoke it later,
> they can't be accused of inventing a rule for their own convenience.
>
> #2: There is no TCP-compatibility requirement Yes, CUBIC is not
> TCP-compatible. But that's a feature, not a bug. Words like
> 'TCP-compatible' or 'fair' sound nice, but do not be fooled into thinking
> that an RFC recommends or requires you to behave in a certain way just
> because it has used a nice-sounding word for it.
>
> For an RFC to recommend or require something, it has to say SHOULD or
> MUST. So when BCP 41 [RFC2914] defines 'TCP-compatible', and talks about
> what is necessary to be 'fair', it implies nothing about whether you should
> or must be TCP-compatible, or fair; unless it actually says you SHOULD or
> MUST be TCP-compatible, or fair. *No RFC says that.*
>
> BCP 133 [RFC5033] and others have written careful words about straying
> from equal flow rates (quoted below). That gives a checklist for people
> like us who come along later. But it also respects our right to make a
> decision on whether/how to publish a CC RFC based on our own present-day
> knowledge and experience. To quote the relevant guideline in BCP 133
> [RFC5033]:
>
>    (1) Impact on Standard TCP, SCTP [RFC2960 <https://www.rfc-editor.org/rfc/rfc2960>], and DCCP [RFC4340 <https://www.rfc-editor.org/rfc/rfc4340>].
>
>        Proposed congestion control mechanisms should be evaluated when
>        competing with standard IETF congestion control [RFC2581,
>        RFC2960 <https://www.rfc-editor.org/rfc/rfc2960>, RFC4340 <https://www.rfc-editor.org/rfc/rfc4340>].  Alternate congestion controllers that have a
>        significantly negative impact on traffic using standard
>        congestion control may be suspect and this aspect should be part
>        of the community's decision making with regards to the
>        suitability of the alternate congestion control mechanism.
>
>        We note that this bullet is not a requirement for strict TCP-
>        friendliness as a prerequisite for an alternate congestion
>        control mechanism to advance to Experimental.  As an example,
>        HighSpeed TCP is a congestion control mechanism that is
>        Experimental, but that is not TCP-friendly in all environments.
>        We also note that this guideline does not constrain the fairness
>        offered for non-best-effort traffic.
>
>        As an example from an Experimental RFC, fairness with standard
>        TCP is discussed in Sections 4 <https://www.rfc-editor.org/rfc/rfc5033.html#section-4> and 6 <https://www.rfc-editor.org/rfc/rfc5033.html#section-6> of [RFC3649 <https://www.rfc-editor.org/rfc/rfc3649>] (HighSpeed TCP)
>        and *using spare capacity* is discussed in Sections 6 <https://www.rfc-editor.org/rfc/rfc5033.html#section-6>, 11.1 <https://www.rfc-editor.org/rfc/rfc5033.html#section-11.1>, and 12 <https://www.rfc-editor.org/rfc/rfc5033.html#section-12>
>        of [RFC3649 <https://www.rfc-editor.org/rfc/rfc3649>].
>
> The rfc8312bis draft has a section on 'using spare capacity' precisely
> because that's what was considered acceptable about CUBIC and the new
> generation of hi-BDP CCs developed at that time, as I've emphasized in the
> last para above.
>
> #3: A process for publishing EXP RFCs doesn't cover publishing non-EXP
> RFCs (by definition)
> This IESG statement on "Experimental Specification of New Congestion
> Control Algorithms
> <https://www.ietf.org/about/groups/iesg/statements/experimental-congestion-control/>"
> says it defines the process for a CC to be published as an Experimental
> RFC. It does not say it is the process that /all/ CCs have to follow to
> enter the standards track.
>
> Before invoking that process, one has to determine whether it is
> applicable to this case. The IESG statement contains a sentence about how
> to determine its applicability:
>
> The decision of whether a specific new congestion control schemes goes
> beyond the principles of [RFC2914] and hence will undergo the process
> described in this document lies with the transport area directors, who will
> use the expertise of the transport area directorate and other congestion
> control experts to aid their decision.
>
> Since RFC2914, we've had RFC3246 explaining why Reno is unscalable, and
> RFC5033 (quoted above) giving guidelines for designers of new CCs. So we
> can debate whether the process that Markku quoted is relevant to this case,
> to help the AD to decide whether to follow the process or not.
>
> #4 EXP or STD? My view
> Reno is worse than other CCs in some respects. Nearly everyone has
> abandoned it. So, if someone asked you why Reno is the IETF's only stds
> track CC, what would you say ...?
>
> As I already said, we have to stop thinking that the stds track requires a
> CC algorithm to be perfect. A CC certainly mustn't have failure or collapse
> modes, but it's performance doesn't have to be perfect in all cases. For
> instance, CUBIC has known poor utilization over radio links. That didn't
> stop Reno from being on the stds track. For me, the IETF needs a new CC on
> the stds track, and CUBIC is the most natural candidate.
>
> However, we must not set a precedent for any old CC to move to the stds
> track. So we must document it's weaknesses and failings, and explain why
> they are not serious (if that is the case).
>
> New CCs need to interoperate with the most prevalent CC on the Internet
> (CUBIC). The IETF cannot even say that as long as it hasn't formally
> recognized CUBIC on the stds track. That is a failing of *us* in the tcpm
> WG. We can move CUBIC to stds track via the exp track if we have to, or we
> can go straight to stds track. The only difference is that the first option
> makes us look like jobsworths for longer.
>
> jobsworth
> /ˈdʒɒbzwəːθ/
> *noun*
>  derogatory•informal
> an official who upholds petty rules even at the expense of humanity or
> common sense.
> 1970s: from "I can't do that, it's more than my job's worth."
>
>
> Bob
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>