[tcpPrague] Too fast for Google?
Bob Briscoe <ietf@bobbriscoe.net> Thu, 02 June 2016 16:03 UTC
Return-Path: <ietf@bobbriscoe.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 4021A12D7F3 for <tcpprague@ietfa.amsl.com>; Thu, 2 Jun 2016 09:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 a0aVVb-kw3_c for <tcpprague@ietfa.amsl.com>; Thu, 2 Jun 2016 09:03:50 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465C612D7A8 for <tcpPrague@ietf.org>; Thu, 2 Jun 2016 09:02:58 -0700 (PDT)
Received: from [31.185.187.76] (port=47485 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <ietf@bobbriscoe.net>) id 1b8V5D-0002WC-Ps; Thu, 02 Jun 2016 17:02:56 +0100
To: Jana Iyengar <jri@google.com>, iccrg IRTF list <iccrg@irtf.org>
References: <574EBEA2.8080705@bobbriscoe.net>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <575058AE.1020001@bobbriscoe.net>
Date: Thu, 02 Jun 2016 17:02:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <574EBEA2.8080705@bobbriscoe.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpprague/ZXyNxpblrFsPGMqyDEnHzqkIgl0>
Cc: TCP Prague List <tcpPrague@ietf.org>
Subject: [tcpPrague] Too fast for Google?
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: Thu, 02 Jun 2016 16:03:52 -0000
Jana, When we held the L4S Bar BoF in Buenos Aires, you said we were moving too fast. I think the sentiment behind your point was that we seemed to be shutting out similar approaches too fast. Can you clarify if that's what you meant? If yes, I'd be interested to know if this impression came from the presentations or the drafts. Because: * in the drafts, we've specified example design(s) in appendices, and in the normative body text, we've distilled only the essential structure of the approach as normative standards statements. * in presentations, I (at least) have a tendency to want to be concrete - to demonstrate that there is real code and equipment and tests, etc. I'd also be interested to hear if you think we have been successful in generalising the drafts, or whether you think they are still too specific. In particular, you mentioned making space for delay-based congestion control, which I would /not/ want to include for the reasons below. Is there any rationale for being /that/ general? Background: L4S aims for a very shallow queue, which we indicate with immediate ECN notification (the L4S demo used a 5-MTU threshold when there is no traffic in the classic queue). ECN gives much more precision, and immediately. Rather than waiting for enough packets to get an imprecise delay-measurement heuristic. (for instance the sender can dither packet inter-arrival time during flow-start to sense available capacity, which it can then approach very rapidly without overshoot.) This is what I meant when I said we have created an "incrementally deployable clean-slate"... There is a brief window of opportunity during which we (ie. you, everyone) can all jiggle both host and AQM together. But it will have to be standardised soon, then it will ossify. We can't wait too long, otherwise everyone loses interest. Seriously, I first presented the idea of deploying DCTCP on the Internet in the same session as Van Jacobson introduced CoDel (Jul 2012). We published the main drafts on L4S in Jul 2015, so I think it's reasonable to expect to be moving on to setting standards agendas about a year after that. Your thoughts are always enlightening, so if you haven't set aside time to read, consider deeply and comment,... soon would be good. Bob [I actually wrote a similar email straight after Buenos Aires, but I just noticed I sent it from the wrong address, so the list rejected it.] On 01/06/16 11:53, Bob Briscoe wrote: > All, > > Can some folks respond on whether they think it is right to hold a BoF > on this topic in Berlin. > > Back in Jul 2015, when we had the first ad hoc meeting about evolving > DCTCP (the one where Matt Mathis suggested we call it TCP Prague), > there was a huge amount of energy and excitement in the room. > > However, I've noticed that the discussion on this list seems to move > in fits and starts. > Can anyone suggest why? > > I see much more discussion off-list about building projects, around > the enabling idea of the dualQ. > Perhaps it's just that it takes a long time for some people to be able > to to shift the focus of their work. > > If that's so, then I guess it is still worth the core proponents > pressing ahead. > Because others only need to influence the direction of travel of a > project if it is moving! > > Thoughts? > > > Bob > > PS. The BoF proposal deadline is on Friday. > I'm guilty for not having yet delivered what I promised: a problem > statement draft - working on it now. > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/
- Re: [tcpPrague] Experimental dual-queue ECN Black, David
- Re: [tcpPrague] Experimental dual-queue ECN Michael Welzl
- Re: [tcpPrague] Experimental dual-queue ECN Gorry Fairhurst
- Re: [tcpPrague] Experimental dual-queue ECN John Leslie
- Re: [tcpPrague] Experimental dual-queue ECN Michael Welzl
- [tcpPrague] Experimental dual-queue ECN John Leslie
- Re: [tcpPrague] Experimental dual-queue ECN Gorry Fairhurst
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Bob Briscoe
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Gorry Fairhurst
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Bob Briscoe
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Spencer Dawkins at IETF
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Gorry Fairhurst
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Bob Briscoe
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Gorry Fairhurst
- [tcpPrague] Enough energy for an L4S/TCP Prague B… Bob Briscoe
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… John Leslie
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Bob Briscoe
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Mirja Kühlewind
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Bob Briscoe
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Bob Briscoe
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… John Leslie
- [tcpPrague] Too fast for Google? Bob Briscoe
- Re: [tcpPrague] Enough energy for an L4S/TCP Prag… Bob Briscoe
- [tcpPrague] L4S BoF Proposal on the wiki Bob Briscoe