Subject: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching

From: Bob Briscoe <[email-masked]>
Date: Wed, 18 May 2016 12:47:26 +0100

Folks,

At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos 
Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) 
time-frame.
It was decided to initially use this ML, even tho the scope of L4S is 
wider than TCP Prague.
Consensus was to aim for a non-WG-forming BoF, to demonstrate 
willingness to work on the pieces in existing IETF WGs, and to 
co-ordinate approaches to each WG.

The cut-off is now 2.5 weeks away.
*2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area 
Directors at UTC 23:59.

To organise a successful BoF (referring to rfc5434 
<https://tools.ietf.org/html/rfc5434>), we need volunteers for the 
following tasks:
#/ Draft a statement of problem & scope
#/ List planned deliverables (incl. implementation, spec drafting), 
milestones and target WG (also identify any critical interdependencies)
#/ Identify and draft any necessary changes to WG charters, to cover the 
above deliverables
#/ Discuss with relevant WG chairs and ADs [see background below]
#/ Identify volunteers (pref before the BoF) planning to work on each 
deliverable

Some people have already volunteered in general to help with arranging 
the BoF, but we now need to get specific.

Let's get volunteers for the above priority tasks first, but for 
completeness I'll also list the formalities we have to do:
#/ Decide on name of BoF (and mailing list)
#/ BoF facilitators - chairs, scribes, etc
#/ Draft the BoF agenda, incl. time constraints
#/ Decide on the BoF questions
#/ Estimate attendance, list conflicts, decide duration
#/ Submit a formal request for the BoF via
      http://www.ietf.org/instructions/MTG-SLOTS.html and
      http://www.ietf.org/ietf/1bof-procedures.txt

I'll start off co-ordinating and chasing all the above, but contact me 
if you would like to take on the co-ordinating task.

*Background work so far**
*
The idea of this BoF has been floated with WG chairs and ADs for some 
time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked 
with the RMCAT chairs.
Also we have already done considerable work on defining the problem 
while writing various drafts and papers about L4S.

But, that was just a small group of co-authors (me, Koen, Inton, Olga). 
There's still a lot to do to build wider consensus.
We can go ahead with a BoF scheduling request even if disagreements on 
scope/problem remain.
But before the BoF itself, we need to have any such disagreements ironed 
out.

At the Buenos Aires Bar Bof, we put up a todo list of pieces that will 
need to be worked on:
See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf 
particularly slides 9 & 10
and the target WGs for each were:
* TSVWG (the L4S identifier)
* AQM (the AQM - the name gives the clue ;)
* TCPM (the DCTCP-like congestion control, covering SCTP)
* RMCAT (L4S variants of real-time congestion controls, or at least 
standardise existing controls using the identifier)

I believe, formally, each WG has to decide to charter additional work on 
its own ML.

[Since then, Ingemar has pointed out on this list that we also need to 
get AQM & ECN-marking in radio networks, and that will require working 
with/through other SDOs and/or developer groups that deal with the MAC 
layer .
V. important, but let's push that to a separate thread.]

Many of the pieces have their own rationale, independent of L4S. The 
idea of the BoF is to draw the bigger picture that motivates the work.
That doesn't preclude incremental work on the pieces for those who are 
not motivated by a big picture.

Cheers

Bob

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

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 18 May 2016 10:54:25 -0400

Hi Bob!

While I cannot be sure I will make it to Berlin this work is very pertinent to my current consuting/research; I could help with 1. reviewing 2. maybe suggestions and 5.

Marie-José
>> On May 18, 2016, at 7:47 AM, Bob Briscoe < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Folks,
>> 
>> At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) time-frame.
>> It was decided to initially use this ML, even tho the scope of L4S is wider than TCP Prague.
>> Consensus was to aim for a non-WG-forming BoF, to demonstrate willingness to work on the pieces in existing IETF WGs, and to co-ordinate approaches to each WG.
>> 
>> *2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area Directors at UTC 23:59. 
>> 
>> To organise a successful BoF (referring to rfc5434 <https://tools.ietf.org/html/rfc5434>), we need volunteers for the following tasks:
>> 1/ Draft a statement of problem & scope
>> 2/ List planned deliverables (incl. implementation, spec drafting), milestones and target WG (also identify any critical interdependencies)
>> 3/ Identify and draft any necessary changes to WG charters, to cover the above deliverables
>> 4/ Discuss with relevant WG chairs and ADs [see background below]
>> 5/ Identify volunteers (pref before the BoF) planning to work on each deliverable
>> 
>> Some people have already volunteered in general to help with arranging the BoF, but we now need to get specific.
>> 
>> Let's get volunteers for the above priority tasks first, but for completeness I'll also list the formalities we have to do:
>> a/ Decide on name of BoF (and mailing list)
>> b/ BoF facilitators - chairs, scribes, etc
>> c/ Draft the BoF agenda, incl. time constraints
>> d/ Decide on the BoF questions
>> e/ Estimate attendance, list conflicts, decide duration
>> f/ Submit a formal request for the BoF via 
>>      http://www.ietf.org/instructions/MTG-SLOTS.html <http://www.ietf.org/instructions/MTG-SLOTS.html> and
>>      http://www.ietf.org/ietf/1bof-procedures.txt <http://www.ietf.org/ietf/1bof-procedures.txt>
>> 
>> I'll start off co-ordinating and chasing all the above, but contact me if you would like to take on the co-ordinating task.
>> 
>> Background work so far
>> 
>> The idea of this BoF has been floated with WG chairs and ADs for some time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked with the RMCAT chairs.
>> Also we have already done considerable work on defining the problem while writing various drafts and papers about L4S.
>> 
>> But, that was just a small group of co-authors (me, Koen, Inton, Olga). There's still a lot to do to build wider consensus.
>> We can go ahead with a BoF scheduling request even if disagreements on scope/problem remain. 
>> But before the BoF itself, we need to have any such disagreements ironed out.
>> 
>> At the Buenos Aires Bar Bof, we put up a todo list of pieces that will need to be worked on:
>> See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf <http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf> particularly slides 9 & 10 
>> * RMCAT (L4S variants of real-time congestion controls, or at least standardise existing controls using the identifier)
>> 
>> I believe, formally, each WG has to decide to charter additional work on its own ML.
>> 
>> [Since then, Ingemar has pointed out on this list that we also need to get AQM & ECN-marking in radio networks, and that will require working with/through other SDOs and/or developer groups that deal with the MAC layer . 
>> Many of the pieces have their own rationale, independent of L4S. The idea of the BoF is to draw the bigger picture that motivates the work. 
>> That doesn't preclude incremental work on the pieces for those who are not motivated by a big picture.
>> 
>> Cheers
>> 
>> 
>> 
>> Bob
>> -- 
>> Bob Briscoe                               http://bobbriscoe.net/ <http://bobbriscoe.net/>_______________________________________________
>> tcpPrague mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tcpprague <https://www.ietf.org/mailman/listinfo/tcpprague>
>

---

From: John Leslie <[email-masked]>
Date: Wed, 18 May 2016 13:06:12 -0400

> co-ordinate approaches to each WG.

   I'm not sure we're all convinced this work _can_ be done by the existing
WGs -- if it can, I'm all for that.

> #/ Identify volunteers (pref before the BoF) planning to work on each 

   I'll volunteer for almost anything except going to Berlin...

--
John Leslie <[email-masked]>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 18 May 2016 21:22:19 +0200

Hi,

I am happy to help with #1, #2 and support you with any any of the 
formalities

Regards, marcelo

El 18/05/16 a las 13:47, Bob Briscoe escribió:
> Folks,
>
> At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in 
> Buenos Aires, there was support for a BoF about L4S, In the IETF-96 
> (Berlin) time-frame.
> #/ Identify and draft any necessary changes to WG charters, to cover 
> the above deliverables
> But, that was just a small group of co-authors (me, Koen, Inton, 
> Olga). There's still a lot to do to build wider consensus.
> Bob Briscoehttp://bobbriscoe.net/
>
>
> _______________________________________________
> tcpPrague mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpprague

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 19 May 2016 12:29:09 +0100

John,

> WGs -- if it can, I'm all for that.
I don't think it is such a problem for AQM and tsvwg.

The biggest question-mark is over tcpm. One of the reasons for showing 
the full list of possible work (even tho some isn't even started) is to:
* expose the potential load on tcpm {Note 1}
* enable discussion on whether the phrase "minor" in tcpm's charter 
would need to be nuanced to encompass minor changes that have major effects

{Note 1} Some of the deliverables would be brought to tcpm anyway, 
because they are important for all TCP-derived congestion controls, not 
just "TCP Prague".
For instance, the following two RTT-related items are particularly 
important for L4S/"TCP Prague", but they are also important updates to 
the base TCP cc [RFC5681] too.
3-4) Scaling TCP's Congestion Window for Small Round Trip Times
3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence

>     I'll volunteer for almost anything except going to Berlin...
Thanks. Can you be more specific? One thing you might immediately be 
able to help with: advice on formal procedure...

Normally, a WG-forming BOF proposes a charter.
Is it appropriate for a BoF to propose a co-ordinated set of charter 
deltas across multiple existing WGs?
Or would it be more normal/polite/effective to propose/agree those 
changes in each WG?
Or would the best approach be to propose the changes in the BoF, then 
discuss/agree each change in each WG as well?

(I already understand that the IESG formally approves any charter changes.)

Cheers

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 19 May 2016 12:43:10 +0100

Marcelo,

Thanks for the offers.

I didn't say what I myself would volunteer for:
#1 I'd be happy to work with you and Koen (and others) on a problem 
statement - this is always tough, and I believe we've nailed the problem 
better through writing the existing drafts and a few papers on L4S.
#2 Deliverables list : Already in progress (see "Subject: Draft L4S 
Deliverables List")
#5 List volunteers for deliverables : Already in progress (see "Subject: 
Draft L4S Deliverables List")

I could do the following but only if no-one else volunteers:
      #3 Changes to charters: (but I'm more than happy for others to 
take this on)
      #4 As I said, I started this, but I'm happy for others to adopt a 
WG each.

Bob

On 18/05/16 20:22, marcelo bagnulo braun wrote:
>> 2/ List planned deliverables (incl. implementation, spec drafting), 
>> Some people have already volunteered in general to help with 
>> arranging the BoF, but we now need to get specific.
>>
>> I'll start off co-ordinating and chasing all the above, but contact 
>> me if you would like to take on the co-ordinating task.
>>
>> [Since then, Ingemar has pointed out on this list that we also need 
>> to get AQM & ECN-marking in radio networks, and that will require 
>> working with/through other SDOs and/or developer groups that deal 
>> with the MAC layer .

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 19 May 2016 12:54:41 +0000

> The biggest question-mark is over tcpm. One of the reasons for showing the full list of possible work (even tho some isn't even started) is to:
> * enable discussion on whether the phrase "minor" in tcpm's charter would need to be nuanced to encompass minor changes that have major effects

> {Note 1} Some of the deliverables would be brought to tcpm anyway, because they are important for all TCP-derived congestion controls, not just "TCP Prague".
> For instance, the following two RTT-related items are particularly important for L4S/"TCP Prague", but they are also important updates to the base TCP cc [RFC5681] too.

Before speculating too much about the TCPM charter, I believe that running code and (realistic) experimentation would be an important starting point.

Michael (as individual contributor)

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 19 May 2016 18:11:21 +0200

Hi Bob, hi all,

 > discuss/agree each change in each WG as well?

You don't need a charter for a non-wg-forming BoF (which anyway wouldn't make 
sense). However, you should have a description of the BoF (which clearly lays 
out the goals of the BoF/discussion that is expected at the BoF) to provide 
the needed information to request a BoF, see

https://www.ietf.org/wg/bof-procedures.html

I can also recommend to add your BoF information to the BoF wiki page:

https://tools.ietf.org/bof/trac/

Template is given here:

https://tools.ietf.org/bof/trac/wiki/BofExample

Regarding any charter changes in other groups: these have the be discussed 
and decided in the respective group. I don't think it's helpful to come up 
with any text now, or even discuss this text during the BoF.

Hope that helps!
Mirja

---

From: John Leslie <[email-masked]>
Date: Thu, 19 May 2016 12:48:32 -0400

Mirja K??hlewind <[email-masked]> wrote:
> 
> You don't need a charter for a non-wg-forming BoF (which anyway wouldn't 
> make sense). However, you should have a description of the BoF (which 
> clearly lays out the goals of the BoF/discussion that is expected at the 
> BoF) to provide the needed information to request a BoF, see
> 

   I entirely agree with Mirja (though I don't warrantee the rest of the IESG
does).

   I think it's worth adding what Mirja posted to the AQM list:
] 
] AQM will have a recharter discussion at the next meeting which might lead to
] rechartering or closure. If the wg will continue, moving this doc forward
] might be one of their work items. Otherwise there are currently no plans.
] Even though there are implementations of PIE in the wild, the working did
] not have consensus to publish this doc as ST now, as these implementation 
] are currently mostly used in home devices and not the Internet itself.

   So... if we imagine dual-queue work being carried out in AQM, we really
ought to reach agreement with the current AQM chairs, and be prepared to help
them with a rechartering proposal.

   If we wish to ensure our BoF comes before, or after, the AQM rechartering
discussion, we need to beg Mirja to ensure that ordering, since such ordering
is not part of the standard BoF-scheduling process, and swaps tend to happen
as the process proceeds.

   OTOH, we could discuss that work in our BoF, stating that we'd be happy to
see it become part of an AQM rechartering...

   IMHO, it would be more ordinary to discuss chartering such work within
dual-queue (and be prepared to ask that it be part of our charter; again
stating we're happy to see the work take place in AQM).

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 19 May 2016 18:57:42 +0200

Hi John, hi all,

As far as I know, dual-q has been presented at an aqm meeting and in any case the dual-q draft is an aqm draft (draft-briscoe-aqm-dualq-coupled). So for sure the aqm wg is aware that this draft exists and I would assume that this draft will be part of the re-charter discussion. However, even if the group is interested in this work, it could still be possible that it is not worth having a whole wg basically for just one document (not saying that will be the case). However, even in this case this work could also be continued by other groups in transport. 

While knowing about the recharter effort of aqm is for sure good input for the discussion in this potentially BoF, I think we can keep those two efforts separate.

Mirja

> Am 19.05.2016 um 18:48 schrieb John Leslie <[email-masked]>:
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 19 May 2016 18:55:04 +0100

Juts in case anyone is unfamiliar, I'd add that area working groups  (in 
this TSVWG) tend to pick-up work that the AD assigns them, as well as 
their core work items.

So, I'd encourage people to work out what they want to do and why this 
is needed, who will implement what is proposed,  etc -  I'm sure the 
work can be found an appropriate home if the IETF decides to proceed 
with this:-).

Gorry

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 19 May 2016 20:03:25 +0100

Michael,

Over the coming days / weeks, we will try to expose the vast numbers of 
experiments that have been done. And on real broadband equipment, in 
realistic traffic settings, etc. (the realism being for you to judge, 
not me)

Regarding running code, often at the time when a 'typical' BoF is held, 
there is some example or initial code, but not code for every proposed 
milestone. We are much further ahead than just initial code. But most of 
the "TCP Prague" safety aspects are still only a list of desires, not code.

To ensure I understand your concern,...
I assume even tho your email is as an individual, you are focusing on 
those aspects relevant to tcpm, which are all those safety points - 
mostly not implemented.
Or are you questioning the adequacy of the AQM code, the DCTCP code etc?

The problem here is that, if we were proposing a new WG, it would be 
normal to create a charter with a list of milestones, many of which 
would not have even been thought about in detail, let alone implemented. 
Milestones might be requirements documents, not protocol specs at that 
stage.

Nonetheless, because we are proposing to work across existing WGs, I 
accept we have to adapt to the norms of each WG. Nonetheless, even in 
TCPM, it is possible to start some work with a requirements doc, rather 
than a fully-tested implementation.

Also, part of this discussion is about whether WG norms need to be 
stretched to accommodate L4S work. Or whether a new WG is needed. For 
instance, when we discussed how to take L4S forward with the ADs (and a 
few very relevant WG chairs who happened to be in the Transport AD 
Office hours at the time), there was v strong consensus that we should 
avoid going off into an L4S huddle in a separate WG. And one of the ADs 
said we might have to consider widening the definition of "minor 
extensions" in TCPM's charter as a consequence.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 19 May 2016 20:12:42 +0100

Mirja, John, [and thanks for pointing out the role of the area WG, Gorry]

Going back to your point about scheduling the order of re-chartering 
discussion meetings in Berlin.
We don't have to wait for the f2f meeting to discuss re-chartering aqm 
(or any of the WGs potentially affected by L4S work).
We can start now on the relevant MLs, so the f2f mtgs become a 
coordination checkpoint for the discussions, like they should be.

But in general, it might be useful to have the L4S BoF (if approved) 
early in the week, so that discussions specific to each WG can be held 
with the largest number of people aware of the wider context of the 
discussion.

Bob

On 19/05/16 18:55, Gorry Fairhurst wrote:
> Juts in case anyone is unfamiliar, I'd add that area working groups 
> (in this TSVWG) tend to pick-up work that the AD assigns them, as well 
> as their core work items.
>
>> As far as I know, dual-q has been presented at an aqm meeting and in 
>> any case the dual-q draft is an aqm draft 
>> (draft-briscoe-aqm-dualq-coupled). So for sure the aqm wg is aware 
>> that this draft exists and I would assume that this draft will be 
>> part of the re-charter discussion. However, even if the group is 
>> interested in this work, it could still be possible that it is not 
>> worth having a whole wg basically for just one document (not saying 
>> that will be the case). However, even in this case this work could 
>> also be continued by other groups in transport.
>>
>> While knowing about the recharter effort of aqm is for sure good 
>> input for the discussion in this potentially BoF, I think we can keep 
>> those two efforts separate.
>>
>> Mirja
>>
>>
>>

---

From: John Leslie <[email-masked]>
Date: Sat, 21 May 2016 19:31:47 -0400

It's time for me to reply to the list here...

Bob Briscoe <[email-masked]> wrote:
>> I'm not sure we're all convinced this work _can_ be done by the 
>> existing WGs -- if it can, I'm all for that.

   Actually, _I'm_ not convinced that it'll work for us to spread
the work around. :^(

> I don't think it is such a problem for AQM and tsvwg.

   I'd be more convinced if I heard this from the AQM and TSVWG chairs.

>   would need to be nuanced to encompass minor changes that have major

   IMHO, TCPM has been the place for ongoing work on TCP which isn't
expected to raise anybody's hackles. Once anybody sees it as "major",
a different process is invoked. I don't think we'll get away with saying
the changes are "minor" if they require "fundamental" changes to TCP.

> 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence

   This is almost off-topic. :^(

   The "small round-trip times" issue is pretty fundamental: TCP _doesn't_
reduce its congestion window below 2 (packets); so with enough classic-TCP
senders, no AQM can possibly hold latency low. Bob has proposed a change;
but it's a change to _every_ classic TCP sender. Myself, I'd rather not
worry about this just yet...

   RTT-dependence is an inseparable part of TCP-as-we-know-it. I'd _much_
rather not tilt at that windmill quite yet...

> Normally, a WG-forming BOF proposes a charter.

   Yes, but that's not essential. See

   A Description and Agenda are required. A charter _may_ be discussed,
but it's normal to leave this to a second BoF or hash out some details
and propose it to the community.

   The _main_ purpose of a BoF is to have a "brief" discussion to see
whether there's enough interest to justify forming a WG.

   The IESG is becoming a bit nervous about (formal) BoFs that don't
propose to form a WG. Informal BoFs are fine; but formal scheduled
BoFs are designed for deciding whether to form a WG.

> deltas across multiple existing WGs?

   No.

> Or would it be more normal/polite/effective to propose/agree those 

   It is considered _necessary_ to discuss those in each WG. (It's OK
to ask the WGCs involved for advice about how to discuss that.)

> discuss/agree each change in each WG as well?

   The IESG certainly wouldn't recommend that. It's entirely too easy
for discussion to get hung up on details.

> (I already understand that the IESG formally approves any charter

   Formally, yes; in fact, these are not discussed much on IESG telechats.

> Cheers

   I mean to post some advice on a better way to proceed; but this seems
enough for one email...

---

From: John Leslie <[email-masked]>
Date: Sat, 21 May 2016 19:55:39 -0400

(not that I in any way disagree; this seems like the best starting
point for what I believe we should discuss:)

Mirja K??hlewind <[email-masked]> wrote:
> BoF)

   It seems to me that we have two really-fundamental items:

1) How to relax the requirement that ECN-marking results in the "same"
   reaction as a drop; and

2) How to deprecate ECN-nonce, which encourages seemingly-random switching
   between ECT-0 and ECT-1.

   I don't believe it appropriate to try to change either of these in an
Experimental status document. (And I think we'll get in trouble if we try.)

   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'd like to see a new WG chartered to oversee the appropriate experiments.
This really doesn't fit any existing WG on Bob's list; and IMHO it's the
easiest path to gain widespread support. (Or do any of you disagree that
a lot of folks would like to _do_something_ about latency?)

   As for the particulars of L4S, I like it: but that doesn't mean that
_everybody_ will like it. To tell truth, it's a bit hard to understand...

   The question of how to proceed with the L4S experiment remains open;
and I would see no problem in evaluating it under the WG to be formed.
If we want to put that in our charter, I won't object; but I really don't
want to get hung-up on those details before we get authorization to
respond differently to ECN marking and some assurance that we can treat
ECT-0 and ECT-1 differently.

   If we go this path, we can spend the BoF justifying the efforts to
free up ECT-0 and ECT-1 without having to argue details during the BoF.

---

From: Michael Welzl <[email-masked]>
Date: Sun, 22 May 2016 12:17:29 +0200

Hi all,

Just one comment:

(snip)

> rather not tilt at that windmill quite yet…

So here’s the +1.  I can’t see how it helps this work if we discuss all the possible problems of the world and how it can possibly solve them.
Opening many cans of various worms - wouldn’t it be better to keep things more focused?

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Sun, 22 May 2016 13:08:56 +0200

[adding the co-authors of the ABE draft]

All,

My thoughts regarding the two items that John mentions below:

To 1)  =>  the problematic statements from RFC3168 are on the third slide here:
https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-13.pdf
(sorry for forgetting to use slide numbers!)

They talk about “the indication of congestion” and "the receipt by an ECN-Capable transport of a single CE packet”.
The receiver gets this signal, but the congestion reaction happens at the sender - so these sentences assume the feedback mechanism described in the same document.
It seems strange to me to have to update these sentence (regarding how congestion control mechanisms should react) for the purpose of L4S, which relies on an entirely different feedback mechanism; reacting exactly as if there would have been loss in response to an accurate ECN signal is just completely weird.

Rather, in the proposed update that we’re planning to do for the sake of ABE (which assumes “normal” RFC3168-style feedback), we should probably talk about the ECE mechanism "described in this document” or something like that - and the L4S work should be able to (rightfully) assume that the reaction in response to accurate ECN simply isn’t defined yet.

To 2) => Procedurally, I just wonder, is it really necessary to “deprecate” (replace?) an Experimental RFC?   As for the technical side of it, we could just require the L4S work to discuss the case of a lying receiver in the Security Considerations section - there could be various possibilities for dealing with that, I’d assume…  (e.g. monitoring the feedback after giving an ECN indication, in case of symmetric paths) - I think Bob had other arguments; either way I don’t see a huge issue here.

Cheers,
Michael

> On 22. mai 2016, at 01.55, John Leslie <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Sun, 22 May 2016 17:45:09 +0100

See some comments below on these topics.

> They talk about “the indication of congestion” and "the receipt by an
> ECN-Capable transport of a single CE packet”.
> The receiver gets this signal, but the congestion reaction happens at the
> sender - so these sentences assume the feedback mechanism described in the
> same document.
>
> It seems strange to me to have to update these sentence (regarding how
> congestion control mechanisms should react) for the purpose of L4S, which
> relies on an entirely different feedback mechanism; reacting exactly as if
> there would have been loss in response to an accurate ECN signal is just
> completely weird.
>
> Rather, in the proposed update that we’re planning to do for the sake of
> ABE (which assumes “normal” RFC3168-style feedback), we should
> probably talk about the ECE mechanism "described in this document” or
> something like that - and the L4S work should be able to (rightfully)
> assume that the reaction in response to accurate ECN simply isn’t
> defined yet.
>
I was assuming that this also was a likely way forward.
>
> To 2) => Procedurally, I just wonder, is it really necessary to
> “deprecate” (replace?) an Experimental RFC?   As for the technical
> side of it, we could just require the L4S work to discuss the case of a
> lying receiver in the Security Considerations section - there could be
> various possibilities for dealing with that, I’d assume…  (e.g.
> monitoring the feedback after giving an ECN indication, in case of
> symmetric paths) - I think Bob had other arguments; either way I don’t
> see a huge issue here.
>
> Cheers,
> Michael
>
It would be fine to declare one experiment finished and to start a new
one: In that sense, if the WH sees a strong consensus that the IETF no
longer needs an Experimental Spec, and that this no longer should be
deployed, it can be replaced by a new RFC.  In this case RFC 3540 is from
TSVWG, so whoever wishes to discuss this should make the presentation
there.

I'm curious also to see which method the IETF will recommend to solve the
problem(s) that ECN-Nonce attempted to solve.

Gorry

---

From: John Leslie <[email-masked]>
Date: Sun, 22 May 2016 15:17:00 -0400

Michael Welzl <[email-masked]> wrote:
>> rather not tilt at that windmill quite yet???
> 
> So here???s the +1.  I can???t see how it helps this work if we discuss
> all the possible problems of the world and how it can possibly solve them.

   That's a trifle unfair to Bob: he included a bunch of things which
are actually prerequsites to L4S working well.

   I don't disagree with Bob that these are important: I merely don't
want to tie ourselves in knots trying to solve them at the outset.

> Opening many cans of various worms - wouldn???t it be better to keep
> things more focused?

   Exactly!

   I listed the things I think are necessary to show sufficient results
to get folks believing the goal is worth the effort. I'd like to concentrate
our efforts there; and get around-to the other details after we can show
some big-I-Internet results.

---

From: Michael Welzl <[email-masked]>
Date: Sun, 22 May 2016 21:25:31 +0200

> On 22. mai 2016, at 21.17, John Leslie <[email-masked]> wrote:
> 
>   That's a trifle unfair to Bob:

Wasn’t the intention => au contraire…

> he included a bunch of things which

… that was my point.

Cheers,
MIchael

---

From: John Leslie <[email-masked]>
Date: Sun, 22 May 2016 15:47:18 -0400

NB: I take 1) to mean:

>>   reaction as a drop;

> They talk about ???the indication of congestion??? and "the receipt by
> an ECN-Capable transport of a single CE packet???.
> The receiver gets this signal, but the congestion reaction happens at
> the sender - so these sentences assume the feedback mechanism described
> in the same document.

   More exactly, they assume some magical process, which _may_ be the
feedback mechanism in the same document...

> congestion control mechanisms should react) for the purpose of L4S,
> which relies on an entirely different feedback mechanism; reacting
> exactly as if there would have been loss in response to an accurate
> ECN signal is just completely weird.

   My concern is to get warnings where the folks which have to implement
things will see them. "Same-as" has found its way into enough documents
that the implementation of deprecating it is non-trivial. I don't want
to discuss all those details (if we can avoid it); but I think we need
to get the warning-labels out there.

> Rather, in the proposed update that we???re planning to do for the
> sake of ABE (which assumes ???normal??? RFC3168-style feedback), we
> should probably talk about the ECE mechanism "described in this
> document??? or something like that - and the L4S work should be able
> to (rightfully) assume that the reaction in response to accurate ECN
> simply isn???t defined yet.

   We mustn't assume that all implementors read all RFCs.

   Accurate-ECN _is_ essential to L4S working as intended; but what
reason is there for folks designing the next generation of cable-modem
to read and understand it?

   We need to find a way to ensure that folks designing such boxes
understand it _does_ matter whether packets are dropped instead of
ECE-marked; and that reasonable active-queue-management will desire
different marking rules for ECT-1 packets vs. ECT-0 packets.

   I proposed a design-for-experiments document updating enough RFCs
as a way to accomplish this: no doubt there are other ways; but we're
ill-advised to say, "Well, they _should_ have known!"

> ???deprecate??? (replace?) an Experimental RFC?

   IMHO, yes.

   I recognize there are many Experimental documents out there that have
never been deprecated; nor have they resulted in a "Results of Experiment"
documents. This leads to confusion which could have been easily avoided.

   In this particular case, we have gotten a bunch of additional documents
saying "This is how to support ECN-nonce," giving no hints that ECN-nonce
was intended as an Experiment which should long since have been concluded.
IMHO, we do need such a formal statement, and it should "update" the list
of RFCs which show "how to support"

   I suppose YMMV; but I wish you'd come up with some way for implementors
to learn that ECN-nonce is dead.

> As for the technical side of it, we could just require the L4S work to
> discuss the case of a lying receiver in the Security Considerations
> section - there could be various possibilities for dealing with that,
> I???d assume???  (e.g. monitoring the feedback after giving an ECN
> indication, in case of symmetric paths) - I think Bob had other
> arguments; either way I don???t see a huge issue here.

   I'd be happy to see such Security Considerations; but it really won't
substitute for a warning label (that ECN-nonce can't accomplish this).

---

From: John Leslie <[email-masked]>
Date: Sun, 22 May 2016 15:54:21 -0400

[email-masked] <[email-masked]> wrote:
>... 
>> ???deprecate??? (replace?) an Experimental RFC?   As for the technical
>> various possibilities for dealing with that, I???d assume???  (e.g.
>> symmetric paths) - I think Bob had other arguments; either way I don???t
>> see a huge issue here.
>>
>> Cheers,
>> Michael
> 
> deployed, it can be replaced by a new RFC.

   That is certainly one way: I'm happy to defer to Mirja whether it is
the best way...

> problem(s) that ECN-Nonce attempted to solve.

   Bob has mentioned several: I'd rather not _start_ that discussion myself.

   (We've avoided solving that for rather a few years so far: IMHO it's
not our highest priority.)

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 23 May 2016 12:47:35 +0100

On 22/05/2016 20:54, John Leslie wrote:
>> one: In that sense, if the WG sees a strong consensus that the IETF no

It's Spencer (he's the TSVWG AD).

> not our highest priority.)
I am aware of the proposals.

Gorry

---

From: "De Schepper, Koen (Nokia - BE)" <[email-masked]>
Date: Mon, 23 May 2016 13:28:17 +0000

Hi all,

Just wanted to clarify that I see the TCP-Prague requirements primarily applicable for L4S. 

"Maybe some" also make sense to apply to classic tcp, but for me this is not the main goal and often not possible anymore. Classic TCP works well (except for low latency) if we configure a big enough Q in the network. The problems start appearing if the queues get reduced.

Related to the RTT-(in)dependence, if an AQM is targeting a delay of 100ms, a flow with 100ms base RTT can still compete reasonably (twice less throughput) with a flow of 1ms base RTT. 

If you set the AQM to 20ms, the 100ms flow will get 6 times less throughput than the 1ms flow, or seen otherwise you can support reasonable competition for flows up to 20ms base RTT.

If the AQM is set to 5ms, you might consider FQ_* to solve the RTT unfairness, as otherwise your 100ms flow gets almost 20 times less throughput.

But if you target sub millisecond queues as for TCP-Prague, I think we should solve the issue in the end-system (end-2-end principle). We would face up to 100 times less throughput for 100ms flows competing with 1ms flows. As we are defining a new service, we should do this from the beginning, and not end up in a deadlock situation as we are with classic tcp. 

So I agree also that this is not possible to change for classic TCP, but I think we should for TCP-Prague.

Same for minimum 2 segments, which guarantees that at least 2 packets can be sent per RTT for Classic 100ms flows (at least if ECN is used, or the drop probability is not too high (if the queues are not too small)). So for TCP-Prague, I prefer we don't have standing queues which can't be reduced (except with drop).

Regards,
Koen.

> -----Original Message-----
> From: tcpPrague [mailto:[email-masked]] On Behalf Of Michael
> Welzl
> Sent: zondag 22 mei 2016 12:17
> To: John Leslie
> Cc: Bob Briscoe; TCP Prague List
> Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal
> cut-off approaching
> 
> Hi all,
> 
> Just one comment:
> 
> (snip)
> 
> So here’s the +1.  I can’t see how it helps this work if we discuss all
> the possible problems of the world and how it can possibly solve them.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 23 May 2016 09:13:10 -0500

Hi, all,

> It's Spencer (he's the TSVWG AD).

True.

I should also mention that Mirja and I talk ;-)

Spencer