Subject: [tcpm] an idea for experimental TCP options

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 1 Sep 2011 12:59:00 -0700

Hi, I'm not sure if this is a valid idea yet, but I'm thinking about a
simple (and may be silly?) proposal for
tcp options for experimental use. I'm sorry if we've already discussed
this kind of things before.

1: Allocate one new option kind for new experimental use.

2: When a proposal that requires new option kinds is approved, IANA
can allocate "candidate" option kind numbers.

3: If an implementation wants to use the "candidate" option kind, it
has to be *encapsulated* into the new experimental option.
    If implementers don't like encapsulated format, they can always
use the conventional experimental values as suggested in rfc4727.

4: Once we reach consensus to deploy the proposal, change the
candidate status to assigned status.
    Implementations are now free to use this number in the option kind field.

Pros
   It can be safely used without contaminating.
   It can explicitly specify this is an experimental use.
   Ugliness of this approach makes people motivate to move from
experimental status to standard more seriously?

Cons
   It won't be a true experiments since the option format will be changed?
   Changing option format is troublesome thing?
   It will add another complexity for option processing?

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 07 Sep 2011 23:56:43 -0400

>     It will add another complexity for option processing?

Hi Yoshifumi, this is an interesting variation on Joe's idea.
The difference seems to be that instead of using a timestamp
or a random value to identify the sub-kind for the options
involved in an experiment, IANA would pre-register a Kind number
to be used encapsulated within an experimental option Kind.

I think the drawback is that the Kind field is too small to
make error-free use of in this way.  It's only a single byte
and there's no way to tell in a given option with one of the
experimental outer Kinds whether to process its body as
encapsulated with an inner Kind or in some other way.  With Joe's
method, at least there could be more bits (like 32) to provide a
higher-probability that an option will be processed as intended.

-- 
Wes Eddy
MTI Systems

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 8 Sep 2011 13:01:07 -0700

Hello Wes,
Thanks for your response.

> higher-probability that an option will be processed as intended.

I guess I don't not fully understand joe's proposal yet and I might
miss some points,
but here's my opinion on this.

1: I think 32bit length is coming from self-assigning nature.
   If IANA can control the sub-kind number, I think 1 byte might be sufficient.
   There are also similar kind of risks in using normal TCP options. I
don't see strong
   reason to set higher security on this yet.

2: We might want to distinguish the proposals for experimental RFCs from some
    random TCP experiments. The pre-registered number might be used as
an indication
    of the green-light for large-scale experiments.

    It's probably impossible to control small-scale random TCP
experiments. So, I think
    we should focus on the proposals which need more experiments to be
standards.

Thanks,
--
Yoshifumi Nishida
[email-masked]