From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EE94B3CB38 for ; Fri, 19 Jul 2019 14:33:39 -0400 (EDT) Received: by mail-io1-xd2f.google.com with SMTP id o9so60448020iom.3 for ; Fri, 19 Jul 2019 11:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=CHbeoSjiydIbgoMJhJU1aIt94S1Qcp2PC7atnk0lYq0=; b=U5N+alTVof0qyQfdAC/f/O06JnfCGSF9ADysT3tuwXA/80cgQZRB1l0bC0pQrfcR9v 15VevVZnm455DkdIlmmYiuTRhwiKF6MFnqyekuiVpEHj/em0wGQXkxNPpLCDUingEIv7 XNO8YCo2Px49QAl+URxsfxJlXB7tixQ6epm6LYhCb4xrPYkFpjUA16fWAUoCa6FzYTGh uiJyrF2UwUgfPlB1q7gbHTWB+tUm58N/5daTpGUIxDPbzknOG7Hg3ToWK0VcFWvzVCAr 2K89skY0i9b2kmHqeSGOSf4FoAr72uMh+qppK7MUawzKmJ729VqxvZnnSlGB3vhWWyn+ tOmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CHbeoSjiydIbgoMJhJU1aIt94S1Qcp2PC7atnk0lYq0=; b=Z24tlHgdm7O+xeVhFt6W4wRIS6VdH4Si93VI8IjqeeTwAHD4pfCPGUZtQyzRGrG0SN 5yjD/z4MNBdEZIErY/eOxucd9Wu0m8qvUiFH+PJlI+BgXDju0GQTNmsWDLO09eXRGqxs L08+v0CCv/Au4w/ZoMql6KeKUUjO8kzK14VkEQNmMlLQ0pRLP4JGBD+asECN8qFSX8Id Zq+YHsaKCmr3OPxUQDxTUsyLGRUGIjqdTJkJGKubLwMiOMQwl3jzsQcdLLZVUY/8aHW8 0mRDZZkF18Hrea6UC3xih+1wUnphnKcjH9++wg37F1BxkkXnbP6Y2pC6WJnJDA8cRRAc jYvQ== X-Gm-Message-State: APjAAAVoaIoez7AaZLkn9CcZDZDE7D6e8ybNFG+810qDpIyQo5uZ2EcP HdYQOS/8JsDFC4GRDGDNgR8= X-Google-Smtp-Source: APXvYqwPRKGqQn5Y8exhwpirU2TLrsMvvZ7uWlX07jiF6IWHKCxpX5iQoSpOfMEIsHcKNsoGK6s/AA== X-Received: by 2002:a5e:9314:: with SMTP id k20mr31598752iom.235.1563561219339; Fri, 19 Jul 2019 11:33:39 -0700 (PDT) Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id p3sm37535817iom.7.2019.07.19.11.33.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 11:33:38 -0700 (PDT) To: Dave Taht , "De Schepper, Koen (Nokia - BE/Antwerp)" Cc: "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> From: Wesley Eddy Message-ID: Date: Fri, 19 Jul 2019 14:33:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <87ef2myqzv.fsf@taht.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 18:33:40 -0000 On 7/19/2019 11:37 AM, Dave Taht wrote: > It's the common-q with AQM **+ ECN** that's the sticking point. I'm > perfectly satisfied with the behavior of every ietf approved single > queued AQM without ecn enabled. Let's deploy more of those! Hi Dave, I'm just trying to make sure I'm reading into your message correctly ... if I'm understanding it, then you're not in favor of either SCE or L4S at all?  With small queues and without ECN, loss becomes the only congestion signal, which is not desirable, IMHO, or am I totally misunderstanding something? > If we could somehow create a neutral poll in the general networking > community outside the ietf (nanog, bsd, linux, dcs, bigcos, routercos, > ISPs small and large) , and do it much like your classic "vote for a > political measure" thing, with a single point/counterpoint section, > maybe we'd get somewhere. While I agree that would be really useful, it's kind of an "I want a pony" statement.  As a TSVWG chair where we're doing this work, we've been getting inputs from people that have a foot in many of the communities you mention, but always looking for more. > In particular conflating "low latency" really confounds the subject > matter, and has for years. FQ gives "low latency" for the vast > majority of flows running below their fair share. L4S promises "low > latency" for a rigidly defined set of congestion controls in a > specialized queue, and otherwise tosses all flows into a higher latency > queue when one flow is greedy. I don't think this is a correct statement.  Packets have to be from a "scalable congestion control" to get access to the L4S queue.  There are some draft requirements for using the L4S ID, but they seem pretty flexible to me.  Mostly, they're things that an end-host algorithm needs to do in order to behave nicely, that might be good things anyways without regard to L4S in the network (coexist w/ Reno, avoid RTT bias, work well w/ small RTT, be robust to reordering).  I am curious which ones you think are too rigid ... maybe they can be loosened? Also, I don't think the "tosses all flows into a higher latency queue when one flow is greedy" characterization is correct.  The other queue is for classic/non-scalable traffic, and not necessarily higher latency for a given flow, nor is winding up there related to whether another flow is greedy. > So to me, it goes back to slamming the door shut, or not, on L4S's usage > of ect(1) as a too easily gamed e2e identifier. As I don't think it and > all the dependent code and algorithms can possibly scale past a single > physical layer tech, I'd like to see it move to a DSCP codepoint, worst > case... and certainly remain "experimental" in scope until anyone > independent can attempt to evaluate it. That seems good to discuss in regard to the L4S ID draft.  There is a section (5.2) there already discussing DSCP, and why it alone isn't feasible.  There's also more detailed description of the relation and interworking in https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-02 > I'd really all the tcp-go-fast-at-any-cost people to take a year off to > dogfood their designs, and go live somewhere with a congested network to > deal with daily, like a railway or airport, or on 3G network on a > sailboat or beach somewhere. It's not a bad life... REALLY. > Fortunately, at least in the IETF, I don't think there have been initiatives in the direction of going fast at any cost in recent history, and they would be unlikely to be well accepted if there were!  That is at least one place that there seems to be strong consensus.