From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 16A933B29D for ; Thu, 30 Apr 2020 13:55:53 -0400 (EDT) Received: by mail-lj1-x234.google.com with SMTP id b2so281483ljp.4 for ; Thu, 30 Apr 2020 10:55:53 -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=ssyPlsxl5MIFelAygl41LVgazWjaElqiTb3mFOfL6wY=; b=rgAyXzFcZrkzLT5AwHaxCWFK66B2Hm9Uh53HDBMYiti/9FHUHErGFsdIz5sC5L//TH O/33k7LhZ6r/Cid5lbOMOlISrZBnL877wKnTJUPuUELFRzrHG7x+WO0nYw+Av3nmoPhO QJDisZmIS7lrmfLMayoypbUSXCkpsqRpWfmA3AUylAPUr3iMmcOXoHIwYU8bJuosXJbf QzypgpmWQ6FsvwN45RTcYnezPZzyLhUupt7qXGyatuTHor4fEwMkO123vFzlEojmvtSZ zmc9/G0/3GBE2hLdq6DP2pvLZxChoJRmbgI0QvbCDAX/+SMkXwVVHG6CoODEM/8amO9D YBVQ== 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=ssyPlsxl5MIFelAygl41LVgazWjaElqiTb3mFOfL6wY=; b=qCA4GXn1jpoDaiXTmQci6UkAA5XgKw9hia1PqKO4RMBkZSSCCaQ6yJCzVo0ZtWEUQ0 g2s60op902V0iKQqcUmpUsPEasyCsDMUhih93QjwGz34kLvnkd8tY+8un24RGuJMX342 f2pc50Js0AB2KdczrUt7vyYDVC63JFKKvlTOWauDf3pM6FZt2465vSTGYAdmXBTWMfq5 MVTeGZd1PsllDbkHTh08U6Ez04IIRgojJrXgeNbYCl7n+qQyxJBv7FW7/cOT5jZUu6TP iwiM+iEsuf1sKZHPNHUPaLbkh8onnyE1vAMcjbFlRyOjjdfpavWtk4SBQkia8PcajyhV Ifiw== X-Gm-Message-State: AGi0PuYv5ZGD0zVzOJYDTyWbI9pAkCzbV9JAMLxcX8ud0QAF61s6DQIV ZWXbHRAxqrfKmp+OAFWkFsE= X-Google-Smtp-Source: APiQypLu/Ey+zEt8uGJD6QYQbLH8uNh+d0inTu3bV39sqbAvqVBqVL3cCa2rgBLR+NoDYVT0Az2HCw== X-Received: by 2002:a05:651c:1058:: with SMTP id x24mr26418ljm.39.1588269351948; Thu, 30 Apr 2020 10:55:51 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-235-192-nat-p.elisa-mobile.fi. [83.245.235.192]) by smtp.gmail.com with ESMTPSA id h14sm255658lfm.60.2020.04.30.10.55.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2020 10:55:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <2937CA62-6FCC-4E32-B7F5-11A6A485F1EE@gmail.com> Date: Thu, 30 Apr 2020 20:55:49 +0300 Cc: ecn-sane@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <7BF193B5-DF2E-493B-B8A7-B7CB5D4BABEA@gmail.com> References: <2937CA62-6FCC-4E32-B7F5-11A6A485F1EE@gmail.com> To: Rich Brown X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Ecn-sane] Questions about TSVWG call 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: Thu, 30 Apr 2020 17:55:53 -0000 > On 30 Apr, 2020, at 8:28 pm, Rich Brown = wrote: >=20 > I have been a bystander in these discussions, and could only listen in = to part of the TSVWG conference call. But here are a couple questions = that come to mind from what (I think) I heard... >=20 > 1) Has anyone run RRUL tests on L4S gear? What would be involved = setting up such a test? Why hasn't it already been done? I'm pretty sure the L4S team hasn't. We're doing some runs now = ourselves. As for why, it might show up something inconvenient that = doesn't look good for their marketing. > 2) If I understand correctly, the L4S proposal is to use the ECT(1) = bit as an input to the routing algorithm. If it's set, the router can = assume that it's latency-sensitive traffic and use special routing = rules/queues/etc. How does L4S guard against DoS/cheating? Has such a = proposal been implemented and tested? It's a fair question. A "queue protection algorithm" is supposedly a = MUST in the L4S spec, but we haven't seen a working implementation yet, = and it rather undermines their claims that L4S doesn't require L4 header = inspection. I happen to think the real danger lies the other way, that = with 1/p responses to CE legitimised, someone will alter a sender to be = classed into the "classic" queue instead, squeezing out other traffic. = Y'know, like DCTCP does. Because SCE doesn't rely on a classifier, no such danger exists for us. = We use a different method to ensure SCE traffic coexists nicely with = conventional traffic. > 3) The L4S proposal is designed to decrease latency. Can there be a = successful L4S deployment in the face of the millions of current CPE = that have no notion of latency control? In a drop-tail queue, L4S is supposed to respond to lost packets with = MD, and reserve the 1/p response solely for (at least) ECN enabled = networks. We found that functionality had not been very well tested, = though they fixed the bug we found pretty quickly. The major concern is = with L4S' deployment into an Internet equipped with conventional AQMs = and exhibiting significant jitter on real paths. SCE works fine on any existing deployed network, with conventional = behaviour as long as SCE signals are absent. When the bottleneck is = also SCE enabled, all flows passing through it benefit from the = associated FQ or AF management, and SCE flows additionally get the = benefits of high-fidelity congestion control. > 4) I have a personal bias toward helping people with dreadfully slow = ISP service. (My home can only get 7mbps/768kbps DSL; others in my town = only get 3mbps/500kbps service.) Does L4S help for slow links like = these? Our testing has found that the "classic detection heuristic", intended = to deal with existing AQM deployments, is triggered on slow links such = as that (our example was at 5Mbps) even if they are L4S equipped, so no, = there is no benefit from L4S there. I think we can demonstrate SCE achieving better results here. The goal = for us is to achieve 100% link utilisation without incurring excess = latency, and without breaking stuff that's already in use. L4S tries to cut queue delay so low that, at anything less than 25Mbps, = it takes longer to deliver a single packet. So they can't reliably = operate on ADSL at all. - Jonathan Morton=