From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 7BAAA3BA8E; Fri, 15 Mar 2019 10:27:47 -0400 (EDT) Received: by mail-lj1-x22b.google.com with SMTP id j25so1695262lji.1; Fri, 15 Mar 2019 07:27:47 -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=WEzYqGfwJbD1UG6LVI6hGIhryug2cA+IUNwo7sy+Orc=; b=iJEXemrKmD38I1inX83XgetCVldxUm8AJKPD1+Dn5RL0zJ51Pfhwt2QdHCneAIaV6w DIbd/mT89Qfgvvxy3oDf4kIsa0nZehLFyrTIDaUwyaZVU3M1xpDz0DllrV+8C+rKmYEA 9It5QKWqEeZislW6upPFTz7z+QfRvdZyZRuQDZQVxYk78hwg1rX4ZHSCcPNkw7B7CV5F gFQ16RIUvsDueiWV5jOWBf/uiaigtWoZBCrW/1+20eQphV4pKjpE96vgc38C0ATqv26r brJN9i7sbwfcgPH5uA1XBto/Ku9XqLwEpWCF4SM5+t3za+/HauDdeIIVwpWQN+Fujx7E 6m8A== 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=WEzYqGfwJbD1UG6LVI6hGIhryug2cA+IUNwo7sy+Orc=; b=mkTXSYWLoJR02Ao5WYLrLKGr1eR8GxV85ycJC20AhIOIqMQnfETxVLIBtasx2P0WSl lU8qvgqaFd0K3WoMX/kGhkn2KM4V6mPArcVxR0F1fS2GykEs60iljAQLf+DUrdYd4uaR XYgHoZ5kaN7+/Cu6DR322XKtKl0pZkyBD4seW+XTrJNY7CKScxtrnuPYJVJiSB8mAq0u Y2Ze91kWoXHzF6/N8Avj2lc3DEtRXjNCy3u4r1AxaN29PbovQrSBCvZAGzR/aBpjUS2n CE2e/3+GomKu6TQkpIIw7xP4+910UlL6tOT2KOHrM54cK62OtyKkM0s7uuU7MwyTIZos CgAg== X-Gm-Message-State: APjAAAV3YpZPYN9j/N6f/O/E6z+BwJ3ZgTYnQRjyCrTKCnBJvUiGkkQ0 lyknGZxE4nPgFRtzTJ5riho= X-Google-Smtp-Source: APXvYqzVDWqnq6gDo+tKhxDycsAfqBGH8cELIxxoy5/eFkXZrIplhoYVtRtGSMb5RcOzaV2FWTPqgg== X-Received: by 2002:a2e:5cc1:: with SMTP id q184mr2320008ljb.123.1552660066336; Fri, 15 Mar 2019 07:27:46 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-235-46-nat-p.elisa-mobile.fi. [83.245.235.46]) by smtp.gmail.com with ESMTPSA id h26sm441436ljf.5.2019.03.15.07.27.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 07:27:45 -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: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> Date: Fri, 15 Mar 2019 16:27:43 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , bloat , ecn-sane@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 14:27:47 -0000 > On 15 Mar, 2019, at 3:01 pm, Sebastian Moeller = wrote: >=20 > That said, having read through the L4S architecture description and = the related appendices of draft-ietf-tsvwg-ecn-l4s-id-05 I came to the = conclusion, that this is a mess. >=20 > The L4S project proposes a really wide-ranging change of basically the = internet (but allow a concurrent operation with legacy probably to cater = to the fact that an internet-wide flag-day seems daunting to organize). = But then they chicken out when figuring out how to differentiate between = their new and the old by proposing to use ECT(1)=E2=80=A6 I think I would be less annoyed by L4S if it proposed to assign a DSCP = or three to identify its traffic. In fact, I'd be interested to hear a = defence of why DSCP identification of L4S flows was *not* adopted. I = suspect it would revolve around the widespread practice of re-marking = DSCPs by ISPs, which renders DSCP too unreliable for L4S' purposes. But using the ECN field for this purpose is *also* unreliable, because = it is *intended* to be altered on route (in prescribed ways). In = particular, both ECT codepoints can be replaced by CE, erasing the = distinction between them when it comes to choosing which half of a "dual = queue" AQM to pass it through. I'm not convinced they've spent very = much of the past several years thinking about that. Fortunately, L4S flows should work with flow-isolating AQMs (including = Cake) without modifying the latter, and without needing to specifically = identify which flows are L4S or otherwise. That really says more about = the robustness of proper flow isolation than anything else. But = Codel-type AQMs don't provide the ideal ECN signal for L4S (and nor do = RED-type AQMs without specific tuning for L4S), and any single-queue AQM = is going to end up with L4S flows outcompeting standard ones quite = seriously. Since very little "big iron" hardware supports flow-isolating AQM so = far, that puts a damper on any "incremental deployment" argument to be = made for L4S, even if they claim their dual-queue AQM is easier to = implement at high link rates than full flow isolation. The fact is that = either dual-queue or flow-isolation is required in middleboxes *before* = endpoint deployment of L4S can begin. SCE explicitly avoids these problems, as both SCE-aware endpoints and = SCE-aware middleboxes can safely be deployed without waiting for each = other. Work remains on figuring out precisely how SCE information = should be produced and consumed, and verifying that the resulting system = behaves as intended when fully deployed - but its interaction with = existing deployed hardware and software is explicitly defined to be = benign. - Jonathan Morton