Re: [tcpm] Thoughts on EXP vs. PS in TCPM

On Wed, Nov 20, 2019 at 8:44 AM Mark Allman <mallman@icir.org> wrote:
>
>
> Hi Michael!
>
> Good questions.  Thanks for starting the thread.
>
> I agree that TCPM is basically too conservative.  We have been too
> conservative for a long time.  I probably contributed my fair share
> to that.  But, I'd put a finer point on it: Have we ever issued
> something at EXP (or PS for that matter!) that had to be pulled back
> because it was too aggressive?  I am not conjuring anything at the
> moment.
>
> TCPM has long used EXP as a crutch.  We don't have the guts to label
> something a PS, yet we still want to publish it.  And, no amount of
> non-answers to "what's the experiment?" garners rough consensus for
> issuing as PS.
>
> And, my take is that the world doesn't much buy there to be a
> distinction.  I.e., EXP doesn't dissuade general use of something.
> And, I bet at least part of this is that we're just too conservative
> with both kinds of RFCs.  If we occasionally did publish an EXP that
> caused TCP to fall on its face then maybe people would be a bit more
> careful.
>
> That said, it's sort of hard to come up with good rules for
> delineating.  For instance, consider this ...
>
> > In order to start a WGLC in TCPM for EXP status, there SHOULD be
> > one implementation in the main source code tree of an important
> > TCP/IP stack; a default to "off" is perfectly
> > acceptable.
>
> Well, there are a number of implementations of IW=15 or IW=100, it's
> just that these are off by default.  I.e., something like the
> initial window is just a constant somewhere so what does it mean
> that we have 'one implementation' of something like this?

I like Mark's remarks on # of implementations. This might be too easy
to game: I and my friend each implemented X in our toy stacks. It
really should be WG's consensus if the proposed change has been
well-tested (or else WG is very confident it works).

>
>
> I think in the end TCPM standardizes a wide variety of stuff and a
> one-size rule may not apply.  E.g.,
>
>   - We standardize actual protocol mechanisms (a la TFO) and those
>     need some sort of interoperability kinds of criteria.
>
>   - We standardize algorithms and those need some sort of behavioral
>     and safety criteria (a la RACK).
>
>   - We standardize constants and those need safety criteria (a la
>     IW or RTO).
>
> Further, my observation is that for the latter two in particular the
> WG cares about 'one impl' vs. 'two impls' much less than we care
> about the overall evidence that something works---or, where it falls
> down.
>
> I wish I had some idea about how to synthesize this better than
> 'perhaps we should relax and be less conservative', but I don't.
> I'll think on it.
>
> allman
>
>
> --
> https://www.icir.org/mallman/
> @mallman_icsi
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm