TCP Extensions for High Performance
RFC 7323

Note: This ballot was opened for revision 20 and is now closed.

(Spencer Dawkins) Yes

Comment (2014-03-26 for -20)
No email
send info
This was a very helpful key document for the TCP protocol. Thanks for producing it.

I had some questions while reading the document. Please consider them along with any other comments you receive.

In this text:

1.  Introduction

   For brevity, the full discussions of the merits and history behind
   the TCP options defined within this document have been omitted.
   [RFC1323] should be consulted for reference.  It is recommended that
   a modern TCP stack implements and make use of the extensions
   described in this document.

I don't know what "a modern TCP stack" will mean in a decade or so (RFC 1323 was published more than two decades ago, so ...). 

Is there another way to say what you want to say?

In this text:

1.3.  Using TCP options

   Research has shown that the use of the Timestamps option to take
   additional RTT samples within each RTT has little effect on the
   ultimate retransmission timeout value [Allman99].  However, there are
   other uses of the Timestamps option, such as the Eifel mechanism
   [RFC3522], [RFC4015], and PAWS (see Section 5) which improve overall
   TCP security and performance.  The extra header bandwidth used by
   this option should be evaluated for the gains in performance and
   security in an actual deployment.

Does the evaluation suggested in the last sentence happen in practice? I'm also looking a bit further down at this text: 

   A TCP vendor concerned about optimal performance
   over low-speed paths might consider turning these extensions off for
   low- speed paths, or allow a user or installation manager to disable

I guess there are TCP vendors who care _only_ about optimal performance over low-speed paths, but does that happen in practice? Maybe no reason to change anything, but ... mumble. 

In this text:

3.2.  Timestamps option

   TCP is a symmetric protocol, allowing data to be sent at any time in
   either direction, and therefore timestamp echoing may occur in either
   direction.  For simplicity and symmetry, we specify that timestamps
   always be sent and echoed in both directions.  For efficiency, we
   combine the timestamp and timestamp reply fields into a single TCP
   Timestamps option.

I'm pretty sure I know what you mean, but I struggled a bit between "may occur" and "always be sent and echoed". Is it correct to say "we specify that when timestamps are used, they can be sent and echoed in both directions using a single TCP Timestamps option that combines both timestamp and reply fields for efficiency"?

In this text: 

5.5.  Outdated Timestamps

   However, the TCP specification has never included keep-alives, so the
   solution based upon invalidation was chosen.)

I'm reading, and I'm confused. Is the point that the TCP specification has never mandated the use of keep-alives? Or that RFC 1122 doesn't count as part of "the TCP specification" (but it's in Could you help me understand what's going on here?

In this text:

7.  Security Considerations

   The TCP sequence space is a fixed size, and as the window becomes
   larger it becomes easier for an attacker to generate forged packets
   that can fall within the TCP window, and be accepted as valid
   segments.  While use of timestamps and PAWS can help to mitigate
   this, when using PAWS, if an attacker is able to forge a packet that
   is acceptable to the TCP connection, a timestamp that is in the
   future would cause valid segments to be dropped due to PAWS checks.
   Hence, implementers should take care to not open the TCP window
   drastically beyond the requirements of the connection.

Is "the requirements of the connection" clear to implementers? If I'm using TCP for bulk transfers and always have additional segments to send, is it obvious what implementers should be looking at?

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Comment (2014-03-24 for -20)
No email
send info
1) In Sec 5.6, it says " However, this probabilistic argument is not universally accepted, and
   the consensus at present is that the performance gain does not
   justify the hazard in the general case.  It is therefore recommended
   that H2 follow H1."

IMHO, a problem with the probabilistic argument is that it ignores the possibility of an attacker deliberately 
sending the problem packet.  Has that been considered or is it just not a concern?

(Richard Barnes) No Objection

(Benoît Claise) No Objection

Comment (2014-03-25 for -20)
No email
send info
Below is Fred Baker's OPS DIR review. It's so nicely done that I wanted to copy it here.
Mainly FYI, except maybe one final check related to some pre-2008 text, as Fred mentions the document is ready.

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

As background, I'll note that RFC 1323, which draft-ietf-tcpm-1323bis replaces, has quite of bit of history in the Internet; when I look at traces, the question isn't whether window scaling and timestamps are used, but the scaling factor in use. The authors are recognized experts in TCP, having among them early contributors to the specification and a more recent worker with significant accomplishments. The bibliography of the document cites significant research behind the recommendations, and an rfcdiff shows changes, minor or major, throughout the document. As near as I can tell, the specification documents current practice in deployed TCP implementations and/or makes language more accessible (such as changing the variable in which the window scale value is stored from "scale" to "shift"; the operation is to shift the advertised window left the stated number of bits).

idnits notes the possibility of pre-2008 text and recommends ensuring that the authors of any such text sign off on its publication. The first version of the draft is indeed dated January 2008, and it replaces draft-borman-1323bis, which is a 2007 document. David is a principle author on this document, so I think the concern is likely unwarranted, but it would be worthwhile for the authors to ask themselves that question and deal with it as it deserves.

Important information is included in the document regarding the recommendations of RFC 1323 and other documents, and how they have worked out in practice over time. For example, it was originally thought that including a timestamp in all or many TCP segments would improve estimates of the retransmission timeout. It turns out that, while they help, they don't help as much as expected. Hence, a timestamp once or twice per RTT probably produces the same benefit as a timestamp option on every packet. These observations contribute enormously, in my opinion, to the value of the document.

Security Considerations and Privacy Considerations are included; RFC 1323 didn't consider security. The sections appear well thought through and reach essentially the same conclusions that I would were I writing them. They include not only end to end considerations, but considerations related to middle boxes, which are an operational aspect of the Internet that the IETF likes to overlook.

Regarding the questions from RFC 5706:

The document is grounded in significant operational experience with well-understood and widely-used code. It has not had scaling issues in deployment; it is in fact a response to scaling issues. It does not change the options or their interpretation, so co-existence should not be an issue.

Configuration is not discussed in the document per se. In implementations I am aware of, configuration varies. In some, there is simply a standard value used for all peers; in others, different settings are used on a per-address or per-prefix basis derived either from history or manual settings. There is really only three values that *can* be set: whether or not scaling is in use, a recommended shift value (which may or may not differ based on the peer), and whether or not timestamps are in use. I believe that this is adequate for known purposes.

With respect to the other questions in the list, in my opinion the answer is "it is satisfactory".

I consider the document to be "Ready" for IESG consideration.

(Alissa Cooper) (was Discuss) No Objection

Comment (2014-03-26 for -20)
No email
send info
Might make sense to include a reference to RFC 6191 per our discussion of the random offset.

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2014-03-26 for -20)
No email
send info
believe the doc is ready per the opsdir review.

(Barry Leiba) No Objection

(Ted Lemon) No Objection

Comment (2014-03-25 for -20)
No email
send info
In 2.3:
   o  The Window Scale option MUST be sent with shift.cnt = R, where R
      is the value that the TCP would like to use for its receive

Don't you mean "use for scaling its receive window?"   It's unlikely the reader will get this wrong, but the text doesn't really seem to say what is clearly intended.

It might make sense to divide section 7.1 into more sections.   For instance, why isn't the bit on middleboxes a subsection of section 7?

Also, I didn't see mention of a middlebox failure mode I've heard reported: some middleboxes set the window scale to zero in the SYN but leave the option in the header, so that the other end sees it as a willingness to negotiate, but records the wrong value for the sender window size as a consequence.   I don't know if this is worth mentioning, but I was a bit surprised not to see it there.   Perhaps this is so damaging that middleboxes that do this have all been fixed?

All in all this is a very clear and informative document.   Thanks for doing it!

(Kathleen Moriarty) No Objection

Comment (2014-03-21 for -20)
No email
send info
Thanks for addressing the SecDir comments.

I just found a nit to be addressed:

Nit: Section 4.1 - The RTT acronym should be spelled out in the previous sentence instead of the one it is currently.  Here are the two sentences:

   Values of this clock MUST be at least approximately
   proportional to real time, in order to measure actual RTT.

   TCP measures the round trip time (RTT), primarily for the purpose of
   arriving at a reasonable value for the Retransmission Timeout (RTO)
   timer interval.

(Pete Resnick) No Objection