[tcpm] On allocating reserved bits in the TCP header

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Tue, 10 September 2019 10:50 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9FE55120043 for <tcpm@ietfa.amsl.com>; Tue, 10 Sep 2019 03:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wmwGz1wNfqou for <tcpm@ietfa.amsl.com>; Tue, 10 Sep 2019 03:50:48 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BED1200F6 for <tcpm@ietf.org>; Tue, 10 Sep 2019 03:50:47 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by mail.hs-esslingen.de (Postfix) with ESMTP id 8FFA425A19 for <tcpm@ietf.org>; Tue, 10 Sep 2019 12:50:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1568112645; bh=17nTmPi9DxM6HWHlZp50WvEgpiGPfxiwpeUh5CoJmAo=; h=From:To:Subject:Date:From; b=gUt/PpRtCbQwIxqfaVMSpwaj9cxDHSa6QLLX5ajEn47mlvh2vQtBspwg4z4hC4bS9 ZvMVk5VxoiMmxKgUltPWCJ6wcJyQosjf5DvV8yvV09L05Yw7QxrF0EL1eeXVXj91mm fwxmaJrYDpSrQoMCMBIufiMlHVwAqkmgvrY/yLj4=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([]) by localhost (hs-esslingen.de []) (amavisd-new, port 10024) with ESMTP id l2XgJ4hwkMj1 for <tcpm@ietf.org>; Tue, 10 Sep 2019 12:50:44 +0200 (CEST)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for <tcpm@ietf.org>; Tue, 10 Sep 2019 12:50:44 +0200 (CEST)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Tue, 10 Sep 2019 12:50:44 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: On allocating reserved bits in the TCP header
Thread-Index: AdVmj1xabgQDGeLVSb628zuZMsyT0A==
Date: Tue, 10 Sep 2019 10:50:43 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/v_jShstnGaVkkVI_NZUh-D7xrMg>
Subject: [tcpm] On allocating reserved bits in the TCP header
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: Tue, 10 Sep 2019 10:50:51 -0000

Hi all,

Disclaimer: I write this note as individual contributor to TCPM. It is possible that I end up in the rough part of the TCPM consensus in this case. That would be unusual, but it is not impossible. If so, this e-mail documents my concerns (again). Reasonable people can reasonably disagree, and that does not prevent the working group from moving forward. I'd also like to announce that I would prefer not to serve as shepherd for a document if consensus has to be declared against me, in order to avoid any bias.

Given that we need to finish draft-ietf-tcpm-accurate-ecn, and given other recent TCPM discussions on reserved TCP header bits, I have thought about the IANA considerations of allocating a reserved header bit. This e-mail is not about the question of _whether_ to allocate a bit. It is about the _how_.

That question was discussed in the past for draft-ietf-tcpm-accurate-ecn already quite a bit, e.g. during IETF 99. During that discussion, I have raised concerns against allocating a bit in the main TCP to an experiment without backing by a standards track RFC. I may have been in the rough part of the consensus in the room when that discussion took place. But I have not changed my mind.

The statement in RFC 2780 is: "The reserved bits in the TCP header are assigned following a Standards Action process."

RFC 8126 explains: "For the Standards Action policy, values are assigned only through Standards Track or Best Current Practice RFCs in the IETF Stream."

And I think that requirement in RFC 2780 is correct. I probably don't have to expand on why IETF rules make sense to me. RFC 2780 and RFC 8126 don't leave much room for interpretation, as far as I understand them.

It is well-known that bit 7 requested by draft-ietf-tcpm-accurate-ecn has previously been allocated to an experimental RFC (RFC 3540). That happened before I have joined IETF mailing lists, and I am not familiar with the corresponding discussions, most notably regarding compliance with RFC 2780. In any case, given that RFC 3540 is now historic and the bit is has status "reserved", the current IANA registration of TCP header flags is apparently compliant to RFC 2780.

In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules.
And actually I believe it would not be hard to do so. For instance, TCPM could publish a short standards track RFC that allocates e.g. bit 7 for experiments. That could solve the allocation needed by draft-ietf-tcpm-accurate-ecn. Similar to RFC 8311, a standards track document could precisely define what experimentation is allowed with that bit. It would be a short document that could be finished on fast track, possibly even in parallel to draft-ietf-tcpm-accurate-ecn, provided that there is consensus on allocating e.g. bit 7 to a well-defined area of experimentation. It has been pointed out in the past that such as standards track document would result in overhead. I believe that the overhead would be small and worth the effort.

In any case, I feel uncomfortable with creating a precedent for IETF process violation regarding any of the reserved bits in the TCP header.

Best regards