Subject: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2013 11:56:25 -0800

Hi, all,

The IESG has reviewed draft-touch-tcpm-experimental-options and is 
holding the document up on two key concerns:

     I. the lack of a registry for magic numbers

     II. potential for prefix collision within the set of magic numbers
	supported in a single implementation

Addressing their concerns would involve a substantive change to the 
draft, so I would appreciate some feedback on the following possible 
solution before updating the document.

Please post your comments on this proposed change.

Here's what we need to know:

1. do you agree with change (A)?

2. do you agree with change (B)?

3. do you agree with change (C)?

	if so, which variant (i), (ii), (iii)?

My preference is:
	A yes
	B yes
	C yes
		first choice (i)
		second choice (iii)
		(I think (ii) is inelegant)

Thanks,

Joe

-----------------------------------------------------------------------

PROPOSED CHANGES:

     A) change the name from MAGIC NUMBER to "experiment ID"

	Rationale: because the new value will be delegated by IANA,
	it no longer qualifies as a self-assigned "magic number"

     B) request that IANA register experiment IDs
	The procedure would be:
		FCFC assignment from among unassigned values
		zero hurdle for assignment (no ID required)
		OK to indicate multiple assignees
			list in the order of request

	Rationale: Needed to satisfy IANA concern (I) above.

     C) Specify a more limited number of sizes to avoid overlap

	Here's a list of the current known uses of the magic
	number as already proposed in this doc:

	draft-ietf-tcpm-fastopen-02	
			0xF989

	draft-fox-tcpm-shared-memory-rdma-01	
			0xE2D4C3D9

	draft-sarolahti-irtf-catcp-00
			0x20120229

	draft-trammell-tcpm-timestamp-interval-00
			0x75ec

	i) Given this, my first inclination - given we'd be using
	an IANA registry - would be to just stick to 16-bits,
	and assign the values for current uses to be consistent.

	ii) a second variant would be 16- and 32-bit values

		a) assign as follows to be compatible with current use:
			16-bit	0x0000 - 0x7FFF
				0xF000 - 0xFFFF

			32-bit	0x8000 0000 - 0xEFFF 0000

			This allows all current known uses unchanged.

		b) assign according a simpler split, and assign a large
		range to one of the members above:

			16-bit	0x0000 - 0x7FFF
			
			32-bit	0x8000 0000 - 0xFFFF FFFF

			All current uses would be unchanged except:

			fastopen	0xF989 0000 - 0xF989 FFFF

			catcp		0x2012

			(note - this would be updated in their spec,
			but need not affect their implementations)

-----------------------------------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2013 13:22:29 -0800

PS - one additional point:

	regardless of the length that might be registered with IANA,
	using a longer experiment ID might still be useful, since
	it helps guard against both squatters and those who don't
	support this mechanism

I'll be sure to include that in the update if we converge on this approach.

Joe

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 15 Feb 2013 17:01:57 -0800

(A) yes
(B) yes
(C) yes, option ii), a) which requires no changes for anyone.

At 11:56 2/15/2013, Joe Touch wrote:
>Hi, all,
>
>The IESG has reviewed draft-touch-tcpm-experimental-options and is holding the document up on two key concerns:
>

---

From: [email-masked]
Date: Sat, 16 Feb 2013 10:27:31 -0000

This sounds good. You could consider citing one of the existing longer
value as a concrete example.

Gorry

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Brian Trammell <[email-masked]>
Date: Sat, 16 Feb 2013 13:10:03 +0100

hi Joe, all,

> 1. do you agree with change (A)?

yes

> 2. do you agree with change (B)?

yes

> 	if so, which variant (i), (ii), (iii)?

yes. The value in our draft, in any case, is arbitrary and can be changed at this point with minimal experimental impact, so preserving existing values (at least from my viewpoint) isn't worth the relative inelegance of (ii).

On straight 16- vs 16-32 bit identifiers, I have noticed that scarcity in 16-bit number space often tends to be perceived quite early through the use of the space, so even if we say "no barrier to entry" now, the ability to expand to 32-bit numbers would make it more likely that assignments in this space remain zero-friction. So I'd say I prefer (iii) to (i).

Cheers,

Brian

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 18 Feb 2013 14:50:10 +0000

Hi Joe,

>		(I think (ii) is inelegant)

With (B) stating that multiple assignments are possible, I think C(ii) and C(iii) don't really need to be in the document. Any experiment that is notified by IANA of an experiment id collision should be free to use whatever means appear feasible to disambiguate further (such as adding 16 more bits as extended experiment id, using different length options etc.)...

Thus I support (A), (B), (C)(i)...

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Trammell
> Sent: Samstag, 16. Februar 2013 13:10
> To: Joe Touch
> Cc: [email-masked]
> Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-
> tcpm-experimental-options
> 
> hi Joe, all,
> 
> yes. The value in our draft, in any case, is arbitrary and can be changed
> at this point with minimal experimental impact, so preserving existing
> values (at least from my viewpoint) isn't worth the relative inelegance of
> (ii).
> 
> On straight 16- vs 16-32 bit identifiers, I have noticed that scarcity in
> 16-bit number space often tends to be perceived quite early through the
> use of the space, so even if we say "no barrier to entry" now, the ability
> to expand to 32-bit numbers would make it more likely that assignments in
> this space remain zero-friction. So I'd say I prefer (iii) to (i).
> 
> Cheers,
> 
> Brian

---

From: Brandon Williams <[email-masked]>
Date: Tue, 19 Feb 2013 09:51:53 -0500

> 1. do you agree with change (A)?

Yes.

> 2. do you agree with change (B)?

Yes, provided that "OK to indicate multiple assignees" means that the 
multiple assignees should all agree.

> 3. do you agree with change (C)?

Yes. i looks better due to size, iii is next.

--Brandon

-- 
Brandon Williams; Principal Software Engineer
Cloud Engineering; Akamai Technologies Inc.

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Feb 2013 09:23:22 -0800

> multiple assignees should all agree.

So what if they don't?

Or, more specifically, what if they:

	- refuse
	- cannot be contacted

Or should we just say that the IANA list is the 'first to file', and 
don't really list anything else?

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Feb 2013 09:42:58 -0800

PS - we could add the following:

	16 bits are assigned, but 32 SHOULD be used

	IANA registration will assign FCFS the first 16 bits,
	and record the second 16 bits if provided.

That still leaves the question of squatters and/or collisions that 
request explicit registration.

Clearly, IANA requests should help the applicant choose an unassigned 
codepoint rather than recording a collision. However, if they either 
refuse or didn't contact IANA (i.e., squatter), what should we ask IANA 
to do?

This case comes up in the ports space. There are a few solutions:

	a) don't record or indicate collisions
		i.e., record only the IANA assignments

	b) record the existence of a collision, but no other info
		this helps users debug problems, but
		avoids implicit endorsement of squatter usage

	c) record the collision and all available info
		helps debugging the best, and allows
		the community to "assign blame", but
		might be taken as an implicit endorsement
		of squatter usage

I'm in favor of (b) above.

Joe

---

From: Brandon Williams <[email-masked]>
Date: Tue, 19 Feb 2013 12:50:31 -0500

> don't really list anything else?

My thinking is that one of the goals of a registry would be to avoid 
collisions, which suggests that 'first to file' language would be good. 
I don't think it's absolutely necessary to disallow multiple assignees, 
but would prefer that to an approach that too readily allows collisions.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Tue, 19 Feb 2013 12:55:14 -0500

This looks good to me. I also like your suggestion (b).

--Brandon