Multiple IETF Transport mailing lists.
This is to announce that discussions are proceeding on the
[email protected] 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 protected]>
To: TCP Prague List <[email protected]>
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/
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
