Subject: [tcpPrague] Enough energy for an L4S/TCP Prague BoF?

From: Bob Briscoe <[email-masked]>
Date: Wed, 1 Jun 2016 11:53:22 +0100

All,

Can some folks respond on whether they think it is right to hold a BoF 
on this topic in Berlin.

Back in Jul 2015, when we had the first ad hoc meeting about evolving 
DCTCP (the one where Matt Mathis suggested we call it TCP Prague), there 
was a huge amount of energy and excitement in the room.

However, I've noticed that the discussion on this list seems to move in 
fits and starts.
Can anyone suggest why?

I see much more discussion off-list about building projects, around the 
enabling idea of the dualQ.
Perhaps it's just that it takes a long time for some people to be able 
to to shift the focus of their work.

If that's so, then I guess it is still worth the core proponents 
pressing ahead.
Because others only need to influence the direction of travel of a 
project if it is moving!

Thoughts?

Bob

PS. The BoF proposal deadline is on Friday.
I'm guilty for not having yet delivered what I promised: a problem 
statement draft - working on it now.

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: John Leslie <[email-masked]>
Date: Wed, 1 Jun 2016 11:29:08 -0400

> Can some folks respond on whether they think it is right to hold a BoF 

   I must admit I see little reason for a non-WG-forming formal-BoF.

   The formal-BoF process is really organized around forming a WG. An
informal-BoF can be organized entirely outside this process; and were
I to attend Berlin, I would certainly want to participate.

   It's getting awfully late to start organizing a WG-forming BoF, so
I'd tend to set my sights on an informal-BoF.

   We should definitely note draft-khademi-tsvwg-ecn-response, recently
submitted to TSVWG, presumably intended to become adopted as a WG draft,
and setting a basis for relaxing the "same-as-drop" rule of RFC3168.

   It mentions draft-khademi-tcpm-alternativebackoff-ecn, which presumably
is intended to become a TCPM WG draft and offers a different experiment
from dualq which we've been discussing here.

   I think it's more important to get involved in those discussions
than to try for a formal-BoF in Berlin.

   Obviously, YMMV...

--
John Leslie <[email-masked]>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 1 Jun 2016 19:32:13 +0100

John,

Before getting back to the WG-forming vs. non-WG forming BoFs debate, 
let's explore your idea from a couple of weeks back, which might not 
even need a BoF:

On 22/05/16 00:55, John Leslie wrote:
>     Thus, I'd like to see a first deliverable be a Proposed Standard laying
> out ground-rules for (quite possibly multiple) Experimental status documents.
> I know I've seen a fairly wide range of proposals differing in details from
> L4S (some of them very dependent upon variations in delay); and it's hard
> to believe that nobody will still want to push for their idea.

I think you are saying this PS would:
a) state the requirements for a new form of "ECN not the same as drop", 
targeted at much lower latency queuing (including L4S, ABE and others).
b) free up the use of ECT(1) if necessary for this purpose (needed by 
L4S but not ABE), by formally declaring the end of the ECN nonce 
experiment, and updating all the RFCs (including PSs) that refer to 
"same as drop" behaviour for ECN, or the ECN Nonce.

If such an RFC could be written (see below), it would serve the purpose 
we were hoping that a BoF would serve: to describe how a set of pieces 
might fit together as part of a larger programme of work, even if they 
are standardized in separate WGs (and even if some improve the Internet 
on their own whether or not the master-plan happens).

It would have the advantage over a BoF that it would require the 
consensus of all the affected WGs (as does any IETF RFC).

But...
Can someone who understands IETF process better than I, answer these 
questions:
* Can a Proposed Standard just 'clear a space' without actually defining 
a specific protocol to fill that space? Any examples from history?
* Don't protocol requirements tend to be written in informational RFCs, 
not PS?

Even if PS is an appropriate status, I see problems writing such an RFC 
so abstractly that it would encompass as-yet-unknown alternative 
proposals. Of course, I see no problem describing where an existing 
proposal fits, e.g. ABE.

For instance, draft-briscoe-tsvwg-ecn-l4s-id-01 has very similar scope 
to the document you propose, except:
a) It has currently been written as experimental (but it says what it 
would say if it was PS).
b) it precisely (but very generally) describes the new semantics of the 
identifier.

Take a read of it, then tell us how you think it could be written 
without any specifics,... to become the doc you are thinking of.
I think the IESG (and the intended audience) would have a hard time 
understanding such an abstract document.

Or perhaps you are /not/ saying that it has to be completely 
non-specific. Perhaps ecn-l4s-id is already close to the sort of doc you 
are talking about. For instance:
* it describes the problem
* it refers to the technology that would be necessary and sufficient in 
the network (some sort of DualQ);
* it has a section on "Pre-Requisite Transport Layer Behaviour", where 
requirements on TCP, SCTP, RMCAT etc. have been written.
* It also obsoletes the ECN nonce.

*A New Working Group?**
*
I believe such a doc could and should be written in tsvwg, with formal 
last calls to tcpm, aqm, rmcat and iccrg as well.

I do not see that a separate WG is necessary, or even useful, for 
writing this.
What's your reasoning?
We need to be quick, cos if we need a new WG, we've only got 2 days ;)

There are a couple of things that a BoF would achieve that a new I-D 
would not achieve:
* socializing with the rest of the IETF, particularly the IESG and IAB, 
that this work is starting, so they can understand it and expect it.
* highlighting the potential architectural importance of the work, 
particularly to the IESG and the IAB (e.g. sunsetting TCP Reno, 
implications for Diffserv, etc).

There must be other ways to achieve these two goals? A plenary 
presentation? An IAB workshop?

Regards

Bob

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 1 Jun 2016 21:31:13 +0200

Hi Bob,

> Am 01.06.2016 um 12:53 schrieb Bob Briscoe <[email-masked]>:
> 
> However, I've noticed that the discussion on this list seems to move in fits and starts.
> Can anyone suggest why?

I believe it would help to foster discussion if someone (you) would send a problem statement to the list because right now there are a lot of people interesting in this topic where everybody might have his/her own idea what this is about. Having a common understanding of want we want is the first step. For me most of things I’ve seen so far are very wide spread and I guess there something for everybody that sounds interesting…

Just my 2c.

Mirja

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 1 Jun 2016 20:48:49 +0100

M, OK, Will do. B

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 1 Jun 2016 22:10:01 +0100

John, Gorry,

A random new thought...
Another mechanism I've seen for this sort of thing is a mini-BoF within 
an existing WG agenda.
I'm not sure whether a mini-BoF needs any official procedure. Am I 
correct that a mini-BoF is appropriate for extending a WG's charter in a 
more major direction than just adding one doc, and/or where it's not 
clear whether a new WG might be needed instead?

It could possibly be a tsvwg mini-BoF.
Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists?

Bob

On 01/06/16 19:32, Bob Briscoe wrote:
> a) state the requirements for a new form of "ECN not the same as 
> drop", targeted at much lower latency queuing (including L4S, ABE and 
> others).
> If such an RFC could be written (see below), it would serve the 
> purpose we were hoping that a BoF would serve: to describe how a set 
> of pieces might fit together as part of a larger programme of work, 
> even if they are standardized in separate WGs (and even if some 
> improve the Internet on their own whether or not the master-plan 
> happens).
>
> * Can a Proposed Standard just 'clear a space' without actually 
> defining a specific protocol to fill that space? Any examples from 
> history?
> * Don't protocol requirements tend to be written in informational 
> RFCs, not PS?
>
> Even if PS is an appropriate status, I see problems writing such an 
> RFC so abstractly that it would encompass as-yet-unknown alternative 
> b) it precisely (but very generally) describes the new semantics of 
> the identifier.
>
> non-specific. Perhaps ecn-l4s-id is already close to the sort of doc 
> you are talking about. For instance:
> * it refers to the technology that would be necessary and sufficient 
> in the network (some sort of DualQ);
> * socializing with the rest of the IETF, particularly the IESG and 
> IAB, that this work is starting, so they can understand it and expect it.
>> Bob Briscoe<[email-masked]>  wrote:
>> John Leslie<[email-masked]>
>>
>> -- 
>> Bob Briscoehttp://bobbriscoe.net/

---

From: John Leslie <[email-masked]>
Date: Wed, 1 Jun 2016 17:53:12 -0400

> A random new thought...

   (I'm still working on a reply to Bob's earlier email today: I'm
tending to make it a private reply since I'm not seeing a lot of interest
in discussing it on the tcpprague list.)

> Another mechanism I've seen for this sort of thing is a mini-BoF within 

   I'm not aware of any rules pertaining to such a mini-BoF -- I'd guess
the WGCs are entitled to call a section of their WG session a "mini-BoF"
and operate under near-BoF rules...

> Am I correct that a mini-BoF is appropriate for extending a WG's charter
> in a more major direction than just adding one doc, and/or where it's
> not clear whether a new WG might be needed instead?

   ISTM that is up to the TSVWG chairs.

> Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists?

   I really doubt such a thing exists.

   I'd be happy to see what Bob is suggesting as part of a TSVWG agenda.

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 2 Jun 2016 17:02:54 +0100

Jana,

When we held the L4S Bar BoF in Buenos Aires, you said we were moving 
too fast.
I think the sentiment behind your point was that we seemed to be 
shutting out similar approaches too fast.
Can you clarify if that's what you meant?

If yes, I'd be interested to know if this impression came from the 
presentations or the drafts. Because:
* in the drafts, we've specified example design(s) in appendices, and in 
the normative body text, we've distilled only the essential structure of 
the approach as normative standards statements.
* in presentations, I (at least) have a tendency to want to be concrete 
- to demonstrate that there is real code and equipment and tests, etc.

I'd also be interested to hear if you think we have been successful in 
generalising the drafts, or whether you think they are still too specific.

In particular, you mentioned making space for delay-based congestion 
control, which I would /not/ want to include for the reasons below.
Is there any rationale for being /that/ general?

Background:
L4S aims for a very shallow queue, which we indicate with immediate ECN 
notification (the L4S demo used a 5-MTU threshold when there is no 
traffic in the classic queue).
ECN gives much more precision, and immediately. Rather than waiting for 
enough packets to get an imprecise delay-measurement heuristic.
(for instance the sender can dither packet inter-arrival time during 
flow-start to sense available capacity, which it can then approach very 
rapidly without overshoot.)

This is what I meant when I said we have created an "incrementally 
deployable clean-slate"...
There is a brief window of opportunity during which we (ie. you, 
everyone) can all jiggle both host and AQM together. But it will have to 
be standardised soon, then it will ossify. We can't wait too long, 
otherwise everyone loses interest.

Seriously, I first presented the idea of deploying DCTCP on the Internet 
in the same session as Van Jacobson introduced CoDel (Jul 2012). We 
published the main drafts on L4S in Jul 2015, so I think it's reasonable 
to expect to be moving on to setting standards agendas about a year 
after that.
Your thoughts are always enlightening, so if you haven't set aside time 
to read, consider deeply and comment,... soon would be good.

Bob

[I actually wrote a similar email straight after Buenos Aires, but I 
just noticed I sent it from the wrong address, so the list rejected it.]

On 01/06/16 11:53, Bob Briscoe wrote:
> DCTCP (the one where Matt Mathis suggested we call it TCP Prague), 
> there was a huge amount of energy and excitement in the room.
>
> I see much more discussion off-list about building projects, around 
> the enabling idea of the dualQ.

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 3 Jun 2016 17:17:01 +0100

Mirja,

Status report on the BoF proposal for you & the list:...

You will have seen we've uploaded a problem statement.
The BoF proposal is complete in theory, but completely absent on the wiki.
I'll fill in the wiki in the next couple of hours.

Sorry to everyone that this won't provide long to react to anything they 
disagree with. So here's a summary of what will be there:

The proposal is to have a non-WG-forming BoF, with a suggestion that in 
practice it takes the form of a mini-BoF within TSV-AREA.
We are still putting it through as a BoF request, because we think it is 
important that the IESG get a heads-up on this, rather than the first 
they know being when RFCs start to appear two years later. Then if it is 
decided to do a mini-BoF within TSVAREA, at least the IESG/IAB can know 
to come along.

We will suggest that the questions asked are:
1/ Support this work?
2/ Interested in helping implement, test, write, review, etc.?
We believe we should leave the question of how the work is organised 
(across WGs? a new WG? a hybrid of the two? etc.) for the ADs, rather 
than burn time in a meeting on that.

One of the main purposes will be to demonstrate to the community that 
there are people working on this, and others that are planning to.
Thank you for everyone who has volunteered to give short talks about 
your current activity around L4S, and/or your plans.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 3 Jun 2016 21:10:45 +0100

All,

The L4S BoF proposal is here:
https://trac.tools.ietf.org/bof/trac/wiki#Transport

There's 4 hours left, if anyone wants to suggest any changes.
I'll be off-line for a while, but I'll look at email before the cut-off.

In the mean time, I'll formally send the request to Mirja (we can change 
the wiki in parallel until the deadline).

Cheers

Bob

On 03/06/16 17:17, Bob Briscoe wrote:
> Sorry to everyone that this won't provide long to react to anything 
> they disagree with. So here's a summary of what will be there:
>
> The proposal is to have a non-WG-forming BoF, with a suggestion that 
> in practice it takes the form of a mini-BoF within TSV-AREA.
> We are still putting it through as a BoF request, because we think it 
> is important that the IESG get a heads-up on this, rather than the 
> first they know being when RFCs start to appear two years later. Then 
> if it is decided to do a mini-BoF within TSVAREA, at least the 
> IESG/IAB can know to come along.
>
>> I believe it would help to foster discussion if someone (you) would 
>> send a problem statement to the list because right now there are a 
>> lot of people interesting in this topic where everybody might have 
>> his/her own idea what this is about. Having a common understanding of 
>> want we want is the first step. For me most of things I’ve seen so 
>> far are very wide spread and I guess there something for everybody 
>> that sounds interesting…
>>
>> Just my 2c.
>>
>> Mirja
>>
>>
>> --

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 15 Jun 2016 18:40:11 +0100

This topic may well fit within the scope of TSVWG.We could in principle 
consider such a discussion, *IF* that's the best use of face-to-face 
time at the meeting.

Since L4S is approved, please discuss the topics there.

Gorry

On 01/06/2016 22:53, John Leslie wrote:
> _______________________________________________
> tcpPrague mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpprague
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 Jun 2016 08:34:21 +0100

Gorry,

Thank you for this - v useful.

I would like to get a sense of people's opinion on a particular 
political/procedural question that John L has raise that I think will be 
central. And you may have a better feel for 'public opinion' on this 
than me...

I expect any L4S aqm algos and any congestion control algos to be 
experimental track.
However, in order to be experimented with on the public Internet, they 
will need to distinguish their packets with an identifier.
ECT(1) is the leading contender, complemented by CE as the marking.{Note 1}

There are many pre-existing standards track docs {Note 2} that describe 
usage of ECT(1), based on the assumption that it was an experimental nonce.
A Proposed Standard RFC would be needed to update these PSs.

John L suggests (if I understand it correctly) a PS that makes space for 
experiments by reserving ECT(1) again, without redefining it for any new 
purpose (I guess it would mention L4S non-normatively). This RFC would 
be written to update all the mentioned PS RFCs. I assume he is proposing 
that then a new definition of ECT(1) for L4S could be written as a new 
experimental track use of this newly reserved codepoint.

a) Is this a feasible way to evolve these proposed standards?
b) Do you think there might be support for this?

One problem I see:
* L4S needs to redefine the semantics of both ECT(1) /and/ CE, with the 
definition of CE shared between L4S and Classic flows. {Note 3}
   We may have to somehow word the "John-L-proposed-PS" to allow this?

Bob

{Note 1} There are no perfect choices (the choices and their compromises 
are listed in draft-briscoe-tsvwg-ecn-l4s-id).
{Note 2} Listed under "the standardization problem" in our L4S problem 
statement draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem.
                Also, quoting from the above l4s-id draft (which is 
written as intended for the experimental track):

"  Therefore, if the experiment is successful and a descendant of this
    document proceeds to the standards track, it would be expected to
    update the specification of ECN in IP [RFC3168].  It would also
    update the transport behaviour when using ECN in the standards track
    RFCs listed in Section 2.3 (i.e.  ECN in TCP [RFC3168], in SCTP
    [RFC4960], in RTP [RFC6679], and in DCCP [RFC4340]).
"
{Note 3} Hosts understand which meaning of CE is intended, because they 
have per-flow context. For the network, the l4s-id draft proposes that a 
stateless L4S-capable classifier classifies CE as L4S. Any ECN-capable 
queue can still re-mark either ECT(0) or ECT(1) to CE.
This last point is no change from RFC3168. But the first two points 
/are/ changes to the PSs.

On 15/06/16 18:40, Gorry Fairhurst wrote:
>
> This topic may well fit within the scope of TSVWG.We could in 
> principle consider such a discussion, *IF* that's the best use of 
> face-to-face time at the meeting.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 16 Jun 2016 13:48:11 +0100

Hi Bob,

As it currently stands, I think a proposal to change the meaning of the 
ECN base spec should come to TSVWG, as should updating the experimental 
codepoint use currently assigned to ECN-NONCE. This would mean 
re-defining ECT(0) as not equivalent to ECT(1) within the default (BE) 
diffserv class - currently this is only permitted as an alternate behaviour.

I think it could perhaps be argued that the meaning of CE is not 
significantly changed, rather the marking behaviour and interpretation 
would be updated for endpoints using the new proposed method. A short 
draft that notes the impact on existing RFCs would be good as a step 
forward.

For the moment, let's first discuss at the BoF what is needed - deciding 
where to get standards progressed comes later.

Gorry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 16 Jun 2016 08:02:32 -0500

Hi, Bob and Gorry,

On Thu, Jun 16, 2016 at 7:48 AM, Gorry Fairhurst <[email-masked]>
wrote:

> codepoint use currently assigned to ECN-NONCE. This would mean re-defining
> ECT(0) as not equivalent to ECT(1) within the default (BE) diffserv class -
> currently this is only permitted as an alternate behaviour.
>
> would be updated for endpoints using the new proposed method. A short draft
> that notes the impact on existing RFCs would be good as a step forward.
>

I agree with this (but see below) ...

>> ECT(1) is the leading contender, complemented by CE as the marking.{Note
So, just to make sure I understand the proposal ... because I'm probably
confused.

I would support publication of these algorithms as Experimental, if that's
what is proposed.

Are you thinking the experiment is, that devices on the public Internet are
upgraded to provide this new functionality even if they aren't
participating in the experiment, and then this new functionality is then
experimented with, and the result of the experiment might be "now we know
why that's a bad idea, so we're not going to standardize it", so then the
devices revert to previous functionality?

The way I thought this worked was that when you experiment with a
standards-track protocol, the Experimental RFC is supported only by devices
that are participating in the experiment, and the Experimental RFC doesn't
update the standards-track RFC(s) until the experiment succeeds, and then
the Experimental RFC is republished as a standards-track RFC that updates
the previous standards-track RFCs. If you decide the experiment is a bad
idea, only devices that opt in to the experiment need to revert to previous
functionality.

Are you thinking that wouldn't work here?

Thanks,

Spencer

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 Jun 2016 15:50:39 +0100

Gorry,

On 16/06/16 13:48, Gorry Fairhurst wrote:
> Hi Bob,
>
> As it currently stands, I think a proposal to change the meaning of 
> the ECN base spec should come to TSVWG, as should updating the 
> experimental codepoint use currently assigned to ECN-NONCE. This would 
> mean re-defining ECT(0) as not equivalent to ECT(1) within the default 
> (BE) diffserv class - currently this is only permitted as an alternate 
> behaviour.
Understood and agreed that tsvwg is the place for these. Thx.
> draft that notes the impact on existing RFCs would be good as a step 
Well, CE (and ECT(1) would become a classifier to select a different 
queue as well as to select a mark/drop treatment. Admittedly that's 
pretty similar to today's definition, where the ECN field solely selects 
the latter, but it's a substantive difference.

Nonetheless, I guess no-one changed the TCP and UDP specs when fq 
starting using port numbers as queue selectors ;)
>
> For the moment, let's first discuss at the BoF what is needed - 
> deciding where to get standards progressed comes later.
Can I beg a little more of your time? I'd like to be able to discuss 
this by email first if poss - I am trying to ensure the BoF runs 
smoothly by trying to sense and adapt to consensus beforehand.

Reason: I'd like to produce a draft intended for the 'most likely' track 
before the draft deadline. That way it highlights all the potential 
pitfalls of choosing that track.

There are three possible approaches to get an identifier started:
1/ EXP only
2/ PS to reserve space, EXP to use it
3/ PS only

Pros and cons:
1/ draft-briscoe-tsvwg-ecn-l4s-id was written as "intended EXP" and it 
proved (to JohnL) that we needed something that could trump existing PSs.

2/ JohnL's 2-stage approach is less of a jump for the IESG to take, and 
it seems fairly clean, but it introduces two rounds of standardisation 
and therefore more interoperability complexity.

3/ Redefining the codepoints straightaway in a PS would be cleaner, but 
perhaps too much of a jump for the IESG.

Bob

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 16 Jun 2016 16:04:42 +0100

My *own* take is this:

I think the proposed use is EXP, and the proposal should be in an EXP 
ID. I think your intention is to propose an experiment with the Default 
diffserv class and new use of the ECN field. As Spencer noted, be 
careful to explain the implications of the experiment)

If the ID requires an over-ride, or some other document to make that 
happen is less of an issue at the moment. After discussion, if the TSV 
AD, and relevant WG thinks this is a great idea and the risk of the 
experiment is acceptable, then we can help work out how to make this 
happen in the RFC-series. (That may involve a PS update to make this 
happen (2).) -- anyway I think it would be good to have an ID that 
identifies the scale of the update to existing RFCs.

Personally, I don't see option 3 as a likely successful path.

Gorry

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 Jun 2016 16:32:08 +0100

Gorry,

Thanks.
Good to know where we stand with option #3.
To summarise, you're advising #1 for now, and perhaps #2 will be needed 
later.

I've already written #1 (in ecn-l4sl-id) and it doesn't work.

So I think #2 is not just something we might need later, but the only 
option.

Bob

On 16/06/16 16:04, Gorry Fairhurst wrote:
> ID. I think your intention is to propose an experiment with the 
> Default diffserv class and new use of the ECN field. As Spencer noted, 
> be careful to explain the implications of the experiment)
>

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Jun 2016 13:01:18 -0400

Spencer Dawkins at IETF <[email-masked]> wrote:
>...

   I can't answer that part.

> standards-track protocol, the Experimental RFC is supported only by
> devices that are participating in the experiment, and the Experimental
> RFC doesn't update the standards-track RFC(s) until the experiment
> succeeds, and then the Experimental RFC is republished as a standards-
> track RFC that updates the previous standards-track RFCs. If you decide
> the experiment is a bad idea, only devices that opt in to the experiment
> need to revert to previous functionality.

> Are you thinking that wouldn't work here?

   IMHO, such a path to  update RFC 3168 is impractical.

   At 62 pages, RFC 3168 simply covers too much territory. It covers both
the behavior of ECN-capable forwarders and the behavior of TCP senders
and receivers. (Fortunately, it doesn't try to cover the behavior of
non-TCP transports.)

   At the time it was written, it really wasn't practical to cover less
territory. But today, we understand that even TCP transport is entirely
too broad a topic.

   IMHO, we need to break off a limited part of it for Experimental
protocols:
1. that reaction to ECN-CE should be the "same as" drop; and
2. that ECN(1) MAY request marking for a lesser degree of congestion than
   ECN(0).

   This needs justification; and I believe we can give ample justification
without setting on _just_ dual-queue. Surely you've noticed there's
already a separate proposal for differing treatment of ECN-CE.

   I'm hoping we can agree that both experiments can co-exist...

   And even if _both_ experiments are declared a failure; the principle
of allowing differing requests and differing reactions is still 100%
valid.

   Your concern about backing out of an experiment is 100% correct.

   My preference is some kind of registration scheme to state which
senders and which forwarders are implementing an experiment. Registration
is conceptually simple; but associating senders with forwarders remains
challenging. IMHO, we need not solve that: it's sufficient to leave that
question to those who propose a particular experiment.

   Unfortunately, we have to deal with human beings to design experiments.
It is up to those who review the proposals to keep pressure on those
volunteers to distinguish their eventual aims from how to conduct and
evaluate experiments.

   IMHO, if we ask each experimental-track writer to solve that in addition
to designing the intended end-state _and_ how to modify RFC 3168, we're
inviting failure.

   Obviously, YMMV; but I think I owe it to you to provide whatever advice
I can.

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 24 Jun 2016 18:41:31 +0100

Since this is TCP-Prague, I'm speaking here only as an author of the ABE 
spec...

On 24/06/2016 18:01, John Leslie wrote:
> Spencer Dawkins at IETF<[email-masked]>  wrote:
>> ...
>> track RFC that updates the previous standards-track RFCs.
That seems correct to me.
>> If you decide
I disagree of course - the CE-marking proposal has already been 
discussed at the IETF - and I suggest no ECN is likely to be found using 
RED - and ECN-marked RED is now anyway now deprecated. Many modern AQM 
methods CE-mark on a shallow queue - and I think we need to update the 
PS to reflect this.

I also don't see a specific experiment that is needed here  - what would 
be needed to test for safety in deployment? I *think* particular update 
can be taken directly to PS.
> 2. that ECN(1) MAY request marking for a lesser degree of congestion than
That to me requires two changes - a standards action to address the 
current ECN PS requirement that the two codepoints (i.e., ECT(0) and 
ECT(1) are treated the same in the default DS class.

*AND* followed by an experimental proposal to use something different 
and obsolete the ECN-NONCE.

To me though, these are both TSVWG concerns - discussion should be taken 
on that list.
>     I'm hoping we can agree that both experiments can co-exist...
If you refer to TCP's recation proposed in ABE (now a draft in TCPM), as 
a co-author I would suggest that these two experiments (and their usage 
if they continue) can co-exist. We have spoken to Bob and Koen on this 
topic.
> of allowing differing requests and differing reactions is still 100%
Indeed, until a PS is published.
>     Obviously, YMMV; but I think I owe it to you to provide whatever advice
I can see we need to think about how to manage experiments and that 
there could indeed be lots of possibilities about how to manage the 
ECT(1) codepoint usage. I think your proposal should probably be 
analysed (at least discussed) if (hopefully when) TSVWG decides to allow 
experimental use of that codepoint.

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Fri, 24 Jun 2016 22:24:23 +0200

Dear all,

Two comments in line below - about ABE, what else… sorry for derailing a bit, since this is the TCP Prague list...

> On 24. jun. 2016, at 19.41, Gorry Fairhurst <[email-masked]> wrote:
> 
> Since this is TCP-Prague, I'm speaking here only as an author of the ABE spec...
> 
> I disagree of course - the CE-marking proposal has already been discussed at the IETF - and I suggest no ECN is likely to be found using RED - and ECN-marked RED is now anyway now deprecated. Many modern AQM methods CE-mark on a shallow queue - and I think we need to update the PS to reflect this.

+1 to Gorry  (unsurprisingly).

The ECN “Experiment” has hardly happened, so on what basis de we say that a reaction that is the “same as” drop is safe?
If we just take operational experience, Cubic has first used a backoff (multiplication) factor of 0.8, then 0.7, deployed in Linux and widely used in the Internet.
This isn’t even limited to an ECN signal, which is likely to be produced by an AQM mechanism, and hence much more likely to indicate a shallow queue than loss.

So: I think we can now assert that the Internet won’t melt down if we'd back off using a different multiplication factor than 0.5.
Using such a larger factor *only* in response to ECN is even more conservative, so even safer.

Adding to this, what exactly is the logic that makes “react to marking the same way as you would react to drop” particularly safe?
I can only assume that this assumes the same behavior in the network for ECN-marking and dropping, and so, if we keep as much as possible similar, this would be a safe way to go.
Reality is different. Please see, for example Figure 13 in this pdf:
https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434.pdf
Compare the left and right diagram - this is standard AQM marking behavior (mark where you would otherwise drop) and standard TCP behavior too, yet the result is pretty different.
This is because a packet that is marked, not dropped, is admitted into the queue and thereby changes the AQM dynamics.

So: you have a different result from *just* turning on ECN, similar-to-loss backoff or not.

In conclusion, I struggle to see the big reason why an “exactly like loss” backoff is standard behavior and experimenting with other values should be prohibited.  A new particular value may constitute an experiment, but the “equal to loss” limitation simply isn’t a good thing and should be removed - this removal isn’t an experiment, it's a bugfix. Other values are already used (in Cubic, as I said, and there not only for ECN), but for ECN-only, which is a more conservative route than doing this for loss, the IETF doesn’t even allow the Experiment.

> I also don't see a specific experiment that is needed here  - what would be needed to test for safety in deployment? I *think* particular update can be taken directly to PS.

+1

> That to me requires two changes - a standards action to address the current ECN PS requirement that the two codepoints (i.e., ECT(0) and ECT(1) are treated the same in the default DS class.
> 
> *AND* followed by an experimental proposal to use something different and obsolete the ECN-NONCE.
> 
> To me though, these are both TSVWG concerns - discussion should be taken on that list.
> If you refer to TCP's recation proposed in ABE (now a draft in TCPM), as a co-author I would suggest that these two experiments (and their usage if they continue) can co-exist. We have spoken to Bob and Koen on this topic.

Yes - there are two queues for L4S, and, from a prior email from Bob in this list:
"L4S needs to redefine the semantics of both ECT(1) /and/ CE, with the definition of CE shared between L4S and Classic flows.”
 
These different semantics are necessary to differentiate between the “normal” and “L4S” ways of using ECN.

> I can see we need to think about how to manage experiments and that there could indeed be lots of possibilities about how to manage the ECT(1) codepoint usage. I think your proposal should probably be analysed (at least discussed) if (hopefully when) TSVWG decides to allow experimental use of that codepoint.
> 
> Gorry

Cheers,
Michael

---

From: John Leslie <[email-masked]>
Date: Sat, 25 Jun 2016 10:08:03 -0400

I seem to have flunked Robert Heinlein's class in writing orders!

   Gorry succeeded in misunderstanding my point 1: "that reaction to ECN-CE
should be the 'same as' drop". :^)

   It was "obvious" to me that RFC 3168 now requires that, and that we
need to change so that is no longer required.

   Fortunately, it seems the three of us agree it needs to change. :^)

Michael Welzl <[email-masked]> wrote:
> From: Michael Welzl <[email-masked]>
>... 

>> discussed at the IETF - and I suggest no ECN is likely to be foundi
>> using RED - and ECN-marked RED is now anyway now deprecated.
>> Many modern AQM methods CE-mark on a shallow queue - and I think
>> we need to update the PS to reflect this.

   Fundamentally, I agree: but my concern was the minimum change needed
to 3168.

> The ECN ???Experiment??? has hardly happened, so on what basis de
> we say that a reaction that is the ???same as??? drop is safe?

   IMHO, that is what 3168 meant to say. I've never agreed with it.

> If we just take operational experience, Cubic has first used a backoff
> (multiplication) factor of 0.8, then 0.7, deployed in Linux and widely
> used in the Internet.
> This isn???t even limited to an ECN signal, which is likely to be
> produced by an AQM mechanism, and hence much more likely to indicate
> a shallow queue than loss.

   I agree.

> So: I think we can now assert that the Internet won???t melt down if
> we'd back off using a different multiplication factor than 0.5.

   I agree that would be good background material for a PS RFC relaxing
that rule of 3168.

   (But I don't think we need to limit the difference to applying a
differentt factor: that is a really obvious way, and it has effectively
been tested in actual use; but it is not the _only_ way.

> conservative, so even safer.

   Exactly!

> Adding to this, what exactly is the logic that makes ???react to
> marking the same way as you would react to drop??? particularly safe?

   The argument, as best I recall, was that otherwise one flow would
starve the other. But there are other ways to treat that problem!

> I can only assume that this assumes the same behavior in the network
> for ECN-marking and dropping, and so, if we keep as much as possible
> similar, this would be a safe way to go.

   I don't see any reason to "keep as much as possible similay" if
it's for an Experimental RFC. We should aim for _significant_ improvement.

> https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434.pdf

   I shall get around to reading this today.

>...
> In conclusion, I struggle to see the big reason why an ???exactly like
> loss??? backoff is standard behavior and experimenting with other values
> should be prohibited.

   We three agree it shouldn't.

   But...

   Implementors should be able to read RFC3168 and its metadate and
understand that their ten-year-old code may no longer be compliant.

   It's about a warning-label!

> A new particular value may constitute an experiment, but the
> ???equal to loss??? limitation simply isn???t a good thing and should
> be removed - this removal isn???t an experiment, it's a bugfix.

   Exactly!

>...
>> I also don't see a specific experiment that is needed here  - what
>> would be needed to test for safety in deployment? I *think*
>> particular update can be taken directly to PS.
> 
> +1
 
   (I believe we could treat two issues in the same RFC, in order to
make implementors' jab a little easier. YMMV...)

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 25 Jun 2016 15:20:52 +0100

Email is a wodnerful media... we seem to have a lot more agreement than 
I'd hoped.

(... and yes: If we have more than one simple PS update to 3168, and 
everyone agrees, I think these could form part of the same document).

Gorry

On 25/06/2016 15:08, John Leslie wrote:
> Michael Welzl<[email-masked]>  wrote:
>> From: Michael Welzl<[email-masked]>
>> ...
>>> On 24. jun. 2016, at 19.41, Gorry Fairhurst<[email-masked]>  wrote:
>>> ...

---

From: Michael Welzl <[email-masked]>
Date: Sun, 26 Jun 2016 00:43:53 +0200

how nice to see, we all agree!

Sent from my iPhone

> On 25. jun. 2016, at 16.20, Gorry Fairhurst <[email-masked]> wrote:
> 
> Email is a wodnerful media... we seem to have a lot more agreement than I'd hoped.
> 
> (... and yes: If we have more than one simple PS update to 3168, and everyone agrees, I think these could form part of the same document).
> 
> Gorry
>

---

From: "Black, David" <[email-masked]>
Date: Tue, 28 Jun 2016 20:51:51 +0000

+1 on a simple draft to revise RFC 3168 solely to clear the "space" needed
for this sort of experimentation without getting into any details of what the
experiments will or will not do (NB: that sort of speculation on what's coming
is part of what got the RTP circuit breaker draft into its current situation, so
let's not repeat that ...).

Thanks, --David

> -----Original Message-----
> From: tcpPrague [mailto:[email-masked]] On Behalf Of Michael
> Welzl
> Sent: Saturday, June 25, 2016 6:44 PM
> To: [email-masked]
> Cc: Bob Briscoe; John Leslie; Spencer Dawkins; TCP Prague List
> Subject: Re: [tcpPrague] Experimental dual-queue ECN
> 
> > (... and yes: If we have more than one simple PS update to 3168, and everyone
> agrees, I think these could form part of the same document).
> >
> > Gorry
> >