Subject: Re: [tcpm] IANA TCP options registry ...

From: Alexander Zimmermann <[email-masked]>
Date: Thu, 1 Apr 2010 08:36:08 +0000

Hi Lars,

Am 01.04.2010 um 08:26 schrieb Lars Eggert:

> Hi,
> 
> On 2010-4-1, at 8:47, Scheffenegger, Richard wrote:
>> Out of curiousity, does anyone know about the to-be assigned option number(s ?) for RFC 5690 (AckCChttp://tools.ietf.org/html/rfc5690).
>> 
>> Are there two option numbers proposed for that RFC, or will a single option (with the length field being the necessary denominator between AckCC control permitted and AckCC Ratio) suffice?
> 
> Section 10 is pretty clear, in that RFC5690 is for limited experimentation only at this time and hence no separate option numbers will be assigned. Experimenters are supposed to use the normal TCP option numbers set aside for general experimentation (253/254) when playing with this proposal:

this could be funny in Linux. You request ACKcc as TCP sender (option 253)
and get Mr. Simpson's TCP Cookie Transactions back ;-)

> 
>   No IANA action is needed at this time.  If this document was advanced
>   as Experimental or Proposed Standard, then IANA would allocate the
>   option numbers for the two TCP options, the ACK Congestion Control
>   Permitted option, and the ACK Ratio option.  In such a case, the
>   following two lines would be added to the TCP Option Numbers registry
>   (maintained by IANA -- http://www.iana.org):
> 
>        Kind   Length   Meaning                             Reference
>        ----   ------   ---------------------------------   -----------
>        TBD1       2    ACK Congestion Control Permitted    [RFCXXXX]
>        TBD2       3    ACK Ratio                           [RFCXXXX]
> 
>   In the absence of TCP option numbers allocated by IANA, experimenters
>   may use the TCP Option Numbers set aside for Experimentation in RFC
>   4727 [RFC4727].  As stressed in Section 1 of RFC 3692 [RFC3692], the
>   TCP Option Numbers in the experimental range are intended for
>   experimentation and testing and not for wide or general deployments;
>   these option numbers could be in use by other experimentors for other
>   purposes.
> 
> Lars_______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 1 Apr 2010 14:07:48 +0200 (MESZ)

> Hi Alfred et al,
>
> Out of curiousity, does anyone know about the to-be assigned option
> number(s ?) for RFC 5690 (AckCC http://tools.ietf.org/html/rfc5690).
>
> Are there two option numbers proposed for that RFC, or will a single
> option (with the length field being the necessary denominator between
> AckCC control permitted and AckCC Ratio) suffice?
>
> Best regards,
>
>
> Richard Scheffenegger
> Field Escalation Engineer
> NetApp Global Support
> ...

Lars already has pointed to the very clear words in RFC 5690.

I understand that this is ugly for the actual participants in
experiments, but this all is based on Section 9.3 of BCP 37,
RFC 2780, published 10 years ago.  With that RFC, the previous
liberal assignment policy for TCP Option Kind values has been
changed radically to require Standards Action or IESG Approval.

I do not want to argue in favor or against that decision, but I
really want to emphasize that this decision has been half-hearted,
leaving the traces of previous, mostly undocumented experiments
in the registry forever with fixed code points.

Given the current interest in new TCP options, TCPM should reconsider
the above decisions.  Leaving old experiments in the registry and
only admitting two code points for experiments looks discriminating
for new experiments.  Given the really scarce space in the TCP header
for options, subtyping seems to be a poor tradeoff.

As you know, I'm already engaged in transforming my previous
results of collecting more facts and evidence about TCP options
into an I-D that will aim at amending the IANA registry.

Thus the following questions arise:

(1)  Should we take this opportunity to add more experimental
     code points for TCP Option Kinds ?

(2)  Should we allow time-limited code point assignments for
     experiments that only make sense if conducted with many
     participants?
     (IANA has reported that they are ready to support such
     timed transitions in registries.)

(3)  Combined idea: reserve an additional range of, say, 16 code points
     for use in IESG-approved experiments (thus no change to RFC 2780!)
     with a 2-year timeout that can be increased once by the same amount
     of time *iff* the experiment has lead to follow-up work in an IETF
     working group targetting Standards Track.  These code points would
     be recycled in a circular manner.

Thoughts?  Opinions?

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 01 Apr 2010 08:15:31 -0400

> and get Mr. Simpson's TCP Cookie Transactions back ;-)
Haven't seen that (RFC5690) so far, but there's somebody else using 253 and
another somebody using 254 in deployed code!  There are earlier messages on
this list about the culprits.

Last year's Linux code used the experimental numbers and followed the usual
procedures (you have to explicitly turn it on with a sysctl or sockopt),
but the conflicts were quickly obvious.  Don't turn it on outside your lab.

The only reason that I've bothered putting up the internet-draft is to get
official IANA assignments.  I'd sent in the reservation back in November,
but IANA refused to send it to IESG for approval without an internet-draft.
Unfortunately, IESG has been *terribly* slow to act.

Unlike certain commercial interests, I'm trying to avoid conflicts.  But
next time, I'll not bother.  IETF officialdom has become too ossified.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 1 Apr 2010 13:42:05 +0100

I'd opt for option #3 - having time-limited experiment range, and clearly stating these opting in I-D or Informational RFCs would help getting interoperability tests deployed...

Cleaning up the IANA registry every 2 years shouldn't be too much of a burden (actually, if within those 2 years no other options were requested for experiments, keep them active until recycled / standards-track RFC emerges...

Or, if a useful addition surfaces, promote the "expirimental" Option to fixed, and put a previously unallocated one to the expirimental code point pool. Pulling once-implemented codepoints out of commercial stacks is also a pain...

AckCC and DCTCP seem to have some merit together, to get them both a properly defined code point each.

Thanks Alfred! 

Richard Scheffenegger

-----Original Message-----
From: Alfred HÎnes [mailto:[email-masked]] 
Sent: Donnerstag, 01. April 2010 14:08
To: Scheffenegger, Richard
Cc: [email-masked]
Subject: Re: [tcpm] IANA TCP options registry ... policy amendments?

I understand that this is ugly for the actual participants in experiments, but this all is based on Section 9.3 of BCP 37, RFC 2780, published 10 years ago.  With that RFC, the previous liberal assignment policy for TCP Option Kind values has been changed radically to require Standards Action or IESG Approval.

I do not want to argue in favor or against that decision, but I really want to emphasize that this decision has been half-hearted, leaving the traces of previous, mostly undocumented experiments in the registry forever with fixed code points.

Given the current interest in new TCP options, TCPM should reconsider the above decisions.  Leaving old experiments in the registry and only admitting two code points for experiments looks discriminating for new experiments.  Given the really scarce space in the TCP header for options, subtyping seems to be a poor tradeoff.

As you know, I'm already engaged in transforming my previous results of collecting more facts and evidence about TCP options into an I-D that will aim at amending the IANA registry.

Thoughts?  Opinions?

Kind regards,
  Alfred.

--

---

From: <[email-masked]>
Date: Thu, 1 Apr 2010 14:10:39 +0100

> Given the really scarce space in the TCP header

Revive
http://tools.ietf.org/html/draft-eddy-tcp-loo

SACK will perform far better with a larger options space.

L.

http://sat-net.com/L.Wood

---

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Apr 2010 16:35:28 +0300

> and get Mr. Simpson's TCP Cookie Transactions back ;-)

Then Linux needs some #ifdefs for people to decide which experiment they want to participate in.

Or just maybe Linux should stop including experimental option code in shipping releases, as stated by RFC3692, which is pointed to by RFC4727, which assigned the experimental options...

Kars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Apr 2010 16:44:08 +0300

Hi,

> Unfortunately, IESG has been *terribly* slow to act.

your request with IANA for the option allocation has been open for a while, agreed.

The ID that IANA asked for before forwarding the request to the IESG was posted by you on March 1. See http://datatracker.ietf.org/doc/draft-simpson-tcpct/#history

The Independent Stream Editor has sent it to the IESG for the RFC5742 Section 3 review on March 26, i.e., during the IETF meeting in Anaheim.

Today is April 1.

The ID is slated for discussion on the very next IESG telechat on April 8.

I fail to see how we're slow. In fact, this is the most aggressive possible schedule.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Apr 2010 16:49:25 +0300

Hi,

>     code points for TCP Option Kinds ?

no. If we allocate them for shared use, people will just use them and ship code using them, like they did in the past. Nothing is gained.

>     timed transitions in registries.)

Whether the registry contents time out or not is irrelevant. What would need to happen is that people need to stop running the code that uses the allocation when the experiment terminates, which is impossible to guarantee in practice, and so collisions aren't prevented by this. It just creates more IANA overhead.

>     for use in IESG-approved experiments (thus no change to RFC 2780!)

We don't need to assign a range for this - the IESG can *already* assign TCP option numbers for Experimental uses. The tcpct draft was written exactly to ask for such an assignment.

>     be recycled in a circular manner.

See above for why the timeout doesn't work.

Lars

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 1 Apr 2010 16:01:53 +0200 (MESZ)

William Allen Simpson wrote:

>>> Section 10 is pretty clear, in that RFC5690 is for limited
>>> experimentation only at this time and hence no separate option
>>> numbers will be assigned.  Experimenters are supposed to use the
>>  normal TCP option numbers set aside for general experimentation
>>> (253/254) when playing with this proposal:
>>

That's it.
The rules about these 'experimental' code points have been set out
very clearly in RFC 4727, and "deployed code" or even "commercial"
implementations are not compatible with these.

> Unfortunately, IESG has been *terribly* slow to act.

Well, I fear in *this* case neither IANA nor the IESG should be blamed:

The IANA registry at
  <http://www.IANA.ORG/assignments/tcp-parameters/>
clearly points out:

|  Registry Name: TCP Option Kind Numbers
|  Reference: [RFC2780]
|  Registration Procedures: IESG Approval or Standards Action

RFC 5226 (lower half of page 11) explains the "IESG Approval" policy
as exceptional and gives two indications for when it should be applied:
   - urgency (used recently to get early code point assignments for TLS
     after a new class of MitM attacks had been discovered and work to
     counter these had started), and
   - strong WG consensus (for a non- Standards Track proposal).
RFC 5226 also states there:
   "IESG Approval is not intended to circumvent the public review
    processes implied by other policies that could have been employed
    for a particular assignment."

In this case, RFC 2780 has established approval of an I-D as a
Standards Track RFC as the "normal" requirement ("Standards Action").

Obviously both exceptions quoted above are not proper matches for your
case, and so I still do not see the procedural rule on which you have
based your expectation of exceptional treatment.
Or did I miss something?

Sorry: In this case, avoidance of IETF WGs strikes back.

> Unlike certain commercial interests, I'm trying to avoid conflicts.
> But next time, I'll not bother.  IETF officialdom has become too
> ossified.

I do not want to argue on the final point here, but it looks like in
this case the IETF (an the IESG) is simply eating their own doggy-food,
and as shown above, this has nothing to do with ossification of the
institutions tasked with the execution of the procedures set by the
IETF.  If the taste of the doggy-food is perceived as being bad, we
should better try to modify it (i.e. the rule in RFC 2780 -- see my
previous posting on this thread), and not merely complain about it.

It is generally seen that for major protocols where experiments
in closed lab environments do not suffice to gain siginificant
experience before standardization, some rules set by the IETF
for IANA policy are too restrictive.  The wave of RFCs and drafts
seen during the last couple of years that aim at making additions
to IETF protocols easier is a clear indication that in some Areas
of the IETF the value of experiments and running code is gaining
back momentum.  For TCP and TLS, that's not the case, for instance.
It's ours to request and drive change for the rules if they hurt.

Kind regards,
  Alfred.

--

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 01 Apr 2010 11:21:21 -0400

> your request with IANA for the option allocation has been open for a while, agreed.
5 months.

> The ID that IANA asked for before forwarding the request to the IESG was posted by you on March 1. See http://datatracker.ietf.org/doc/draft-simpson-tcpct/#history
That's not how the process is documented.  IANA is supposed to forward each
such request to the IESG.  Then, and only then:

       IESG Approval - New assignments may be approved by the IESG.
             Although there is no requirement that the request be
             documented in an RFC, the IESG has discretion to request
             documents or other supporting materials on a case-by-case
             basis.

Note well: that's a discretion of the IESG, not IANA.

> The Independent Stream Editor has sent it to the IESG for the RFC5742 Section 3 review on March 26, i.e., during the IETF meeting in Anaheim.
The RFC Editor was notified on March 1st, long before Anaheim.

The RFC 2026 process says the RFC Editor has two weeks to consult IESG.
Yet, it took 3 weekly reminders before the ISE notification was even
sent to the IESG!

AFAICT, this is not Neville's fault.  The RFC Editor processing queue isn't
working as externally documented.

> The ID is slated for discussion on the very next IESG telechat on April 8.
Good.  I wasn't notified.

> I fail to see how we're slow. In fact, this is the most aggressive possible schedule.
The IESG was *also* notified on March 1st.  [rt.ietf.org #24497]  As you
well know -- you (Lars) refused to put it on the IESG calendar.  You've
forgotten, I have the email....

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 01 Apr 2010 12:53:21 -0400

> based your expectation of exceptional treatment.
Reminder: by that time, earlier Linux code had already been posted for
over a year, incorrectly using option 255.

As noted in my IANA application:

"This will have widespread testing starting on Monday, November 30th ...
with the December Usenix ;login: issue publication."

"There aren't enough experimental options to go around.  I'm already
using 253, and Cisco is apparently shipping a test with 254."

> Sorry: In this case, avoidance of IETF WGs strikes back.
[eyes rolling]  The last time I sent a draft through an IETF WG
(RFC-4419), it took roughly 6 years to be published.  Long after
there were multiple interoperable implementations.

If they have a deadline, or are planning on getting anything shipped,
nobody in their right mind goes through an IETF WG anymore.  Especially
not this one....

> It's ours to request and drive change for the rules if they hurt.
Been there, done that, have the t-shirt (worn on special occasions)!

   We reject: kings, presidents and voting.
   We believe in: rough consensus and running code.

Sorry, but I've already gone through all that (POISED, POISSON), and we
established pretty clear standards of promptness.

But it's good to know "that in some Areas of the IETF the value of
experiments and running code is gaining back momentum."

Thanks for your feedback!

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 1 Apr 2010 20:47:46 +0200 (MESZ)

Hot news of the day:

Apparently, special procedures for TCP Option Kind assignment are
available, based on re-using previously assigned code points later
returned to IANA; see RFC 5841 for an example.

:-)

Kind regards,
  Alfred.

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 01 Apr 2010 15:07:35 -0400

> no. If we allocate them for shared use, people will just use them and ship code using them, like they did in the past. Nothing is gained.
Both agree and disagree with Lars.

We *do* need a bigger range, but it probably should have been done more
like we did with PPP.  (1 code point, followed by a 3 byte OUI.)

Then, it would be less of a problem for shipping code.  But it's too late
now.  Do that with 255, instead.

> We don't need to assign a range for this - the IESG can *already* assign TCP option numbers for Experimental uses. The tcpct draft was written exactly to ask for such an assignment.
The IESG can already *approve* TCP option numbers (not assign).  The IESG
is a functionary body, not an assignment body.  We deliberately split the
responsibilities long ago.

Note that the IESG does not "architect", it doesn't "design", nor does it
*evaluate* designs.  It is merely a coordinating body.

Actually, the TCPCT draft was written outside the IETF, circa late August
last year.  A big chunk of it was published in December.

The internet-draft was posted, as a last gasp of futility, because IANA
didn't do its job.  IANA records assignments.  It does not evaluate
designs.  In this case, IANA was supposed to forward the formal request
to IESG for approval.  That didn't happen.

So, the work flow (as documented) is supposed to be:
  1) IANA receives request.
  2) promptly forwarded to IESG (1 working day maximum).
  3) IESG takes action at its next meeting (14 calendar days maximum).
  4) If there's not enough information (*not* a problem in this case),
     then ask for more details....

If IANA and IESG merely followed the rules as written, maybe fewer folks
would throw up their hands and run away screaming.

> See above for why the timeout doesn't work.
It's not the timeout that doesn't work, it's the recycling.  But product
cycles are typically about 3 years.  It's not that hard to look at
packets and determine that things are no longer in use.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 8 Apr 2010 17:27:55 +0300

Hi,

> responsibilities long ago.

correct. Sorry for being sloppy with my wording.

> *evaluate* designs.  It is merely a coordinating body.

Please re-read RFC2026. The IESG is not merely a coordinating body.

>  2) promptly forwarded to IESG (1 working day maximum).

I agree that this took longer than necessary. I disagree that one working day is a reasonable deadline.

>     then ask for more details....

Because the IESG isn't merely a coordinating body, an action takes some time. Especially if it involves reviewing an at least moderately complex proposal that doesn't come from an IETF WG and that requires soliciting external opinions from TCP, DNS and security experts. I will also freely admit that I personally prioritize the processing of IETF documents over dealing with independent submissions.

Lars