Subject: [iccrg] Fwd: L4S/DualQ BoF-forming on tcpprague list: pls air your concerns

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

ICCRG folks,

I just realised I omitted the iccrg list from the distribution of the 
mail below.

Bob

-------- Forwarded Message --------
Subject: 	L4S/DualQ BoF-forming on tcpprague list: pls air your concerns
Date: 	Thu, 19 May 2016 19:29:37 +0100
From: 	Bob Briscoe <[email-masked]>
To: 	tsv-area IETF list <[email-masked]>, AQM IETF list 
<[email-masked]>, tcpm IETF list <[email-masked]>, tsvwg IETF list 
<[email-masked]>, [email-masked] <[email-masked]>
CC: 	TCP Prague List <[email-masked]>

Multiple IETF Transport mailing lists.

This is to announce that discussions are proceeding on the 
[email-masked] list [see archive 
<https://www.ietf.org/mailman/listinfo/tcpprague>] about organising a 
BoF on Low Latency Low Loss Scalable throughput (L4S) service, for the 
IETF-96 Berlin timeframe.
The proposed L4S BoF will be about the full implications of L4S - on 
ECN, SCTP, RMCAT, AQM, etc. Despite the name of the mailing list, it is 
not just about so-called "TCP Prague" and its implications solely on TCP.

If you reply to this announcement, please cut all the mailing lists from 
the distr except tcpprague.

Anyone who is sceptical of the L4S approach, or its safety for the 
public Internet, please air your concerns. Ideally now on the tcpprague 
list, but certainly at or preferably before the proposed BoF in Berlin.
If you prefer to air your concerns on your favourite WG mailing list, 
pls at least ensure the tcpprague list is aware.

You may know L4S as the DualQ Coupled AQM. Background info on L4S 
including I-Ds, code, videos, etc. can be found here:
https://riteproject.eu/dctth/

Cheers

Bob

>
> -------- Forwarded Message --------
> Subject: 	Volunteers pls: L4S non-WG-forming BoF proposal cut-off 
> approaching
> Date: 	Wed, 18 May 2016 12:47:26 +0100
> From: 	Bob Briscoe <[email-masked]>
> To: 	TCP Prague List <[email-masked]>
>
>
>
> 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 Briscoehttp://bobbriscoe.net/