IETF Logo Mail Archive

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

"touch@strayalpha.com" <touch@strayalpha.com> Wed, 23 February 2022 15:17 UTC

Return-Path: <touch@strayalpha.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 681253A1093; Wed, 23 Feb 2022 07:17:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.318
X-Spam-Level:
X-Spam-Status: No, score=-6.318 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Ka3Hr6vbJrCu; Wed, 23 Feb 2022 07:17:43 -0800 (PST)
Received: from server217-1.web-hosting.com (server217-1.web-hosting.com [198.54.114.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065503A117F; Wed, 23 Feb 2022 07:17:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0+6mfbPP2Xz/uO84BnmcNwACIgU0J2e6Il1Cl9e8ZNE=; b=cTDOr/bNYdSHo/orAZc0yPepTD LUjmIiTlm5/4/Zb2TYbo3Z89n+Ir4csQzomB4MwBQIZHNwJ+ftxJZLnK569ODwUA54P/4LbTEfD/y dVA/+/8siw123XqMYhr0OAhCGC4Yld3bVyEiSmsbbRwvw4hft572hKry4XVXYe3zNgElHV0bRGid4 ryIUcdCLpgkCDbK0vCpgWb8VW4NK9A5QZj6HQ2w/Z56EtRspvuIKBkbBvCHr0jPOQpxyzJ9xXb5hD hEfZ8dw53vx0dbejGvZEq/sQvMLkLPHZLHXXWxdUIYm7ZxRcRMI3tmbFBwkEIHZsVNY2jG9VNlgVQ R/GSLPWg==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:49159 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1nMtOE-00E3I9-47; Wed, 23 Feb 2022 10:17:19 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_50612ECD-B1AC-4D72-87C1-D7990C238E12"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <e8d7113c-47fa-7f91-54db-f7571840cd85@bobbriscoe.net>
Date: Wed, 23 Feb 2022 07:17:07 -0800
Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>, Markku Kojo <kojo@cs.helsinki.fi>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
Message-Id: <3D137052-588B-4479-93EC-B3F7CA502D1C@strayalpha.com>
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>
To: Bob Briscoe <in@bobbriscoe.net>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/vmYjUMLaLM0-EoHN41_PMZo0Enk>
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 15:17:49 -0000

Hi, Bob (et al.),

> On 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
> 
> ...
> #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. 

RFC 5681 "TCP Congestion Control” (standards-track) says (emphasis mine below):

3 <https://datatracker.ietf.org/doc/html/rfc5681#section-3>.  Congestion Control Algorithms

   This section defines the four congestion control algorithms: slow
   start, congestion avoidance, fast retransmit, and fast recovery,
   developed in [Jac88 <https://datatracker.ietf.org/doc/html/rfc5681#ref-Jac88>] and [Jac90 <https://datatracker.ietf.org/doc/html/rfc5681#ref-Jac90>].  In some situations, it may be
   beneficial for a TCP sender to be more conservative than the
   algorithms allow; however, a TCP MUST NOT be more aggressive than the
   following algorithms allow (that is, MUST NOT send data when the
   value of cwnd computed by the following algorithms would not allow
   the data to be sent).

That looks like a MUST that defines fairness to me.

Joe

v2.23.0 | Report a Bug | By Email