TCP Extensions for High Performance
draft-ietf-tcpm-1323bis-21

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?

Might make sense to include a reference to RFC 6191 per our discussion of the random offset.

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.

believe the doc is ready per the opsdir review.

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.

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
      window.

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!