Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 5 Jan 2017 20:17:24 -0800

Hello,
This is just a reminder. We will appreciate your feedback!
Thanks,
--
Yoshi

On Fri, Dec 16, 2016 at 3:10 PM, Yoshifumi Nishida <[email-masked]>
wrote:

> Hello,
>
> As we have discussed during Seoul meeting, the chairs decided to start
> running a call for adoption of draft-khademi-tcpm-alternativebackoff-ecn.
>
> We would like to confirm that the TCPM community agrees to:
>
>   * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working
> group item to publish it as an experimental RFC.
>   * add a corresponding milestone to the TCPM charter.
>
>      Aug 2017  Submit document on alternative backoff with ECN algorithm
> to the IESG for publication as an Experimental RFC
>
>
> As the end of the year is approaching, we decided to run a longer call
> than usual. Please let us know by * Friday January 6  2017 *, whether you
> support or object adoption of the document.
>
> Thanks,
> --
> tcpm co-chairs
>

---

From: David Ros <[email-masked]>
Date: Fri, 6 Jan 2017 10:23:05 +0100

Hi,

I support adoption of this draft.

Thanks,

David

On 06 Jan 2017, at 05:17, Yoshifumi Nishida <[email-masked]> wrote:

> On Fri, Dec 16, 2016 at 3:10 PM, Yoshifumi Nishida <[email-masked]> wrote:
> Hello,
> 
> As we have discussed during Seoul meeting, the chairs decided to start running a call for adoption of draft-khademi-tcpm-alternativebackoff-ecn. 
> 
>   * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working group item to publish it as an experimental RFC.
>      Aug 2017  Submit document on alternative backoff with ECN algorithm to the IESG for publication as an Experimental RFC
> 
> 
> As the end of the year is approaching, we decided to run a longer call than usual. Please let us know by * Friday January 6  2017 *, whether you support or object adoption of the document. 
> 
> Thanks,
> --
> tcpm co-chairs
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Stein Gjessing <[email-masked]>
Date: Fri, 6 Jan 2017 10:29:06 +0100

Hi,

I support adoption of the document

Cheers,
Stein

On 06 Jan 2017, at 05:17, Yoshifumi Nishida <[email-masked] <mailto:[email-masked]>> wrote:

> On Fri, Dec 16, 2016 at 3:10 PM, Yoshifumi Nishida <[email-masked] <mailto:[email-masked]>> wrote:
> Hello,
> 
> [email-masked] <mailto:[email-masked]>

---

From: hiren panchasara <[email-masked]>
Date: Fri, 6 Jan 2017 09:30:05 -0800

> running a call for adoption of draft-khademi-tcpm-alternativebackoff-ecn.

I support the adoption.

Cheers,
Hiren

---

From: John Leslie <[email-masked]>
Date: Fri, 6 Jan 2017 16:18:39 -0500

> > to the IESG for publication as an Experimental RFC

   I am happy to see an experiment proposed.

   But I don't think this document adequately describes the experiment:
thus I'd rather see agreement on a few things before we adopt this.

- what is the duration of the experiment?

- how will the results be evaluated?

- (how will we even tell which senders are experimenting?)

   Also, we should allow for other experiments. I am not convinced that
the optimum response to an ECN mark is to reduce flightsize by exactly
20% in every case. (At the least, we should allow experimenting on what
reaction there should be to a _second_ ECN mark within one RTT.)

   I remind folks that by it's very nature, ECN-marking can signal things
by the _rate_ of marking. It would be a shame to paint ourselves into a
corner where we can't take advantage of that.

--
John Leslie <[email-masked]>

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 6 Jan 2017 13:31:10 -0800

> - (how will we even tell which senders are experimenting?)

I share same sentiments.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 9 Jan 2017 11:38:19 -0800

Hello,

> - (how will we even tell which senders are experimenting?)

hmm. I think it's a valid point for an experimental draft.
But, I'm not sure if we need to agree on them before the adoption.
We might want to know generic milestone before the adoption, but I'm not
sure if we need to see the details.

Thanks,
--
Yoshi

---

From: John Leslie <[email-masked]>
Date: Tue, 10 Jan 2017 07:42:04 -0500

Yoshifumi Nishida <[email-masked]> wrote:
>... 

   Obviously, any language covering my three questions may be revised
after adoption.

   But I find the total absence of language about these three worrysome.

   When I asked for "agreement" I didn't intend formal "consensus" --
just that the proposal should address those three. Without addressing
them, it looks like it's intended as Proposesd Standard.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 11 Jan 2017 00:23:02 -0800

Hi John,

> them, it looks like it's intended as Proposesd Standard.

Thanks. It makes senses to me.  I believe these points should be addressed
in the new version.
Do the authors feel comfortable with it? any concerns?

I think I saw enough supports for the draft while I don't see any
objections.
I am thinking that it can be adopted if the authors can guarantee to
address these points in a new version.

Thanks,
--
Yoshi

---

From: [email-masked]
Date: Wed, 11 Jan 2017 08:33:33 -0000

Hi John, Yoshifumi, and others,

I haver some thoughts on these comments, see below.

> address these points in a new version.

 I agree there are many things that can be done when information is fed
back about the reception of individual marks (as in Acc ECN), such as
responding to multiple ECN marks within the same RTT,  adjustments based
on the rate of marking, etc. However, I think that such advanced
reactions need to have the more accurate feedback.

As one of the authors, I also agree we should try to bound the duration of
the experiment, if we can. ABE is a simple change, and I’d hope could soon
see deployment. ABE is a proposed change to the basic reaction when Marks
are reported within a RTT - using only RFC3168 feedback (i.e., ECN-Echo).
That’s why I think it is good that ABE can be taken forward in TCPM.

In parallel to this work, I’d be interested to see *how* to best react
after negotiating Accurate ECN, which I’d expect opens a much bigger (more
exciting?) set of questions, is this part of what you are suggesting?  -
I’d expect this debate will likely follow in tsvwg as we discuss L4S and
other new ideas for AQM and transport reactions. If it helps, we can offer
to make this clearer in the ID (improving on what is said in section 3.2) 
and could note the context much earlier,  since I expect much more will
emerge about ECN after this is published).

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Wed, 11 Jan 2017 14:31:45 +0100

> On 11 Jan 2017, at 09:23, Yoshifumi Nishida <[email-masked]> wrote:
> 
> Hi John,
> 
> Thanks. It makes senses to me.  I believe these points should be addressed in the new version.

For me, comfortable yes, concerns none  :)

> I think I saw enough supports for the draft while I don't see any objections.
> I am thinking that it can be adopted if the authors can guarantee to address these points in a new version. 

I have no problem to make that promise, I do think it's a very reasonable request

Cheers,
Michael

---

From: grenville armitage <[email-masked]>
Date: Thu, 12 Jan 2017 06:16:35 +1100

>> On 11 Jan 2017, at 09:23, Yoshifumi Nishida <[email-masked]> wrote:
     [..]
> I have no problem to make that promise, I do think it's a very reasonable request

+1 (as another co-author)

cheers,
gja