Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching
marcelo bagnulo braun <marcelo@it.uc3m.es> Wed, 18 May 2016 19:22 UTC
Return-Path: <marcelo@it.uc3m.es>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EFE12D648 for <tcpprague@ietfa.amsl.com>; Wed, 18 May 2016 12:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.83
X-Spam-Level:
X-Spam-Status: No, score=-101.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wgQguM5ZMih for <tcpprague@ietfa.amsl.com>; Wed, 18 May 2016 12:22:03 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E1712D13B for <tcpprague@ietf.org>; Wed, 18 May 2016 12:22:03 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id n129so199642718wmn.1 for <tcpprague@ietf.org>; Wed, 18 May 2016 12:22:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Qot+bgPw1PnumcrHJgukEfRBiKTOGfo2d5uYIE8FhOw=; b=OeCT5N+es5D6eqbwUjVd/c+9IzCEroFprjiYM9Tap3gcWbTQiBIzE3JOWuyYbpITe6 hC0bNHo8zA8PE2hZ8P3lfutvKu+7dl79kQ9MwvMBEALTmajKnrC62S278qzcNeQZArZ2 1rAxMIx95nTdiReZ+p11yukLiG66ewOmCVuWcK1imksHpXMWu2l3UH5mC8P+9qrwMMAE OvWK0GXN06CBwxxakNydMcvfxytT+ro01N14GJyi6eFBdRJhh8x4i9jLo2+UwUZYd1ky rcW3C9g99Vfjg4/GvVPpgX5dN0RqVpWou6XuErbVX2V4ynilyjYXyqulTQSruqdX02De seVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Qot+bgPw1PnumcrHJgukEfRBiKTOGfo2d5uYIE8FhOw=; b=ZMkdiQJ+ug1KzU1PPhb6aRw8asNmVfiaXKWlK/WXWe/5oCEr/ltTNinh5Vo26gf+4U npA3tUJyArtMH95I+vybpbK5r1qwSSKfXy5Pgflf8V2OIK/jgIpji4daqtWVjy20jndv 8E/YuS2OP9agzLtuzamCqWPWHLHqGLl1il1kt/8bWVqZBRJScDJUEB3eHMdvnbTzGGgd CC/OGav3taA0ASVZds7HMTgSrQBgOVFqpAVQa263fjUcUhYXNldxesyPuXVNvVLmHV4v 9Ymk+Gi9sVfn6TvTF9xB7Xg7iZl0LVi0Gsh+rnzLHypnpxv3EMFsQCJv/beAGcf4esvB ci8Q==
X-Gm-Message-State: AOPr4FVDBOvi/Z4UH4d1ybazuvGaEXkqKV52MPMwxlwD42sGbNHyIQhrX0eCX0iioQ7o9atr
X-Received: by 10.194.173.161 with SMTP id bl1mr9188022wjc.11.1463599321312; Wed, 18 May 2016 12:22:01 -0700 (PDT)
Received: from Macintosh-6.local (pa2-84-91-102-82.netvisao.pt. [84.91.102.82]) by smtp.gmail.com with ESMTPSA id y3sm10192501wji.40.2016.05.18.12.22.00 for <tcpprague@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 12:22:00 -0700 (PDT)
To: tcpprague@ietf.org
References: <573C564E.1090201@bobbriscoe.net>
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Message-ID: <573CC0EB.6060306@it.uc3m.es>
Date: Wed, 18 May 2016 21:22:19 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <573C564E.1090201@bobbriscoe.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpprague/KaSQn4gYUsX6CnxeiNBnXagoAgM>
Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 May 2016 19:22:05 -0000
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. > 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/ > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague
- [tcpPrague] Volunteers pls: L4S non-WG-forming Bo… Bob Briscoe
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Marie-Jose Montpetit
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… marcelo bagnulo braun
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… John Leslie
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Bob Briscoe
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Bob Briscoe
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Scharf, Michael (Nokia - DE)
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Mirja Kühlewind
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… John Leslie
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Mirja Kühlewind
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Gorry Fairhurst
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Bob Briscoe
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Bob Briscoe
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… John Leslie
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… John Leslie
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Michael Welzl
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Michael Welzl
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… gorry
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… John Leslie
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Michael Welzl
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… John Leslie
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… John Leslie
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Gorry Fairhurst
- Re: [tcpPrague] RTT-(in)dependent throughput De Schepper, Koen (Nokia - BE)
- Re: [tcpPrague] Volunteers pls: L4S non-WG-formin… Spencer Dawkins at IETF