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