From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 865503CB3A for ; Fri, 19 Jul 2019 18:09:09 -0400 (EDT) Received: by mail-qt1-x82b.google.com with SMTP id h21so32612449qtn.13 for ; Fri, 19 Jul 2019 15:09:09 -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=dbOVz0BNIVMkymCFcLKBcIPN/A+CVZvsVbmvojiniPQ=; b=bGANBo3YFA77axL3ZfjA+Y63XZJZEaIivUyI3OnrtifZYs7kjPCPoP8TCwIEsyMqms ZN+S8DdaICvpA9/VnDJqPhFwQrLQl4DEwDUxUqvjD6apNjGSsrgo93pkijClXPpcisYI orrHS6EJWo19HjKtIaft30Hvjn6YJrBDXRqgSn1K+SXdJXAEAl2mGcJ3ofsBYrhe3VCm vuM0joaAkk391XT52A/GMFygfSja7gmrML9KuzgQM6n4KJ38AfJTwxrQoKWkKv0sa7OV tgPeSCPTJnJaLP8Qt7hc0HWLVuvDeeVQpVSimgA+MV/whOeqZLbJbxWhKIL8hWmqx6ZF 1U2Q== 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=dbOVz0BNIVMkymCFcLKBcIPN/A+CVZvsVbmvojiniPQ=; b=WfHmDLUbJxGLwA5mNRSvEe8eETJDfFfHt9txJSri+onYlsQkexwD+9EpCda5/SM2hr BCG3fmd3QTmc2EsEqxSQYH/5JmTGskyKyR418VM0jE0VHsVQussItbEBTpBXPDjnp2zG sc7or3bhc/ySOn5ViHydHbTJjs7/JHqV91A/hW3RNuXYoqr4RUQthyB+wrq2wxrb/dzR fm3gLjWSo2g4hAKO+5ECfplLQY95JA6qv5X4nDbhtqKWZ5VyFY86vvMwR+Oatb68raDr UFaanjQrG/svENk/MIvpx0Z0e5FL88YgWeauFQyAfCQsjz3iXWq4wj9rAB8UpYSppzqo bh+w== X-Gm-Message-State: APjAAAVoaNbluQX7fsmjGR5Qi0bQYBdmx4hPT+NMsCj9pBhzA5srqGhi YEN8wCAUlj9XHeU6RbIoIQo= X-Google-Smtp-Source: APXvYqzhqarr6tOLr6lrzKpGZoiwDDl+24QALkHKHZBUKKaCbkxbXzxrOIuu0PRALYFPQSY8nXWOxg== X-Received: by 2002:ad4:55a9:: with SMTP id f9mr39866942qvx.133.1563574149126; Fri, 19 Jul 2019 15:09:09 -0700 (PDT) Received: from [192.168.1.14] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id a54sm16442671qtk.85.2019.07.19.15.09.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 15:09:08 -0700 (PDT) To: Dave Taht Cc: Dave Taht , "De Schepper, Koen (Nokia - BE/Antwerp)" , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <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: <0b76f7eb-a594-17b6-bdeb-226e340b0cea@mti-systems.com> Date: Fri, 19 Jul 2019 18:09:06 -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: 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 22:09:09 -0000 Hi Dave, thanks for clarifying, and sorry if you're getting upset. When we're talking about keeping very small queues, then RTT is lost as a congestion indicator (since there is no queue depth to modulate as a congestion signal into the RTT).  We have indicators that include drop, RTT, and ECN (when available).  Using rate of marks rather than just binary presence of marking gives a finer-grained signal.  SCE is also providing a multi-level indication, so that's another way to get more "ENOB" into the samples of congestion being fed to the controllers. Marking (whether classic ECN, mark-rate, or multi-level marking) is needed since with small queues there's lack of congestion information in the RTT. To address one question you repeated a couple times: > Is there any chance we'll see my conception of the good ietf process > enforced on the L4S and SCE processes by the chairs? We look for working group consensus.  So far, we saw consensus to adopt as a WG item for experimental track, and have been following the process for that. On the topic of gaming the system by falsely setting the L4S ID, that might need to be discussed a little bit more, since now that you mention it, the docs don't seem to very directly address it yet.  I can only speak for myself, but assumed a couple things internally, such as (1) this is getting enabled in specific environments, (2) in less controlled environments, an operator enabling it has protections in place for getting admission or dealing with bad behavior, (3) there could be further development of audit capabilities such as in CONEX, etc.  I guess it could be good to hear more about what others were thinking on this. > So I should have said - "tosses all normal ("classic") flows into a > single and higher latency queue when a greedy normal flow is present" > ... "in the dualpi" case? I know it's possible to hang a different > queue algo on the "normal" queue, but > to this day I don't see the need for the l4s "fast lane" in the first > place, nor a cpu efficient way of doing the right things with the > dualpi or curvyred code. What I see, is, long term, that special bit > just becomes a "fast" lane for any sort of admission controlled > traffic the ISP wants to put there, because the dualpi idea fails on > real traffic. Thanks; this was helpful for me to understand your position. > Well if the various WGs would exit that nice hotel, and form a > diaspora over the city in coffee shops and other public spaces, and do > some tests of your latest and greatest stuff, y'all might get a more > accurate viewpoint of what you are actually accomplishing. Take a look > at what BBR does, take a look at what IW10 does, take a look at what > browsers currently do. All of those things come up in the meetings, and frequently there is measurement data shown and discussed.  It's always welcome when people bring measurements, data, and experience.  The drafts and other contributions are here so that anyone interested can independently implement and do the testing you advocate and share results.  We're all on the same team trying to make the Internet better.