Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis

["Scharf, Michael" <[e-mail]>]

Hi all,

As always in a discussion about EXP vs. PS, I suggest having a look at the definition of Proposed Standard, e.g., in RFC 7127:

   A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.  Proposed Standards are
   of such quality that implementations can be deployed in the Internet.
   However, as with all technical specifications, Proposed Standards may
   be revised if problems are found or better solutions are identified,
   when experiences with deploying implementations of such technologies
   at scale is gathered.

As an individual contributor to TCP and congestion control research, I believe that a CUBIC specification can meet these requirements.

Maybe the "no known technical omissions with respect to the requirements placed upon it" could benefit from some text inside rfc8312bis to make clear what the requirements are, i.e., what the standard tries to achieve (and what not). But, at least to me, the current section 5 already covers that. I am not against adding some more text on the scope of rfc8312bis, but I'll certainly not insist in that.

Also, another repetition of what I wrote already in the past:

In my observation, TCPM is extremely conservative when it comes to standards track documents, as compared to other WGs in the IETF (also outside TSV, e.g., in RTG or OPS). Probably that is not a bug, but a feature in a standardization body. And at least I have not tried to change that thinking as chair in the last 10 years. Nonetheless, if a document can meet the bar for a PS, I believe TCPM should try to go for a PS.

Michael (not wearing any hat)


> -----Original Message-----
> From: Lars Eggert <[e-mail]>
> Sent: Monday, February 21, 2022 3:52 PM
> To: Yoshifumi Nishida <[e-mail]>
> Cc: Markku Kojo <[e-mail]>; [e-mail] Extensions
> <[e-mail]>; tcpm-chairs <[e-mail]>
> Subject: Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis
> 
> Hi,
> 
> first, as an editor (but not wearing other hats) I do object against reclassifying
> the document as Experimental or Informational, esp. this late in the process.
> 
> CUBIC is not a new CC proposal. It's been ubiquitously deployed on the
> Internet for many years. All major TCP stacks use it by default. Given that, I
> don't see how the IESG statement on "Experimental Specification of New
> Congestion Control Algorithms" applies here.
> 
> (As an aside, that statement was specifically written when CUBIC, Compound
> and Hamilton were all jostling for RFC publication. The community converged
> on CUBIC in the meantime.)
> 
> CUBIC *is* the default CC mechanism used on the Internet and in other IP
> networks. It should be published on the standards track.
> 
> Second, this is the second time that an individual raised a long list of issues
> after the WGLC has ended. We did try to work through all the issues that
> were raised after the first WGLC, but the individual often failed to participate
> in the discussion in a timely manner. I now see at least several of those same
> issues re-raised by the same individual. Before going down the same path a
> second time, I would actually ask the WG to confirm there is consensus that
> the raised issues are valid (and if they are valid, commit to contributing to a
> resolution in a timely manner.)
> 
> Thanks,
> Lars