From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 D13F43B2A4 for ; Fri, 5 Jul 2019 04:51:13 -0400 (EDT) Received: by mail-lj1-x22a.google.com with SMTP id p17so8540978ljg.1 for ; Fri, 05 Jul 2019 01:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ivKtyQWZwd2fx687W0UMOeYA+NTdxQGW4vq6LSFHQA4=; b=Tt9u1IgJf7c0pKAFZ5+w9KYRqdNOr6r6o/BfiQYD7F0D++PGOsBsB68hSi+QpZcBLf dMDbv0n4FPD9nN6JdbpBpobg/1J3nqVZWkAXC/mNYGTnG7RTkxp2wpNYidFYCBZJ7JQb MY0jfnrOeIVzVjEFgFz93wodcCh/bCiCPsIfEiyf7Aji+2XG54WWSeMR6DihcsF2koMr D7hT6MryX6/jtjmbsmZyXiPQadE+688LDJjEzxXif04VUAGc7xgb7YV55aOinIWiE86L UrSTreW/jimgJSUhtnDKUlrn8m9BN06Ac8U1yTzhcNEt83yAIE2Ok9FdQmFc3h7bdL7X slEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ivKtyQWZwd2fx687W0UMOeYA+NTdxQGW4vq6LSFHQA4=; b=ABq2csCv2nfeaT0XJ6uDfTAVO0lculWA6+MHjssKnvsl+hNAMusqyaHokFq48LtFLd nnDBMsXI7SoAocFWCEhyEBRwXAmw443za5/xR3lt1i9KDrhm0MN6//VAiVC7EaTpOQwL n/NC3Q6UcFqkupjWWgnD9vmPi9CD41C7quW27RTGjd+c3w9euOCg6Uweqnk4koPtJGXz BNke1PIAk3bUcpRYCcRGZl+3oErVD/YkfKN8teNn+tdHkqygqflrHm75M71uHfpGTwQc Q/zyqs8wLfnlly6rvqgPOmD/563HaAI6HQF6Z5NJ8Wv2eTjmBeYDm3us9eD4NnQ1L/g9 Mgzw== X-Gm-Message-State: APjAAAWxktTFm6MYp4n0o0QysKkkeMuev/rjQIgR2407XF2Xfv1T9nzT Iq8IJ9zPFsH7ME6oFV1+TFw= X-Google-Smtp-Source: APXvYqxDE3seDsf23UI8xIwiVjjrvSmB2/DWeFFO25z/y0GoopDN0efSznVfUshYTZBCGMTVlJBJHQ== X-Received: by 2002:a2e:8696:: with SMTP id l22mr1478266lji.201.1562316672639; Fri, 05 Jul 2019 01:51:12 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-232-91-nat-p.elisa-mobile.fi. [83.245.232.91]) by smtp.gmail.com with ESMTPSA id v86sm1632298lje.74.2019.07.05.01.51.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jul 2019 01:51:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Fri, 5 Jul 2019 11:51:10 +0300 Cc: Bob Briscoe , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> 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> To: "De Schepper, Koen (Nokia - BE/Antwerp)" X-Mailer: Apple Mail (2.3445.9.1) 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, 05 Jul 2019 08:51:14 -0000 > On 5 Jul, 2019, at 9:46 am, De Schepper, Koen (Nokia - BE/Antwerp) = wrote: >=20 >>> 2: DualQ can be defeated by an adversary, destroying its ability to = isolate L4S traffic. >=20 > Before jumping to another point, let's close down your original issue. = Since you didn't mention, I assume that you agree with the following, = right? >=20 > "You cannot defeat a DualQ" (at least no more than a single Q) I consider forcibly degrading DualQ to single-queue mode to be a defeat. = However=E2=80=A6 >>> But that's exactly the problem. Single queue AQM does not isolate = L4S traffic from "classic" traffic, so the latter suffers from the = former's relative aggression in the face of AQM activity. >=20 > With L4S a single queue can differentiate between Classic and L4S = traffic. That's why it knows exactly how to treat the traffic. For = Non-ECT and ECT(0) square the probability, and for ECT(1) don't square, = and it works exactly like a DualQ, but then without the latency = isolation. Both types get the same throughput, AND delay. See the PI2 = paper, which is exactly about a single Q. Okay, this is an important point: the real assertion is not that DualQ = itself is needed for L4S to be safe on the Internet, but for = differential AQM treatment to be present at the bottleneck. Defeating = DualQ only destroys L4S' latency advantage over "classic" traffic. We = might actually be making progress here! > I agree you cannot isolate in a single Q, and this is why L4S is = better than SCE, because it tells the AQM what to do, even if it has a = single Q. SCE needs isolation, L4S not. Devil's advocate time. What if, instead of providing differential = treatment WRT CE marking, PI2 instead applied both marking strategies = simultaneously - the higher rate using SCE, and the lower rate using CE? = Classic traffic would see only the latter; L4S could use the former. > We tried years ago similar things like needed for SCE, and found that = it can't work. For throughput fairness you need the squared relation = between the 2 signals, but with SCE, you need to apply both signals in = parallel, because you don't know the sender type.=20 Yes, that's exactly what we do - and it does work. > - So either the sender needs to ignore CE if it gets SCE, or = ignore SCE if you get CE. The first is dangerous if you have multiple = bottlenecks, and the second is defeating the purpose of SCE. Any other = combination leads to unfairness (double response). This is a false dichotomy. We quickly realised both of those options = were unacceptable, and sought a third way. SCE senders apply a reduced CE response when also responding to parallel = SCE feedback, roughly in line with ABE, on the grounds that responding = to SCE does some of the necessary reduction already. The reduced = response is still a Multiplicative Decrease, so it fits with normal TCP = congestion control principles. > - you separate the signals in queue dept, first applying SCE and = later CE, as you originally proposed, but that results in starvation for = SCE. Yes, although this approach gives the best performance for SCE when used = with flow isolation, or when all flows are known to be SCE-aware. So we = apply this strategy in those cases, and move the SCE marking function up = to overlap CE marking specifically for single queues. It has been suggested that single queue AQMs are rare in any case, but = this approach covers that corner case. > Add on top that SCE makes it impossible to use DualQ, as you cannot = differentiate the traffic types. SCE is designed around not *needing* to differentiate the traffic types. = Single queues have known disadvantages, and SCE doesn't worsen them. Meanwhile, we have proposed LFQ to cover the DualQ use case. I'd be = interested in hearing a principled critique of it. - Jonathan Morton