Subject: [tcpm] draft-ietf-tcpm-experimental-options-04 nit

From: Kevin Lahey <[email-masked]>
Date: Thu, 28 Feb 2013 08:55:54 -0800

Reading draft-ietf-tcpm-experimental-options-04, I was curious about the following provisions:

   The ExID mechanism must be coordinated during connection
   establishment, just as with any TCP option.

   >> TCP ExID, if used in any TCP segment of a connection, MUST be
   present in TCP SYN segments of that connection.

   >> TCP experimental option ExIDS, if used in any TCP segment of a
   connection, SHOULD be used in all TCP segments of that connection in
   which any experimental option is present.

Am I being too lawyerly, or would this prevent something like SACK-Permitted where a different option is sent on SYN segments than is sent with every other segment?  I presume that SACK-Permitted was an attempt to avoid stressing the options processing code then deployed, but I've seen more recent suggestions for an "I implement window shift, timestamps, SACK, and perhaps other options" option to save space.

Kevin
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Feb 2013 15:23:21 -0800

Hi, Kevin,

On 2/28/2013 8:55 AM, Kevin Lahey wrote:
> Am I being too lawyerly, or would this prevent something like
> SACK-Permitted where a different option is sent on SYN segments than is
> sent with every other segment? I presume that SACK-Permitted was an
> attempt to avoid stressing the options processing code then deployed,
> but I've seen more recent suggestions for an "I implement window shift,
> timestamps, SACK, and perhaps other options" option to save space.

SACK-permitted vs. SACK is a great example of how to burn codepoint 
space needlessly.

SACK could instead easily have been defined as:

	if 2-bytes, then only in the SYN and means "sack permitted"

	otherwise means "sack"

That could have used a single codepoint.

So, yes, this language does avoid the idea that one TCP option codepoint 
should enable/extend a different one.

Joe