Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching

John Leslie <john@jlc.net> Sun, 22 May 2016 19:17 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 67BDB12D55D for <tcpprague@ietfa.amsl.com>; Sun, 22 May 2016 12:17:07 -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 gxkX1qSj25fR for <tcpprague@ietfa.amsl.com>; Sun, 22 May 2016 12:17:06 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id EF84312D0A6 for <tcpPrague@ietf.org>; Sun, 22 May 2016 12:17:05 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 62487C941D; Sun, 22 May 2016 15:17:00 -0400 (EDT)
Date: Sun, 22 May 2016 15:17:00 -0400
From: John Leslie <john@jlc.net>
To: Michael Welzl <michawe@ifi.uio.no>
Message-ID: <20160522191700.GA8413@verdi>
References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <20160521233147.GA6947@verdi> <9C86240F-3E2B-4534-9140-48D8286176A7@ifi.uio.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9C86240F-3E2B-4534-9140-48D8286176A7@ifi.uio.no>
User-Agent: Mutt/1.4.1i
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpprague/sYnWwX8LCa0eVgd8DmMLncwj0FY>
Cc: Bob Briscoe <ietf@bobbriscoe.net>, 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: Sun, 22 May 2016 19:17:07 -0000

Michael Welzl <michawe@ifi.uio.no> wrote:
> (snip)
> 
>>> {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???
> 
> So here???s the +1.  I can???t see how it helps this work if we discuss
> all the possible problems of the world and how it can possibly solve them.

   That's a trifle unfair to Bob: he included a bunch of things which
are actually prerequsites to L4S working well.

   I don't disagree with Bob that these are important: I merely don't
want to tie ourselves in knots trying to solve them at the outset.

> Opening many cans of various worms - wouldn???t it be better to keep
> things more focused?

   Exactly!

   I listed the things I think are necessary to show sufficient results
to get folks believing the goal is worth the effort. I'd like to concentrate
our efforts there; and get around-to the other details after we can show
some big-I-Internet results.

--
John Leslie <john@jlc.net>