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

[Markku Kojo <[e-mail]>]

Lars,

On Mon, 21 Feb 2022, Lars Eggert wrote:

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

Maybe I should not have pointed to the IESG statement but RFC 5033.
The IESG statement describes the IETF process while RFC 5033 provides 
the guidelines for the community, and the IESG statement explicitly points 
to (the draft of) RFC 5033. RFC 5033 is crystal clear on what kind of 
evaluation is expected from an alternate congestion control proposal to 
the IETF. "New" is borrowed from RFC5033 where it means "alternate", not 
how old the algo is or some such, and also in this context it means a new 
proposal to the IETF, i.e., an I-D submitted to the IETF.

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

Careful reading and understanding of RFC 5033 would be useful. RFC 5033 
and the IESG statement were written exactly to avoid a situation where 
any such alternate CC algo gets widely deployed in the global Internet 
without being first thoroughly evaluated by the IETF. The process was 
seen important to ensure thorough enough evaluation of any alternate CC 
before its deployment in the Internet.

Could you possibly explain more of your rationale when saying "don't 
see how the IESG statement applies here"?
The fact seems to be that CUBIC has taken the wrong path and has been 
deployed without any IETF evaluation. This is exactly opposite to the 
consensus that the IETF/TSV community had and what has been documented in 
RFC 5033 and the IESG statement. I'm sorry to say that it seems 
incomprehensible to me that now the (long-term) deployment in the 
Internet which was unwanted by the IETF is used in the IETF as rationale 
why CUBIC does not need any IETF evaluation. In particular, when CUBIC is 
targetted as PS which is supposed to have even higher bar than when 
targetting at Experimental.

Furthermore, despite the extensive deployment experience with CUBIC, the 
rfc8312bis draft does not cite any results comparing CUBIC vs. Reno 
that were gathered and publishhed since CUBIC was deployed. Where is the 
the extensive deployment experience documented? That is, could you 
possbly explain on what information the tcpm wg can base its decision 
whether rfc8312bis fullfils the criteria set in RFC 5033?

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

Lars, I would have hoped that the decision on this draft and the 
remaining issues were based on arguments on the actual issues.

When publicly accusing an individual on misbehaviour it would be good to 
have the facts correct. The 2nd last call was announced by a tcpm wg 
chair: "The WGLC runs until *Feb 11*."
Below please find the timestamp as seen by ietfa.amsl.com for the 2nd wglc 
message by the individual:

  Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com
  (Postfix) with ESMTP id 7C1B53A1371; Fri, 11 Feb 2022 21:34:42 -0800
  (PST)

I have always thought that IETF is an international organization and any 
deadlines set with no specific timezone are automatically "anywhere on the 
earth" regardless of the timezone of the contributor's mail system that 
she/he uses for sending messages to the IETF lists. Could you kindly 
explain if this is incorrect such that any individual may avoid such 
a mistake in the future?

The individual raised the first list of issues after the first WGLC 
had ended with only a *single* review (thanks Yoshi) and the tcpm chairs 
explicitly asked if anyone has any thoughts on the doc. The individual 
apologised for the late list of issues and explained that the draft had 
notable conflicts with existing RFCs, which was the major reason for the 
individual to react at that late point. While checking the draft for 
for the conflicts, the individual listed also other issues that seemed to 
require more work. Could you kindly explain how this was wrong thing to 
do?

I think I can also speak for the individual on not always participating 
in the discussions on a timely manner. That is true and the individual 
also informed several times that the individual had very limited cycles 
for the IETF work. To begin with the individual also indicated that many 
issues may deserve discussion on the wg list. The editor responded:

> true, and we will bring those to the list that should be discussed here.

However, many issues were closed in github even though they were 
clearly still unresolved. Sometimes also without confirming 
with the individual.

More importantly and given that this is a wg document, would't it have 
been a viable option to take any unresolved issues to the wg list 
where the wider expertice is instead of closing them in github? By this 
far no issues has been taken to the list by the editor.

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

First, the issues listed for the 2nd WGLC were not re-raised but they 
were more or less unresolved: no consensus has been decleared in the 
discussions on those issues.

Second, definitely these issues should be discussed on the wg list. We are 
about making very significant decisions, not only about this draft, but in 
its current form it has implications to several stds track RFCs via RFC 
5681. One important issue that has not been discussed much at all is 
whether this draft needs to update RFC 5681, and if it does, we need to 
explain and justify it carefully. The current text leaves many questions 
open on what "Updates" here actually means.

Thanks,

/Markku