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

Neal Cardwell <> Thu, 17 February 2022 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 838B73A0A8E for <>; Thu, 17 Feb 2022 08:14:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Status: No, score=-17.598 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gvuV1YSX1m1w for <>; Thu, 17 Feb 2022 08:14:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB22C3A0A8C for <>; Thu, 17 Feb 2022 08:14:04 -0800 (PST)
Received: by with SMTP id bs32so5195825qkb.1 for <>; Thu, 17 Feb 2022 08:14:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dTXU6Xy6qwaHemzXrNKnuE2UYYLxrVDGfD0syj/BEzA=; b=JY5DChdI5pugp2CwC82oNu9UY7/q+VhcQBMq7O3GBjeFOCugpnyUeSmN7CAg6Y/99f b4wjJp9/bFKIrbGYvBOpEoK/57dEj160g1FXYl4SGYa/x1zL8z8buce1ef3O6KSbRZxb rUY8TMfWUkVk8IE3rSL0SCKazoIG6rgBFL2cieI6e5sv8GFd5UEne2VeU2FB5tTetILi B4ecEEI/PV4IwcY4H4tNUO/sWDQ9KzFvAvwDMThKxhLVwGMI4ibonJV9dc/62CFQU4QZ yb6Sdj9HEl2+fHRakXPowrAjLaD5/RZrMb51Ac6Zg7bBrEYz9PA78HJiAPKDPdNBJUPQ dWdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dTXU6Xy6qwaHemzXrNKnuE2UYYLxrVDGfD0syj/BEzA=; b=Vn2K6MplOYpCr8XTNmdYzfRC1ihAaIxf4k92biyVsEO2Lc9IgmdEf4ACbv6OMVekXq EGt1EHgBHSr5K0zXMvqr90uDvMPWUcposl8UggH7v6EhRqD0TTUPtnRCSls1BPrXhYSc 5w8wmFtWEyfcMsZ1iJmE0Sxs6mRcwO3dPG2RG9QxUnedidcGpZ7FvyeM5Sgk0URCBF4o xa8iX95FSixYoLFf6P2VzFXukCVcJolEVlQshtkiv8A0BpJMsmzmlqlzQCnE8HZ3Yy42 ijCYqJAIrvbBNZzufsnSM5a1u849Q6sYYOJL3irxRTVK6MdbiR7OSgkgwoqAEkzKtOAO Y/gg==
X-Gm-Message-State: AOAM5322xlu+Z5rhADZR6eA0dFrIHWdCO28BPriYORm93jK/kauFiyh3 xmJNQHKJnZKAHaM/t+RNDdTJG03HPtaHEhU59qYtMQ==
X-Google-Smtp-Source: ABdhPJzYLcTWpp0PMgwh/JR2RVx8+CopPZx8xe4ipt1iA31g9VwgwDnW/gST1CN4wxcgvM65kXVZa4hTJnCRM2uytNY=
X-Received: by 2002:a37:c06:0:b0:49b:7a31:cd54 with SMTP id 6-20020a370c06000000b0049b7a31cd54mr2054383qkm.358.1645114443335; Thu, 17 Feb 2022 08:14:03 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Neal Cardwell <>
Date: Thu, 17 Feb 2022 11:13:47 -0500
Message-ID: <>
To: Markku Kojo <>
Cc: Yoshifumi Nishida <>, " Extensions" <>, tcpm-chairs <>
Content-Type: multipart/alternative; boundary="000000000000033e8005d8390ebe"
Archived-At: <>
Subject: Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Feb 2022 16:14:11 -0000

On Thu, Feb 17, 2022 at 9:42 AM Markku Kojo <kojo=> wrote:

> Hi Yoshi,
> On Tue, 15 Feb 2022, Yoshifumi Nishida wrote:
> > Hi Markku,
> >
> > Thanks for the comments. I think these are very valid points.
> > However, I would like to check several things as a co-chair and a doc
> shepherd before we
> > discuss the points you've raised.
> >
> > In my understanding (please correct me if I'm wrong), when this draft
> was adopted as an WG
> > item, I think the goal of the doc was some minor updates from RFC8312
> which include more
> > clarifications, minor changes and bug fixes.
> > However, if we try to address your concerns, I think we'll need to
> invent a new version of
> > CUBIC something like CUBIC++ or NewCUBIC in the end.
> > I won't deny the value of such doc, but, this seems not to be what we
> agreed on
> > beforehand.
> > if we proceed in this direction, I think we will need to check the WG
> consensus whether
> > this should be a new goal for the doc.
> >
> > So, I would like to check if this is what you intend for the doc or you
> think we can
> > address your points while aligning with the original goal.
> > Also, if someone has opinions on this, please share.
> I think it is important that we remember the status of RFC 8312 and the
> decades long process that has been followed in tsv area for new
> TCP congestion control algorithms that have been proposed and submitted
> to IETF. In order to ensure that new cc algos are safe and fair, the
> process that has been followed for all current stds track TCP cc algos
> has required that the cc algo is first accepted and published as
> experimental RFC and only once enough supportive experimental evidence
> has been gathered the doc has become a candidate to be forwaded to stds
> track. We have even agreed on a relatively strict evaluation process to
> follow when cc algos are brought to the IETF to be published as
> experimental:
> RFC 8312 was published as "Informational" and if I recall correctly the
> idea was "just to publish what's out there" for the benefit of the
> community. RFC 8312 was never really evaluated, particularly not in the
> way new cc algos are supposed to be as per the agreed process.
> I do not recall what/how exactly was agreed when rfc8312bis was launched
> but I would be very interested to hear the justification why this doc
> does not need to follow the process mentioned above but we would like to
> propose IETF to publish a non-evaluated Informational doc to be published
> "with minor updates", i.e., without actual evaluation, as a stds track
> RFC? If the target really remains as PS then the bar should be even
> higher than what is described for experimental docs in the above process
> document, i.e, what we have followod for experimental to be moved to stds
> track.
> The only justification that I have heard has beed "because CUBIC has long
> and wide deployment experience" and "the Internet has not smelted or that
> "we should have noticed if there were problems". We must, however,
> understand that in order to have noticeable bad impact CUBIC should cause
> some sort of congestion collapse. Congestion collapse, however, is not an
> issue with CUBIC nor with any other CC algo that applies an RTO mechanisms
> together with correctly implemented Karn's algo that retains the
> backed-off RTO until an Ack is received for a new (not rexmitted) data
> packet. The issue is fairness to competing traffic. This cannot be
> observed by deploying and measuring the performance and behaviour of CUBIC
> alone. CUBIC being more aggressive than current stds track TCP CC would
> just gives good performance results that one running CUBIC would be happy
> with. One must evaluate CUBIC's impact on the competing (Reno CC) traffic
> in range of environments which requires carefully designed active
> measurements with thoroughly-analyzed results (as required by the above
> process document, RFC 5033 and RFC 2914). What we seem to be missing is
> this evidence on CUBIC's impact and that is something the IETF must focus
> on, not just that whether CUBIC can achieve better performance than other
> existing CCs. The latter has been shown in many publications and is the
> majos focus in  many scientific papers proposing new algos.
> I appreciate a lot that CUBIC has been implemented/developped and
> deployed for long and I wonder whether those deploying CUBIC have
> unpublished results the wg could review before taking the decicion?
> I suggest everyone to read carefully RFC 2914 Sec 3.2 and particularly
> what it says about more aggressive (than RFC 5681) congestion control
> algorithms:
>   Some of these may fail to implement
>   the TCP congestion avoidance mechanisms correctly because of poor
>   implementation [RFC2525].  Others may deliberately be implemented
>   with congestion avoidance algorithms that are more aggressive in
>   their use of bandwidth than other TCP implementations; this would
>   allow a vendor to claim to have a "faster TCP".  The logical
>   consequence of such implementations would be a spiral of increasingly
>   aggressive TCP implementations, or increasingly aggressive transport
>   protocols, leading back to the point where there is effectively no
>   congestion avoidance and the Internet is chronically congested.
> And:
>   It is convenient to divide flows into three classes: (1) TCP-
>   compatible flows, (2) unresponsive flows, i.e., flows that do not
>   slow down when congestion occurs, and (3) flows that are responsive
>   but are not TCP-compatible.  The last two classes contain more
>   aggressive flows that pose significant threats to Internet
>   performance,
> As I have tried to point out there are several features with CUBIC where
> it is likely to be (or to me it seems it obviously is) more aggressive
> than what is reguired to be TCP-compatible. I'm not aware of evidince
> presented to tcpm (or IETF/IRTF) which shows opposite (and I happy to be
> educated what I have missed).
> You may take my comments to be a part of the expert review phase
> performed by the IRTF/ICCRG for CUBIC. I'm not requesting to modify this
> doc to CUBIC++ (or something) but it seems to be that this would be
> necessary if this doc intends to become published as PS. For experimental,
> I think it would need some addtioinal updates and record the areas
> uncertainty and where more experimentation (clearly) is required.

Hi Markku,

Thanks for your careful argument above. Given your argument, in order to
continue to make constructive progress on rfc8312bis without blocking for
new research and experimentation, I would propose that we change rfc8312bis
so that it remains "Informational" (like RFC8312) rather than the
"Standards Track" status currently listed at:

As far as I can tell, that would allow all of the valuable contributions in
rfc8312bis to carry forward and be published, while still respecting all of
the considerations you enumerated above, which center around concerns with
calling CUBIC "standards track".

How does that sound?