Subject: [apps-discuss] Apps Directorate Review of draft-ietf-tcpm-experimental-options-02

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Nov 2012 19:55:22 +0100

Dear Joe,

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tcpm-experimental-options-02
Title: Shared Use of Experimental TCP Options
Reviewer: Eliot Lear
Review Date: 15 Nov. 2012
IETF Last Call Date: none.
IESG Telechat Date: none.

This document is not yet ready for publication, and requires
consideration of several major issues.  As an apps directorate reviewer,
I can say that since many if not most applications sit atop TCP, the
impact of experimental options can be quite serious.

Major Issues

I would want to know that the working group seriously considered a fixed
length for the magic field. In general, I'm uncomfortable with the
SHOULD for the size of the field, and would be more comfortable with a MUST.

More importantly this draft raises a concern about options that are
meant to be EXPERIMENTAL, but somehow the experiments got out of the
lab.  I'd like to understand how often this has actually been a
problem.  IMHO I don't understand why we would think that implementers
would follow the advice given in this draft if they didn't bother
attempting registering allocation with IANA (Section 1, Page 3).  This
section, needs to more clearly state the problem meant to be addressed.

If this draft is to move ahead, a specific PRN algorithm should be
recommended for selection of the magic number so as to avoid
collisions.  The SAAG folk can help here.

Similarly 3.2 argues against the whole concept.  Let's not try to
address backward compatibility of use of this feature with experiments
in this document, other than to say that this mechanism isn't intended
for use with a uniquely assigned option.

Minor Issues

The ASCII art in Section 3 should give field lengths.

I really don't know what to make of Section 3.1.  The SHOULD there tells
me to do something if my implementation is not robust, but then if I do
it, it is robust, right?  Clearer advise should be given.  Like perhaps
the following: if an implementation receives a response that does not
follow the the experiemental design, it MUST cease sending the option in
question and interpreting any such results, and SHOULD terminate the TCP
connection and try again.  Perhaps hosts participating in the experiment
should cache failures and log them?

Eliot

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Nov 2012 13:09:39 -0800

Hi, Eliot,

> SHOULD for the size of the field, and would be more comfortable with a MUST.

We discussed this in the WG. There is no reason for a fixed field; 
letting the protocol designer decide allows them to trade the potential 
for collision with the space cost, which for TCP options is a critical 
decision.

> lab.

There is no IETF requirement that Experimental RFCs describe protocols 
which are excluded from the public Internet (e.g., see RFC 2026 which 
defines the tracks, as well as the Tao of the IETF). In some cases 
protocols are specified as experimental primarily because some aspects 
are in flux and require operational experience to resolve; in other 
cases the protocol is just not expected to be of widescale interest or 
deployment.

Experiments do use assigned codepoints.

Some confusion may be the result of the statement in RFC 4727 which 
asserts that some codepoints reserved for experiments MUST NOT be 
shipped as defaults. However, there is no prohibition in RFC 4727 or 
elsewhere in the IETF AFAIK that prohibits their deployment or use in 
the public Internet.

The doc should be more clear on this point; I can updated it accordingly.

> I'd like to understand how often this has actually been a
> problem.

As noted above, it's already permitted.

Some systems already deploy experiments as defaults; some use 
experimental codepoints (as summarized in this doc already), and others 
use assigned codepoints or configurations that are set as default (e.g., 
the default Linux and MS TCP flow control is not standards-track AFAIR).

 > IMHO I don't understand why we would think that implementers

I agree this can be more clear.

There are two reasons this doc's approach is useful:

1) there are experimenters who do want to use this approach, and it has 
encouraged them to use the experimental codepoints rather than asking 
for assigned codepoints

2) the magic number approach in this doc protects those who follow its 
approach from those who do not but who 'squat' on the experimental 
codepoints

Overall, we believe this will reduce squatting by encouraging good 
behavior, but it is not intended to track, punish, or otherwise prohibit 
squatters.

> collisions.  The SAAG folk can help here.

Such algorithms are important when numbers are generated within a 
protocol. Magic numbers are generated by the author at the time the 
document is written, and so the method described (using the low-order 
bits of a clock, sampled when the doc is first written) are more than 
sufficient to avoid collision.

> for use with a uniquely assigned option.

I discussed this with the AD given his review, and I think I agree with 
your approach. IMO, "backward compatible" implementations need to 
support both variants (experimental codepoint/magic number and assigned 
codepoint), and the user or system needs to pick one when the option is 
selected.

> The ASCII art in Section 3 should give field lengths.

Will do.

> I really don't know what to make of Section 3.1.  The SHOULD there
> tells me to do something if my implementation is not robust, but then
> if I do it, it is robust, right?  Clearer advise should be given.
> Like perhaps the following: if an implementation receives a response
> that does not follow the the experiemental design, it MUST cease
> sending the option in question and interpreting any such results, and
> SHOULD terminate the TCP connection and try again. Perhaps hosts
> participating in the experiment should cache failures and log them?

Strictly, there's no way to know the difference between two experiments 
colliding and just a bad implementation of the intended option. How such 
errors are handled is up to the option designer.

The section could be clearer on what could happen, e.g.:

- two experiments collide using the same magic number
- two experiments collide with different magic numbers
- an experiment with a magic number collides with an experiment that 
doesn't use the magic number but whose option looks like it matches 
magic numbers
- an experiment with a magic number collides with an experiment that 
doesn't use the magic number and whose option does not match the magic 
number

In reality, the observer sees either:
	- magic number matches
	- magic number doesn't match

TCP specifies that options not implemented are silently ignored. That's 
true not only during a SYN but throughout the entire connection. So 
AFAICT, if the magic number doesn't match the endpoint should treat it 
like an option that isn't implemented.

If the magic number does match and the option can be detected as 
"malformed", that's handled by the option (that could be a bad 
implementation or a collision).

I can add that to the discussion; let me know if it addresses your concerns.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Nov 2012 22:20:09 +0100

Joe,

On 11/15/12 10:09 PM, Joe Touch wrote:
> letting the protocol designer decide allows them to trade the
> potential for collision with the space cost, which for TCP options is
> a critical decision.

Ok, as long as it was discussed.

> The doc should be more clear on this point; I can updated it accordingly.

Ok.

> experimental codepoints (as summarized in this doc already), and
> others use assigned codepoints or configurations that are set as
> default (e.g., the default Linux and MS TCP flow control is not
> standards-track AFAIR).
>
> 1) there are experimenters who do want to use this approach, and it
> has encouraged them to use the experimental codepoints rather than
> asking for assigned codepoints

This is a BIG deal and should be in the draft!!

> approach from those who do not but who 'squat' on the experimental

Ok.  That needs to be clarified as well.  Both good points.
> behavior, but it is not intended to track, punish, or otherwise
> prohibit squatters.
>

Sorry I meant it should be used JUST for the assignment, not
operationally in path, but people do a poor job of this.  Better to tell
them how to do it.  Think ULAs.

> I discussed this with the AD given his review, and I think I agree
> with your approach. IMO, "backward compatible" implementations need to
> support both variants (experimental codepoint/magic number and
> assigned codepoint), and the user or system needs to pick one when the
> option is selected.
>
>> Minor Issues
>>
> Strictly, there's no way to know the difference between two
> experiments colliding and just a bad implementation of the intended
> option. How such errors are handled is up to the option designer.
>
> TCP specifies that options not implemented are silently ignored.
> That's true not only during a SYN but throughout the entire
> connection. So AFAICT, if the magic number doesn't match the endpoint
> should treat it like an option that isn't implemented.
>

In general, the more explicit you can be about normative language the
better, so yes it helps.

Thanks!

Eliot

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Nov 2012 13:25:02 -0800

Hi, all,

I have updated a new version (03) draft based on AD review and Apps 
review as follows. It should show up in the usual places shortly.

Please let me know if this addresses your concerns, or if anyone has any 
other feedback.

Thanks,

Joe

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

AD review:

1) reorganized the sections
	split section 3 into separate first-level sections
	inserted subsections in section 3 to clarify the discussion

2) revised the discussion of migration to assigned options
	the current text is intended to be agnostic to
	a specific solution, but to make recommendations on
	what NOT to do

3) cleaned up the wording in many places, esp. the RFC2119 recommendations

Apps review:

4) added an explanation of the use of experimental codepoints vs. 
Experimental RFCs in the intro

5) cleaned up the discussion of collisions in section 4

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