Skip to main content

Shepherd writeup
draft-ietf-tcpm-fastopen

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

The intended status is Experimental, as indicated on the title page
header.

It is consensus of the TCPM working group that this document should be
published as experimental RFC, given that it describes a TCP extension
that deviates from the standard TCP semantics in certain corner
cases. Because of the same reason, this extension is not recommended
for being used by default. The document explicitly lists certain areas
of further experimentation in Section 7.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

   This document describes an experimental TCP mechanism TCP Fast Open
   (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
   and consumed by the receiving end during the initial connection
   handshake, thus saving up to one full round trip time (RTT)
   compared to the standard TCP, which requires a three-way handshake
   (3WHS) to complete before data can be exchanged. However TFO
   deviates from the standard TCP semantics since the data in the SYN
   could be replayed to an application in some rare
   circumstances. Applications should not use TFO unless they can
   tolerate this issue detailed in the Applicability section.

Working Group Summary:

  This document was extensively discussed and reviewed by the TCPM
  working group and there is strong support to publish the
  document. While being an experimental document, the TCPM working
  group decided to ask IESG for approving an IANA allocation of a new
  TCP option codepoint.

Document Quality:

  The protocol extension described in this document is implemented and
  deployed in the Linux TCP/IP stack, and it is supported by the Chrome
  Web browser and all Google servers. Experimental results have been
  discussed in the TCPM working group. An early SECDIR review 
  concluded that the document had no substantive issues.

Personnel:

  The Document Shepherd is Michael Scharf
  <michael.scharf@alcatel-lucent.com>. The Responsible Area Director
  is Martin Stiemerling <mls.ietf@gmail.com>.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Document Shepherd read the document and he reviewed all
discussions during WGLC and follow-up discussions after WGLC. The
document is considered ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. This document was extensively reviewed by the TCPM working group.

The protocol extension described in this document is implemented and
deployed in the Linux TCP/IP stack, and it is supported by the Chrome
Web browser and all Google servers.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Given the security implications of this TCP extension, the Document
Shepherd decided to ask for an early SECDIR review. The review was
performed by Shawn M. Emery with the conclusion that "the various
risks associated with this protocol are outlined in the draft and
provides sufficient techniques for mitigating against such
attacks". The review only identified two editorial nits.


(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

There are no such issues.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that the appropriate IPR disclusures have
been filed.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no IPR disclosures.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

This document has been extensively discussed in the TCPM working
group, both on the mailing list and in several face-to-face
meetings. It has been reviewed in detail by several contributors. It
can be assumed that TCPM working group as a whole understands the
mechanism.

There have been several discussions on the implications on TCP
congestion control, in particular if this document is being used in
combination with RFC 6928 ("IW10"), since this document allows a
server to send an initial window of data before completing the
three-way TCP handshake. As an outcome of these discussion, the
document mandates in Section 4.2.2 "the server MUST follow [RFC5681]
(based on [RFC3390]) to set the initial congestion window for sending
more data packets" and lists this topic as an areas for further
experimentation in Section 7.3. These statements are considered
sufficient by the vast majority of the TCPM WG participants.

Two issues have been raised during WGLC:

* Regarding allocation of a dedicated TCP option code point for a
  non-standards-track protocol, one contributor disagreed. However,
  there is clear and strong consensus in the TCPM working group that
  in this specific case it seems worthwile to allocate a TCP option
  number (see below).

* The have been concerns concern regarding the rigorousness of the
  protocol specification, in particular if a further specification of
  the client caching behavior is needed. Yet, the consensus in the WG
  is that these heuristics are implementation details that do not
  affect interoperability.

In summary, there is strong consensus in TCPM to publish the document.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There is no known extreme discontent.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

The document passes IDnits with one editorial error ("There is 1
instance of lines with control characters in the document").


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Such review is not required.


(13) Have all references within this document been identified as
either normative or informative?

Yes


(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

There are no such normative references.


(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

Not applicable


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

The document does not change the status of any RFC.


(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

The TCPM working group decided with strong consensus to ask for IANA
allocation of a TCP option number for this experimental document.

Reasoning: The protocol has always followed the guidelines of RFC 6994
and it currently uses an experimental TCP option number in combination
with a registered experimental identifier (0xF989). This consumes two
bytes of very scarce 40B option space in TCP SYN segments, which could
thus prevent other, future TCP extensions. Right now, there is no
significant shortage of IANA-assigned TCP option codepoints for users
following the IETF process: Out of 256 codepoints, IANA has only 14
codepoints assigned to an non-obsoleted RFC, 6 other registrations
(legacy), 9 obsoleted codepoints, and of the order of 10-15 known
unauthorized uses. Given the benefits and the deployment of this
protocol on the one hand side, and the large number of unallocated and
available TCP option codepoints on the other hand, use of a dedicated
option codepoint is considered to be the right trade-off. The TCPM
working group therefore asks the IESG for approving a TCP option
codepoint allocation for this experimental document.


(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

Not applicable


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable
Back