Re: [tcpm] WGLC for UTO

[[ Folks, we could use some opinions from additional people on this 
   question. ]]

> First of all, I want to clarify that I am proposing this as a general
> rule of thumb on how to introduce new features to TCP. It has been
> always a bit fuzzy to me when some new feature should go to
> experimental, and when it can go directly to standards track. This is
> not only about UTO (which I think seems like a fine scheme).

Point taken.

> > (1) What 'careful evaluation' do you think should be done during
> >     Experimental?
> 
> In case of UTO, given
> * possibly limited budget of TCP implementation size (in embedded
> * devices, for example)
> * limited TCP option space
> * possibility of resource exhaustion attacks as discussed in
> * security  considerations

The thing that I don't see is how we'll differently answer these
questions in 2 or 3 years than we do today.  I don't mean to claim there
are not considerations.  There are.  But, are embedded devices that
don't want needless TCP mechanisms going to be gone in a few years?  How
is that consideration going to change with experience?  In a few years
will we be able to discount resource attacks?

It seems to me that you (and others) are advocating experience for the
sake of experience, rather than experience for the sake of figuring
something in particular out.

> One could ask the above question for any other experimental
> document.

Sure---and I think we should.  But, some documents have good answers and
some don't, IMO.

E.g., we made NCR an experimental RFC because it delays TCP's congestion
response and therefore makes TCP more aggressive.  I think the question
"is this OK?" is clear and would have to be answered with experimental
evidence before we decided that it was OK for standards track (i.e.,
generally applicable for wide spread deployment).  In this case "is it
OK?" is a technical question about the mechanism.  I think this is in
direct contrast to UTO---which is about the exchange of information.  We
can say we're going to ask "is it OK?", but in the UTO case that is not
a technical question.  How do we answer that question with an
experiment?  I don't see any reason why we'd delay putting UTO on the
standards track as a **proposed** standard.

> But one could also ask what's the real harm in putting it to
> experimental first? What would be the benefit of going directly to
> standards track, instead? Very little?

Point taken.  The benefit may also be small.

In some sense it depends on the default setting you like best.  You want
to add an extra step to all documents and I want to add that extra step
only when it seems like we really need to add that step (and, it doesn't
seem to me that we need the extra step in this case).

> Remembering a past tsvarea
> presentation at IETF-68 about Window Vista features, where Window
> scaling (PS) and ECN (PS) were disabled by default, and DSACK (Exp),
> F-RTO (Exp) enabled...

(Nit: DSACK is PS and always has been.  And, IMO this is important
because it is quite close to UTO because they both specify how to share
information and not much else.)

allman