Re: [tcpm] WGLC for UTO

[Pasi Sarolahti <[e-mail]>]

On Oct 15, 2007, at 14:48, ext Mark Allman wrote:

>> Regarding the Proposed Standard vs. Experimental issue, I think this
>> draft, like the other new TCP extensions, should first go to
>> Experimental as a rule of thumb. I'm concerned about the increasing
>> complexity and size of "the standards track" TCP implementation. It
>> would be a good practice to have a careful evaluation in Experimental
>> RFC phase before adding up things to standards track TCP that is
>> expected to be implemented by most vendors.

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

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

Should I implement UTO and when should I enable it?

>     Or, put another way, how would we know that it was OK for UTO to
>     later move to PS?

If people find UTO useful (I'm sure many will do), they will  
implement UTO even as an Experimental RFC. After a couple of years of  
deployment experience advancing the document to PS should be a  
straight-forward process, if no problems have emerged, right?

One could ask the above question for any other experimental document.  
Having couple of years of kind of a "trial period" for new TCP  
extensions wouldn't do any harm, would it?

>     My own opinion here is that this draft specifies a way to share  
> some
>     information and that is pretty benign.  I can't see where it hurts
>     anything if stacks want to do it.  It is advisory information if
>     stacks want to ignore it.  So, what's the real harm here in  
> putting
>     it on the standards track?  Or, what would be the benefit of going
>     experimental?  My own answer to both questions is "very little".

I agree that UTO seems quite safe and non-controversial extension  
(like many other experimental RFC).

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

I realize that in the end it is up to the implementors to decide  
which standards track RFCs they choose to use, and we have indeed  
seen that some implementations are pretty liberal in selecting the  
TCP features. Nevertheless, it would be useful to have a meaning to  
the standards track status, indicating that a feature is considered  
to be part of the "recommended TCP", to help the people pondering  
among the number of TCP RFCs out there. The roadmap RFC seems to make  
this assumption, too, having the standards track enhancements listed  
as "recommended".

- Pasi

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