[tcpm] Follow-up questions on allocating reserved TCP header bits

["Scharf, Michael" <[e-mail]>]

Hi all,

As chair, I have stopped the discussion on adoption of draft-kuehlewind-tcpm-flags-registry-00 during IETF 106. I stand by my decision that TCPM does not discuss adoption of any document submitted after the cutoff deadline.

The remainder of this e-mail is written as individual contributor in order to facilitate a list discussion about potential follow-up steps in this space, if they were needed.

It is well-known that a use case for draft-kuehlewind-tcpm-flags-registry-00 could be draft-ietf-tcpm-accurate-ecn. If IETF decides to publish the AccECN spec on Standards Track, the AccECN I-D can directly register TCP header bit 7 according to the existing registry policy defined in RFC 2780. In that case, no change of registration policies is needed to finish draft-ietf-tcpm-accurate-ecn. The target status of draft-ietf-tcpm-accurate-ecn is currently under discussion and there is a mailing list thread for that: https://mailarchive.ietf.org/arch/msg/tcpm/4OB2ZIIvIBX5XXOleGO8YjP64pQ

While the outcome is still to be determined, I assume for the rest of this e-mail that draft-ietf-tcpm-accurate-ecn can register bit 7 without requiring a document like draft-kuehlewind-tcpm-flags-registry-00. Then the remaining question is whether further standardization is needed, e.g., for bits 4, 5, and 6 in the TCP header. If the AccECN specification stays experimental, a solution for bit 7 may be needed, but that allocation does not necessarily have to be identical to the handling of other reserved bits. So even in that case there are a number of open questions.


I believe further list discussion would be useful regarding the following questions, which are not entirely orthogonal, but deal with different aspects:


Question 1: Should an IANA registry be created for bits 4, 5, and 6 with status "Reserved", which are missing on https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml?

  Discussion:

  This has already been proposed before. It could perhaps just be sorted out by 793bis, as long as the registration procedure "Standards Action" is not modified compared to RFC 2780.


Question 2: Should the IANA registry move to a sub-registry on the Transmission Control Protocol (TCP) Parameters page (https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml).

  Discussion:

  This would mostly be a clean-up that could possibly be done by 793bis as well.


Question 3: Should past (and current) use of bits be documented in the IANA registry, and, if so, how?

  Discussion:

  draft-kuehlewind-tcpm-flags-registry-00 proposes "assignments based on experimental RFC should be marked as such in the "Comments" field and potentially even provide hints about the nature of the experiment or provide a pointer to a section in an RFC where the experiment is explained."

  One use case for this would be the past allocation of bit 7 by Historic [RFC3540], which had no known use or implementation. If bit 7 gets reallocated and possibly gets another "name", it is an open question whether and how the past allocation would need to be listed in the IANA registry.

  Another related question may be whether non-SYN use of the two RFC3168-ECN bits in the TCP header different to RFC 3168 should be documented in the IANA registry.


Question 4: If any of the currently reserved TCP header bits will be used in future, should the specification usually be experimental first?

  Discussion:

  This is all about IETF processes.

  draft-kuehlewind-tcpm-flags-registry-00 states: "This draft changes the registration policy of the registration to IETF Review as usually new TCP mechanisms that could use the remaining reserved flags will be first specified as experimental."

  For the sake of completeness, the definition of Experimental can be found in reference [1], which is copied at the end of the e-mail. Further explanation on the use of Experimental RFCs can also be found in [2]. In the context of this question, also the definition of proposed standard in [3] may be relevant, which mentions that the "IESG may require implementation and/or operational experience" for a Proposed Standard.

  This may come down to the question whether the IETF should in future specify use of TCP header bits for experiments that have no implementation or operational experience, or for protocols that cannot be published as PS for other reasons (e.g., the cases mentioned in reference [2]).


Question 5: What standardization policy would be approprate instead of "Standards Action", if a downgrade is needed?

  Discussion:

  RFC 8126 defines different options.

  draft-kuehlewind-tcpm-flags-registry-00 proposes "IETF Review or IESG Approval". Even if there was consensus to replace the policy "Standards Action" in RFC 2780 by something else, one could e.g. question why "IESG approval" would indeed be appropriate for a permanent change of one of the core Internet protocols. RFC 8126 explains that "IESG Approval is not intended to be used often or as a "common case"; indeed, it has seldom been used in practice."


Question 6: How to deal with future allocations not being used?

  Discussion:

  As this is a non-trivial question, here is a copy of the text in draft-kuehlewind-tcpm-flags-registry-00:

   Therefore, any experimental RFC that registers a reserved flags in
   the TCP flags registry MUST provide ways to alter the proposed
   mechanism at the end of the experimental phase without using
   additional TCP header flags.  E.g. it would be possible to add an
   additional negotiation mechanism after the TCP handshake that would
   make it possible to use different versions of the general mechanism/
   extension that was negotiated or indicated during the TCP handshake
   using the newly assigned flag.  Further, any experimental extension
   SHOULD discussion the scope of the experiment and potential failure
   cases or open questions that need to be answered when running the
   experiment and explain how these could be addressed in an updated
   version.

   TCP flags can only be de-assigned if no deployment of an experimental
   extension happened.  This should be evaluated some years after the
   assignment to an experimental extension, in order to change the
   registry entry back to "RESERVED" and move the respective
   experimental RFC to history, or assign it permanently.

  If one goes down that road, one may run into a number of follow-up questions, such as:

  Q6.1: What would be the exact normative statement that experiments would need to comply to?

  Q6.2: How would "additional negotiation mechanisms" work robustly, given that TCP struggles with reliably transporting control information after the SYN?

  Q6.3: Would a new follow-up user of a bit need to implement the previous failed experiment to make use of such a "additional negotiation mechanism"?

  Q6.4: Would there be normative language on how deallocation "should be evaluated some years after the assignment"? If so, what?

  Q6.5: How to deal with partial deployment of an experiment e.g. only in controlled environments, but not in the open Internet? Would the experiment then continue using an experimental bit allocation, or would a follow-up PS be needed after some time, or would the allocation be removed?


Question 7: Could one of the bits 4, 5, or 6 be registered by several experiments in parallel?

  Discussion:

  As after allocation of bit 7 only three reserved bits are left, and there are already a number of proposals for other use cases, in addition to plenty research papers on TCP, and probably many more to come in future, it is not clear whether there would be enough bits in the header for all experimenters and researchers without some additional mechanism of co-existence. For a process document, the question is if an IANA registry would need to foresee more than one experiment.


Question 8: How many bits can reasonably be allocated in the next few years?

 Discussion:

  This is not a technical but more a strategic question. It may be mostly orthogonal to the formal process how to allocate bits, but given that there are only 3 or 4 reserved bits left, they are a very scarce resource. Based on the current level of deployment and use of TCP, TCP will probably still be in use for several decades, even if successor protocols may take over significant parts of the current TCP-based traffic. Given that future needs in, say, 20 years from now are unknown, is there a strategic need to keep back some reserved bits for these future unknown needs? If the answer is yes, it requires discussion whether changing the registration policy for _all_ bits is strategically the right concept now. An alternative could be e.g. to focus changes only on a sub-set of the remaining reserved bits (if there was actually a need for any change).


Question 9: All-in-one policy change now or future case-by-case handling?

  Discussion:

  If bit 7 can be assigned without changing the registration policy, it is unclear whether there is indeed an urgent need for further changes of the registration policy, e.g., for bits 4, 5, and 6. For instance, an alternative would be to sort out future allocation of reserved bits case-by-case once the use case is well understood and the added value of using a TCP header bit is clear, and once it is also understood why the approach of a PS is not applicable for that experiment. For case-by-case handling, no all-in-one policy change would be needed for the time being.


I believe the TCPM community should discuss these questions in order to understand whether some new document is needed, and, if so, what it should contain. Formal procedure documents can be short, but the exact wording matters, and I believe there are quite a number of non-trivial details. And changes to the main TCP header should probably be discussed carefully and be backed by strong consensus.

Thus, feel free to comment.

Michael (with no hat)



References

[1] Definition of an Experimental RFC in RFC 2026

</snip>
4.2.1  Experimental

   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or it may be an individual contribution.
</snip>


[2] IESG guidelines for Experimental RFCs on https://ietf.org/standards/process/informational-vs-experimental/

<snip>
The following set of guidelines will be used by the IESG. The list is read from top to bottom; the first one that seems to apply is probably the one that makes sense to follow.

[...]

4. If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental. This is the typical case of not being able to decide which protocol is "better" before we have experience of dealing with them from a stable specification. Case in point: "PGM Reliable Transport Protocol Specification" (RFC 3208)

5. If the document contains implicit or explicit success/failure criteria, and it's clear that the outcome can be used as the basis for a recommendation to the IETF community, it's Experimental. Case in point: RFC 1797 "Class A Subnet Experiment" which led to RFC 1879 "Class A Subnet Experiment Results and Recommendations"
</snip>


[3] Definition of a Proposed Standard in RFC 7127

<snip>
3.1.  Characterization of IETF Proposed Standard Specifications

   The entry-level maturity for the standards track is "Proposed
   Standard".  A specific action by the IESG is required to move a
   specification onto the standards track at the "Proposed Standard"
   level.

   A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.  Proposed Standards are
   of such quality that implementations can be deployed in the Internet.
   However, as with all technical specifications, Proposed Standards may
   be revised if problems are found or better solutions are identified,
   when experiences with deploying implementations of such technologies
   at scale is gathered.
</snip>