[tcpm] WGLC review of draft-ietf-tcpm-rfc793bis-18

[Praveen Balasubramanian <[e-mail]>]

Following is a WGLC review of draft-ietf-tcpm-rfc793bis-18 by Matt, Yi, and myself.





Section 3.1

The control bits in the header include the RFC 3168 specified CWR and ECE. It might be worth citing 3168 as well in the Abstract.



It is quite a bit surprising that we don't include discussion of the SACK, Timestamp, and Window Scaling options. Even if we don't describe the details, the document should provide references to these almost universally deployed options and recommend that hosts SHOULD implement them. At least the Timestamp option is referred to multiple times in the text without any specification of the format.



Section 3.6.4

"

   If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the

   sending TCP endpoint buffers all user data (regardless of the PSH

   bit), until the outstanding data has been acknowledged or until the

   TCP endpoint can send a full-sized segment (Eff.snd.MSS bytes).

"

This is slightly different from Nagle's description in RFC 896:

"

The solution is to inhibit the sending of new TCP  segments  when

new  outgoing  data  arrives  from  the  user  if  any previously

transmitted data on the connection remains unacknowledged.

"

I.e., the original algorithm description in RFC 896 didn't include the "or if a full-sized packet can be sent" part. This difference isn't mentioned in 793bis, it ought to be, along with a justification for the difference. Also there is no mention of the interaction problem between Nagle's algorithm and delayed ACKs, either here or in the later section on delayed ACKs.





Section 3.7.3



"However, the values of R1 and R2 may be different for SYN

            and data segments.  In particular, R2 for a SYN segment MUST

            be set large enough to provide retransmission of the segment

            for at least 3 minutes.  The application can close the

            connection (i.e., give up on the open attempt) sooner, of

            course.

"

The MUST here is onerous for what is an ancient timeout value which modern implementations don't adhere to. Recommend changing this to a SHOULD.



Section 3.7.4
"Keep-alive packets MUST only be sent when no data or acknowledgement
   packets have been received for the connection within an interval
   (MUST-26).

"

It's important to call out an additional condition - that sends are not already outstanding. When a send is outstanding, it is retransmitted and serves as an implicit liveness check.



Section 3.7.2


"A TCP endpoint MUST implement RFC 5681 (MUST-19)."
This requirement is onerous because RFC 5681 also specifies the NewReno congestion control algorithms. Modern implementations use other algorithms. We should add clarifying text permitting experimentation and evolution of congestion control algorithms. It is also not required for interop.









Editorial comments:



"

     The window size MUST be treated as an unsigned number, or else

     large window sizes will appear like negative windows and TCP will

     now work (MUST-1).

"

should be "not work".



"

Note that when the receive window is zero no segments should be

   acceptable except ACK segments.  Thus, it is be possible for a TCP

   implementation to maintain a zero receive window while transmitting

   data and receiving ACKs.

"

Remove the "be".


"

The "Quiet Time" concept discussed below addresses this and the

   discussion of it is included for situations where it might be

   relevant, although it is not felt to be necessary in most current

   implementations.  The problem have been more relevant earlier in the

   history of TCP.

"
The problem was more relevant

"

It is

   tempting for a TCP implementation to want to advertise the largest

   possible MSS
"
Remove "want to".

"The TCP implementation will signal a
   user, even if no RECEIVEs are outstanding, that the remote peer has
   closed, so the user can terminate his side gracefully.
"
"The user may CLOSE the connection at any time on his own
         initiative
"
Suggestion to be gender neutral in the text.

"

For IPv4, RFC 1122 provides an IP-layer recommendation

   on the default effective MTU for sending to be less than or equal to

   576 for destinations not directly connected.
"
Should at least be "recommendation for", but consider changing to something more concise like "For IPv4, RFC 1122 recommends an IP-layer default effective MTU less than or equal to 576 for destinations not directly connected."