Subject: Re: [tcpm] Call for comments on draft-ietf-tcpm-rfc2581bis

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Date: Tue, 24 Feb 2009 14:20:08 -0600

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Ethan Blanton
>Sent: Thursday, February 19, 2009 11:04 AM
>
>The consensus of the authors is that this miscalculation of ssthresh
>is non-critical, and that no change is required beyond a note that
>this problem exists.  The slow start mechanism exists to protect us
>from errors in the estimate of ssthresh, and any such calculation will
>be closer to the "correct" value of ssthresh than the "arbitrarily
>large" value used at connection initiation.  Furthermore, we are
>reluctant to change this, a known bug which has existed for years,
>without substantial evidence that the fix is correct and an
>improvement; past experience has proven that seemingly minor changes
>can have unforeseen effects.  It is also our sense that the WG is
>hesitant to make unnecessary changes to this document.

My personal view is in agreement with the authors.

My TCPM co-chair view is that the document is blocking other things
in the RFC editor queue with MISSREF, and since this is the last
remaining WGLC comment that needs to be addressed on 2581bis, I
think the WG should try to respond promptly on it.  Since the authors
and Markku have discussed this offlist for a while, and seem to agree
that the effect is fairly minor, waiting only a couple of weeks for
comments to come in seems appropriate, and then issuing the update
and sending it forth to the IESG if there seems to be rough consensus
among the involved parties.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

---

From: Mark Allman <[email-masked]>
Date: Thu, 26 Feb 2009 09:19:02 -0500

Wes-

> My TCPM co-chair view is that the document is blocking other things in
> the RFC editor queue with MISSREF, and since this is the last
> remaining WGLC comment that needs to be addressed on 2581bis, I think
> the WG should try to respond promptly on it.  Since the authors and
> Markku have discussed this offlist for a while, and seem to agree that
> the effect is fairly minor, waiting only a couple of weeks for
> comments to come in seems appropriate, and then issuing the update and
> sending it forth to the IESG if there seems to be rough consensus

In fairness, I don't believe this is quite right.  I believe that the
authors and Markku all believe the overall effect will be minor.
However, I do not believe there is consensus among that set of folk
about the right course of action and that was in fact the impetus for
Ethan's note: to call the WG's attention to this lack of consensus and
get the WG's opinion on which of two sketched paths we should take.

My own view here is that the document has been in its current state for
a while, a lot of people have read it and so the default answer here
should be "no change".  I.e., unless the WG makes a strong push for a
change we should leave things alone at this point.  The question has
been on the table for a week already.  We'd very much appreciate
feedback. 

(And, we can nominally issue an I-D quickly, but another stumbling block
is this new boilerplate.  We do not believe we can issue this draft with
the language that RFC5378 requires given hat we do not believe we can
get all contributors to sign off on this (nor are we willing to do the
legwork).  We understand there is a workaround to RFC5378 but the
authors have not yet all had a chance to look this over and make sure we
are happy releasing the I-D under that boilerplate.)

allman