Subject: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt

From: [email-masked]
Date: Mon, 25 Feb 2013 10:08:26 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.

	Title           : Shared Use of Experimental TCP Options
	Author(s)       : Joe Touch
	Filename        : draft-ietf-tcpm-experimental-options-04.txt
	Pages           : 9
	Date            : 2013-02-25

Abstract:
   This document describes how the experimental TCP option codepoints
   can concurrently support multiple TCP extensions, even within the
   same connection. It uses a new IANA TCP experiment identifier, and
   is also robust to experiments that are not registered and those that
   do not use this sharing mechanism. It is recommended for all new TCP
   options that use these codepoints.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-experimental-options-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Feb 2013 10:22:17 -0800

Hi, all,

This version provides the following updates:

- changes the magic number to an experiment ID

- uses a 16-bit registry with an optional 16-bit additional "magic 
number" to combine aspects of an IANA registry with the potential for 
additional protection by using a larger value

- thus allows 16-bit or 32-bit values, but the first 16 bits are 
expected to be unique

Joe

On 2/25/2013 10:08 AM, [email-masked] wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: John Leslie <[email-masked]>
Date: Mon, 25 Feb 2013 14:29:36 -0500

> - changes the magic number to an experiment ID

   :^)

> additional protection by using a larger value

   This IMHO gives us the best chance of IESG approval.

   (Alas, that's not quite what the draft says -- I know Joe is squeezed
for time.)

> - thus allows 16-bit or 32-bit values, but the first 16 bits are 

   :^)

   Note the IANA Considerations:
] 
] This document calls for IANA to create a new TCP experimental option	
] Experiment Identifier (ExID) registry.	
] That registry should allow 16-bit and 32-bit entries...

   Wording like that _will_ confuse IANA, and will cause Michelle to
ask for more clarity. :^(

   Wording like Joe's post suggests, where IANA is simply asked to
register a 16-bit ExID, is simpler for everyone and IMHO accomplishes
what we want.

   The IESG discussion last time suggested the WG is unable to agree
on a single length. I sincerely hope we can prove that idea wrong.

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Feb 2013 11:37:44 -0800

John,

>     (Alas, that's not quite what the draft says -- I know Joe is squeezed

Please see Section 3.1; I was summarizing that section.

> register a 16-bit ExID, is simpler for everyone and IMHO accomplishes

Absolutely. Instead, I recommend that IANA uses the entire section, 
which includes:

    That registry should allow 16-bit and 32-bit entries, where entries
    are "first-come, first-served" on the first two bytes of the value
    in network-standard byte order (big endian), in which the entry
    should indicate the entire ExID value. Known overlapping uses -
    whether of the first-come portion or the entire value - should also
    be listed and highlighted as collisions.

> on a single length. I sincerely hope we can prove that idea wrong.

I don't intend to provide a tutorial to IANA on why this satisfies their 
"single length" goal with the WG's desire to allow different lengths 
with different costs.

If they can't figure it out from the text, I'll gladly wait for an IESG 
that can. Or consider publishing this as a tech report and running the 
registry myself.

Joe

---

From: John Leslie <[email-masked]>
Date: Mon, 25 Feb 2013 14:59:40 -0500

Joe Touch <[email-masked]> wrote:
> Absolutely.

   :^)

> Instead, I recommend that IANA uses the entire section, 

   Perhaps somebody can explain why simpler isn't better?

>    be listed and highlighted as collisions.

   I really couldn't blame Michelle for being confused by such wording.
Even naming the first 16 bits "ExID" and the remainder "Magic Number"
would greatly reduce the confusion.

   Also, the passive voice about "listed and highligted" leaves open
the question of who does this and how. If IANA simply does first come
first served on 16 bits, and has a short free-form comments field, it
would be clear that it's not IANA's job to find overlapping usage.

> "single length" goal with the WG's desire to allow different lengths 

   (I didn't realize I was asking for a tutorial -- I though I was asking
for simplicity.)

> that can. Or consider publishing this as a tech report and running the 

   Hmm... I thought this was a WG document... If it is, I think views of
other WG members would help.

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Feb 2013 12:05:44 -0800

>     Perhaps somebody can explain why simpler isn't better?

Please see Section 3.1, which already does.

> the question of who does this and how.

It's in the IANA considerations section. IANA does it. How is up to them.

> If IANA simply does first come

Overlapping usage is a collision. If you ask for 0x1234 and it's already 
assigned, FCFS means they say "NO". We want them to say "this is already 
taken, but we'll list yours too". The first one has a "privileged" 
position in the listing, but otherwise collisions are not a reason to 
reject.

IANA has no name for that sort of registry. All current IANA registries 
assume exclusive assignment only.

Joe

---

From: John Leslie <[email-masked]>
Date: Mon, 25 Feb 2013 15:22:31 -0500

> Please see Section 3.1, which already does.

   Help me please. Section 3.1 includes:
] 
] ExIDs are selected at design time, when the protocol designer first
] implements or specifies the experimental option.

   Are we saying it's important to "select" these without any regard to
whether the first 16 bits conflict with a prior use?

] ExIDs are registered with IANA using "first-come, first-served"
] priority based on the first two bytes. Those two bytes are thus
] sufficient to interpret which experimental option is contained in
] the option field.

   I don't see how this can be consistent with the idea of using the
first 16 bits without regard for conflicting usage.

>> If IANA simply does first come first served on 16 bits, and has a
>> short free-form comments field, it would be clear that it's not
>> IANA's job to find overlapping usage.
> 
> taken, but we'll list yours too".

   I really don't think IANA will consider that reasonable.

> The first one has a "privileged" position in the listing, but otherwise
> collisions are not a reason to reject.

   IMHO, asking for such a fundamental change in IANA operation would be
a waste of IESG telechat time.

> assume exclusive assignment only.

   Exactly!

   If that really is what the WG wants, I think we should find another
provider of "registration".

   (Obviously, YMMV; and I really do think opinions from other folks
would be more helpful than continuing this Joe/John dialogue...)

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Feb 2013 12:38:47 -0800

Hi, John,

> whether the first 16 bits conflict with a prior use?

Preferably, but one thing that distinguishes this from conventional IANA 
use is that we're designing-in the expectation that there can be 
collisions, and how to deal with them.

> first 16 bits without regard for conflicting usage.

The first 16 bits demux. The next 16 bits - if fixed, i.e., if the magic 
number part is used - verify.

>     I really don't think IANA will consider that reasonable.

IANA should be implementing what we ask. They already have lists where 
collisions are noted - the port numbers in specific.

> a waste of IESG telechat time.

The IESG started this by not understanding the goal of what the WG asked 
for.

However, this isn't a fundamental change in how IANA runs; it's just not 
noted in the doc that defines FCFS or other IANA processes.

> provider of "registration".

IANA should be capable of doing something more than just what has been 
done before. This variant isn't rocket science, and as I noted they 
already do keep track of additional entries in other lists.

> would be more helpful than continuing this Joe/John dialogue...)

I'll be glad to have others chime in...

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 26 Feb 2013 19:23:42 +0100

Joe,

As individual WG contributor, I wonder why the complexity of a 32bit IANA registry is indeed needed. I clearly prefered variant (C)i in your earlier e-mail to the TCPM list, i. e., a 16 bit registry only. I think that this is simple and just enough.

Maybe I should have stated more explicitly in my original e-mail why a 16bit value without any magic number is enough - I assumed it was clear from the context: Assuming that the IANA registry is indeed used by most experimentors, wasting 2 bytes of scarce option space for a magic number hardly seems reasonable. TCPM considered 32bit when we assumed that there was no central registry, i. e., a higher collision probability of randomly chosen magic numbers. This has changed now given the planned use of an IANA registry.

If the WG consensus was to stick to experiment IDs of either 16bit or 32bit, I think that stronger guidance is needed in the document regarding whether to select 32bit. Right now, the document says:

   The second two bytes serve as a "magic number". A magic number is a
   self-selected codepoint whose primary value is its unlikely
   collision with values selected by others. Magic numbers are used in
   other protocols, e.g., BOOTP [RFC951] and DHCP [RFC2131]. The magic
   number helps reduce the probability of a false positive collision
   with those who either do not register their experiment or who do not
   implement this mechanism. Using the additional magic number bytes
   also helps the option contents have the same byte alignment in the
   TCP header as they would have if (or when) a conventional (non-
   experiment) TCP option codepoint is assigned.

I think that the document should more clearly explain the downsides of using 32bit ID including a magic number, i. e., the consumption of TCP option space possibly preventing other TCP extensions.

As a side note, I don't understand why byte alignment helps that much - this only applies to a 32-bit CPU architecture, right?

Finally, I think that our objective is to encourage TCP experimentors to really use the IANA registry, in order to avoid collisions as much as possible. When I personally did my first TCP experiments as student, I had no understanding of IANA processes etc. While the current IANA consideration section in draft-ietf-tcpm-experimental-options-04 may include the mandatory formal information for experts, as a student I would not have understood what this means to my TCP experiment. The current text is written for experts only, imho.

I also wonder whether the IANA section could comment on the possibility to deregister an experiment ID if the experimentor is confident that the codepoint will not be used any more in the Internet. At least if an experimentor has all endpoints under his control, this seems doable.

Thanks

Michael (again, all this e-mail is my individual opinion)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joe Touch
> Sent: Monday, February 25, 2013 7:22 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tcpm] I-D Action: 
> draft-ietf-tcpm-experimental-options-04.txt
> 
> Hi, all,
> 
> - uses a 16-bit registry with an optional 16-bit additional 
> "magic number" to combine aspects of an IANA registry with 
> the potential for additional protection by using a larger value
> 
> - thus allows 16-bit or 32-bit values, but the first 16 bits 
> are expected to be unique
> 
> Joe
> 
> >   This draft is a work item of the TCP Maintenance and 
> Minor Extensions Working Group of the IETF.
> >

---

From: Joe Touch <[email-masked]>
Date: Tue, 26 Feb 2013 10:47:00 -0800

On 2/26/2013 10:23 AM, Scharf, Michael (Michael) wrote:
> Joe,
>
> As individual WG contributor, I wonder why the complexity of a 32bit
> IANA registry is indeed needed. I clearly prefered variant (C)i in your
> earlier e-mail to the TCPM list, i. e., a 16 bit registry only. I think
> that this is simple and just enough.

The document includes a registry based on the first 16-bits, but allows 
registrants to include the following 16 bits as well. The second 16-bits 
are included in the registry, but the registry should only ever have a 
max of 2**16 entries.

> Maybe I should have stated more explicitly in my original e-mail why
> a 16bit value without any magic number is enough - I assumed it was
> clear from the context: Assuming that the IANA registry is indeed
> used by most experimentors, wasting 2 bytes of scarce option space
> for a magic number hardly seems reasonable. TCPM considered 32bit
> when we assumed that there was no central registry, i. e., a higher
> collision probability of randomly chosen magic numbers. This has
> changed now given the planned use of an IANA registry.

There are two reasons for designers using 32-bit values, even given an 
effectively 16-bit registry:

1) better protection against systems that don't use this extension

There are already numerous deployments that use the TCP experimental 
options; a longer field reduces the probability of collisions.

2) results in identical alignment between the experimental option and a 
standards-track variant, if that transition occurs

Yes, it consumes 2 extra bytes if used. However, it's optional. I don't 
see a good reason not to record those values as 32-bits in an IANA registry.

> If the WG consensus was to stick to experiment IDs of either 16bit
> or 32bit, I think that stronger guidance is needed in the document
> regarding whether to select 32bit. Right now, the document says:
>
> I think that the document should more clearly explain the downsides
> of using 32bit ID including a magic number, i. e., the consumption of
> TCP option space possibly preventing other TCP extensions.

Sure; that's the only downside; I do already mention the upside. I can 
add that.

> As a side note, I don't understand why byte alignment helps that
> much -  this only applies to a 32-bit CPU architecture, right?

It certainly applies to 32-bit architectures (CPU, memory, etc.) and not 
16-bit. I'd have to think about the relative impact to 64-bit.

However, TCP data needs to begin on a 32-bit boundary. Using an 
experimental option with the same length modulo 4 (i.e., same relative 
byte offset length) means that the implementer would expect to interact 
with other options and/or padding in exactly the same way if the option 
transitions to standards-track.

So this is more about "fewer surprises" when transitioning. It does eat 
2 more bytes, but IMO no TCP option should be wedged in so tightly that 
2 bytes matter.

> Finally, I think that our objective is to encourage TCP
> experimentors to really use the IANA registry, in order to avoid
> collisions as much as possible. When I personally did my first TCP
> experiments as student, I had no understanding of IANA processes etc.
> While the current IANA consideration section in
> draft-ietf-tcpm-experimental-options-04 may include the mandatory
> formal information for experts, as a student I would not have
> understood what this means to my TCP experiment. The current text is
> written for experts only, imho.

Yeah, I found that out when I got the comments from the IESG ;-)

I need to take the advice of Sarris to Captain Taggert in Galaxy quest 
and revise that section.

> I also wonder whether the IANA section could comment on the
> possibility to deregister an experiment ID if the experimentor is
> confident that the codepoint will not be used any more in the Internet.
> At least if an experimentor has all endpoints under his control, this
> seems doable.

Yeah.

I've also seen that it might be useful to convert some SHOULDs to MUSTs, 
even though we know they won't be followed.

I'll gather these edits and revise.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 26 Feb 2013 20:38:48 +0100

> > Maybe I should have stated more explicitly in my original 
> e-mail why a 
> > 16bit value without any magic number is enough - I assumed it was 
> > clear from the context: Assuming that the IANA registry is 
> indeed used 
> > by most experimentors, wasting 2 bytes of scarce option space for a 
> > magic number hardly seems reasonable. TCPM considered 32bit when we 
> > assumed that there was no central registry, i. e., a higher 
> collision 
> > probability of randomly chosen magic numbers. This has changed now 
> > given the planned use of an IANA registry.
> 
> There are two reasons for designers using 32-bit values, even 
> given an effectively 16-bit registry:
> 
> There are already numerous deployments that use the TCP 
> experimental options; a longer field reduces the probability 
> of collisions.
> 
> 2) results in identical alignment between the experimental 
> option and a standards-track variant, if that transition occurs
> 
> Yes, it consumes 2 extra bytes if used. However, it's 
> optional. I don't see a good reason not to record those 
> values as 32-bits in an IANA registry.

Apart from the fact that the IANA registry gets more complicated to understand. If there is strong desire in TCPM for 32bit registry (I won't argue in favor of that), I think we should use one of the suggested ways to split the codepoint space, to make clear what a codepoint is about. (But, as noted in your original e-mail, they are not really elegant.)

> > As a side note, I don't understand why byte alignment helps 
> that much 
> > -  this only applies to a 32-bit CPU architecture, right?
> 
> It certainly applies to 32-bit architectures (CPU, memory, 
> etc.) and not 16-bit. I'd have to think about the relative 
> impact to 64-bit.
> 
> However, TCP data needs to begin on a 32-bit boundary. Using 
> an experimental option with the same length modulo 4 (i.e., 
> same relative byte offset length) means that the implementer 
> would expect to interact with other options and/or padding in 
> exactly the same way if the option transitions to standards-track.

Some TCP stacks indeed optimize 32-bit boundaries for production deployments.

But all research experiments with TCP options I did myself, 32-bit alignment was the least thing I cared about. I just parsed the given "struct" defining the option header. But, sure, other experiments may have other needs.
 
Michael

---

From: Joe Touch <[email-masked]>
Date: Tue, 26 Feb 2013 11:46:24 -0800

On 2/26/2013 11:38 AM, Scharf, Michael (Michael) wrote:
> Apart from the fact that the IANA registry gets more complicated to
> understand. If there is strong desire in TCPM for 32bit registry (I
> won't argue in favor of that), I think we should use one of the
> suggested ways to split the codepoint space, to make clear what a
> codepoint is about. (But, as noted in your original e-mail, they are not
> really elegant.)

IMO, 16-bits is sufficient as a registration - it's still enough for ports.

AFAICT 32-bits is needed only to increase protection, or if the entire 
space is "magic".

> But all research experiments with TCP options I did myself, 32-bit
> alignment was the least thing I cared about. I just parsed the given
> "struct" defining the option header. But, sure, other experiments may
> have other needs.

Sure - and you can use 16 bits. There are two reasons for the additional 
two, and neither one is always necessary.

Joe