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>