Re: [tcpm] WGLC for UTO

[Pasi Sarolahti <[e-mail]>]

On Oct 15, 2007, at 19:13, ext Mark Allman wrote:

> 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.

Ok, I think you are right that it is hard to come up with well- 
defined experiments that would give some additional technical  
information about the UTO. But I don't understand where this  
requirement for experiments comes from. I also ask, because this  
"what is the experiment?" question has come up quite a few times  
during the past couple of years for Experimental documents in  
different WGs, and RFC 2026 does not say anything about experiments:

    The "Experimental" designation typically denotes a specification  
that
    is part of some research or development effort.  Such a  
specification
    is published for the general information of the Internet technical
    community and as an archival record of the work, subject only to
    editorial considerations and to verification that there has been
    adequate coordination with the standards process (see below)....

(I believe many of the proposed TCP extensions are part of a research  
project.)

> 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).

I didn't mean adding extra step to *all* documents, just that we  
should by default be conservative when extending standards track TCP  
with new features. The idea was that during the Experimental state we  
could, among other things, get better understanding whether there is  
"enough community interest to be considered valuable", as required  
for Proposed Standard. This is sometimes hard to judge based on the  
(lack of) comments during WGLCs. In addition to the comments on the  
mailing list, a good indication of "community interest" would be, if  
someone indicated interest in taking a documented extension into a  
real implementation.

>> 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.)

Sorry, by "DSACK" I meant Experimental RFC 3708, i.e. the usage part.  
The UTO document is different that RFC 2883 because it specifies both  
the new option, and recommended response on receiving the option.

- Pasi

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm