Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching
John Leslie <john@jlc.net> Sat, 21 May 2016 23:31 UTC
Return-Path: <john@jlc.net>
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 A6BC412D584 for <tcpprague@ietfa.amsl.com>; Sat, 21 May 2016 16:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.026
X-Spam-Level:
X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 CDiDIYB6Z6jI for <tcpprague@ietfa.amsl.com>; Sat, 21 May 2016 16:31:53 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 744A712D539 for <tcpPrague@ietf.org>; Sat, 21 May 2016 16:31:53 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 9492DC9419; Sat, 21 May 2016 19:31:47 -0400 (EDT)
Date: Sat, 21 May 2016 19:31:47 -0400
From: John Leslie <john@jlc.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <20160521233147.GA6947@verdi>
References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <573DA385.8020703@bobbriscoe.net>
User-Agent: Mutt/1.4.1i
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpprague/gELWqlQMjm7w-8y9Wsg73qaux9A>
Cc: TCP Prague List <tcpPrague@ietf.org>
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: Sat, 21 May 2016 23:31:55 -0000
It's time for me to reply to the list here... Bob Briscoe <ietf@bobbriscoe.net> wrote: > On 18/05/16 18:06, John Leslie wrote: >> Bob Briscoe <ietf@bobbriscoe.net> wrote: >> >>> 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. >> 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. > 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 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. > {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 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 https://www.ietf.org/wg/bof-procedures.html 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. > Is it appropriate for a BoF to propose a co-ordinated set of charter > deltas across multiple existing WGs? No. > Or would it be more normal/polite/effective to propose/agree those > changes in each WG? 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.) > Or would the best approach be to propose the changes in the BoF, then > 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 > changes.) 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... -- John Leslie <john@jlc.net>
- [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