Re: [tcpm] Intended status of draft-ietf-tcpm-newcwv - Confirmation of discussion during IETF 89

[[e-mail]]

>
> My high order bit here is that the newcwv document isn't in very good
> shape [per previous comments] and so its a little hard to have these
> conversations in that context if you ask me.  And, so I'd suggest this
> arbitrary two week period is premature.
>
In retrospect, I agree - and since the authors started an internal review,
we have found several places where language is confusing etc. Mea culpa -
we will fix, but this requires some detailed consistency checks by us.

> However, to give a hit on the two questions you asked ...
>
>> In the room there was strong consensus that this document should be
>> heading for Experimental status, given that further experimentation
>> and operational experience with the mechanism is needed (e.g.,
>> regarding pacing).
>
> If it is the pacing that is the reason for experimental instead of
> proposed I'd disagree.  Pacing makes the imposed load on the network
> less aggressive than current mechanisms and so I don't see any reason to
> spin at experimental.  Not that there may not be a refining of our
> understanding of pacing by actually doing it, but that the possibility
> of harm to the network seems pretty small to me.
>
I think so too - In my mind we discussed if Pacing is useful (it is), if
we should recommend some of pacing pacing (I think we should, and the
draft now does). It's always going to be the case that OS implement pacing
in various ways - the big step is to say "turn it on" for these cases, I
don't see turning on as a risk.

> Now if the reason for experimental is that newcwv is more aggressive
> than the current TCP spec recommends then perhaps that is a better
> reason.  However, the flip side is that we have gotten by with no
> downward adjustment based on cwnd use / non-use for a long time and so
> relative to that newcwv is still more conservative and hence seems fine
> for proposed.
>
> (Of course, both these are modulo that I don't really yet understand or
> buy newcwv because the document has yet to convince me we need something
> new and/or that the new algorithm is reasonable.  But, I do have some
> trust in the involved folks and so I figure the document will probably
> get there.)
>
The authors intent resonates with this.

>> In addition, draft-ietf-tcpm-newcwv recommends (for a long time
>> already) to move RFC 2861 from Experimental to Historic. According to
>> the feedback in the room, the TCPM working group seems to agree on
>> that. This message thus intends to confirm that obsoleting RFC 2861 is
>> consensus of the TCPM working group.
>
> I don't see this yet.  Per previous discussion with Gorry the newcwv
> pertains to 'rate limited' periods, whereas RFC 2681 pertains to 'idle'
> or 'application limited' periods.  The new document does not shed any
> light on how these periods relate to one another.  Gorry seems to
> indicate that the new version encompasses the old (and then some).  But,
> I have no good understanding of this relationship myself.  I am sure I
> will better grok it after the next version of the draft.  But, until we
> see a cogent argument written down I don't see how we can decide whether
> to obsolete RFC 2681.
>
> Given the state of the newcwv document these questions are just
> premature.  We'd be better off spending cycles on the actual meat of the
> document.
>
Again, our fault, we'll strive to do better in the next draft.

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

Gorry