From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 9A8283BA8E; Tue, 19 Mar 2019 01:35:39 -0400 (EDT) Received: by mail-lj1-x231.google.com with SMTP id a17so16169401ljd.4; Mon, 18 Mar 2019 22:35:39 -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=pP+NiSKGJi/Hxn/1delLnfoe8U6oMNXdqG0RzpSigv8=; b=eubi61xvR5vU5ASketyElFe92Tb4K+CXb/ooGm9bEj8ixnM0Iup5852HTHh+FE7RIF wvDVT5VYoBmZ73qQ1PwWr8eZX4AVt3kfWsnD7zfXOFQKu3E/Pw0BauA3OoaQ7pRaxFP1 cIFDd7c64HU8mzmJUgPF40mGOZSAWHCoYznvCoUtTzQfBu+iSkPyite3eRqzgslTPx9w AKGhwNedIDPlyt36QbIU1Y3DpDqygHI9O6Ds3hUz2beEjnjp5LBGyc55BalmBVi9BkN1 WDLs3WjJ8btA4G3op3+WTkkb/STunf5VGU8goOdTDxGYOnk+qsTfh6D2BwaZBo/HM7a+ gQrw== 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=pP+NiSKGJi/Hxn/1delLnfoe8U6oMNXdqG0RzpSigv8=; b=Q7XkTyAZ9/rCieEM6D4mAg3a3KVl/Z1Y5gr2ESp3wgi2rCH2F/CO+SXby1PI3teZdA H2a1CbLQsInZKSv8+vijnUFdXXBfQR1vR8KciMeFk5I+SEcoV2W8q0MOK1pHXmlE5U09 +V95P109gexGtkfEIIC13WFSCwsN7N3qDUYwLvfd4ZYdGWDApU8YQzzuMX+b561ZIoP3 jLGL+b5gHw2s+zHj9PNBIXkXg/6IuZ0uVsImyhE1HZGVOo8unu+mE0GEh1pSvF8wSDvx lSQoDthc+SUKxKiawv59DS0qAl/28rs8Oso64OLDoNalLJA2+aRqRIYyE29wfyAryHEm 5+4g== X-Gm-Message-State: APjAAAVpAcWMBibzQoKXuBPwf3zxfymlQaSJxrLFmiYRZ7V3SykWChyQ 994xQClJj9Xyi7mcaaZxCcg= X-Google-Smtp-Source: APXvYqzTeQVO2O+7BXbvHmTXd8hEM3EwPDbwot5HSDRVRdF4Z4IBEBQVTgDr7BQqZWJNG7V7E15iSQ== X-Received: by 2002:a2e:9b41:: with SMTP id o1mr12577106ljj.103.1552973738558; Mon, 18 Mar 2019 22:35:38 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-227-44-nat-p.elisa-mobile.fi. [83.245.227.44]) by smtp.gmail.com with ESMTPSA id k23sm2544994ljk.69.2019.03.18.22.35.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Mar 2019 22:35:37 -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: Tue, 19 Mar 2019 07:35:35 +0200 Cc: "David P. Reed" , Vint Cerf , "ecn-sane@lists.bufferbloat.net" , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <93781542-6DD4-4840-A1C6-A5C28E40A0F7@gmail.com> References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <1552846034.909628287@apps.rackspace.com> To: Greg White X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] [Ecn-sane] [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: Tue, 19 Mar 2019 05:35:39 -0000 > =E2=80=A2 SCE will only work if the bottleneck link implements = fq. Some bottleneck network gear will not be able to implement fq or = will not implement it due to its undesirable side effects (see section 6 = of RFC 8290). > SCE leverages a paragraph in a draft that describes a first guess = about how a congestion controller might work. We have an update in the works that should enable RTT-fair convergence = with single-queue AQMs, whether they support SCE or not. To do this = using the simplest reasonable adjustments to existing congestion control = algorithms, the setpoint is no longer fixed at 50% but varies with the = cwnd of each flow. And yes, we have worked out what those adjustments = should look like in practice, but we haven't yet had time to run tests, = or describe them in a nicely formatted I-D. This update should also allow a very DCTCP-like congestion control = algorithm to work correctly with SCE, as long as it acts conventionally = with CE marks and only has the reduced response to SCE marks. That's = something that DCTCP itself currently does not do. > =E2=80=A2 SCE=E2=80=99s usage of ECT(1) potentially allows an = automatic fallback to traditional Cubic behavior if the bottleneck link = is a single-queue classic-ECN AQM (do any of these exist?), whereas L4S = will need to detect such a condition via RTT measurement =46rom my standpoint, the major objection to L4S is that it is not = incrementally deployable, because DCTCP starves conventional TCPs unless = run through an isolated queue. This is something we quickly realised = when L4S was first announced. It is simply not practical to require all = middleboxes on the path to support L4S before L4S endpoints can safely = be deployed, except in the isolated and very controlled environments = where DCTCP was "proved". > I find it extremely disappointing that some people on this list are = taking such a negative attitude to the major development in their own = field that they seem not to have noticed since it first hit the = limelight in 2015. It is not at all true that we were unaware of L4S. Rather, we quite = reasonably believed it would never get traction in the IETF or in the = Internet at large unless that problem was robustly solved - and we = thought the obvious solution *was* to use ECT(1) as SCE does, and to fix = Diffserv (so that it becomes e2e usable to some degree) or implement FQ = if isolating low-latency-assured traffic is so important. Incidentally, during that time we were implementing a good FQ system = that is now in Linux and in commercial products. Granted, it isn't = designed for the sort of high-capacity links where FQ is traditionally = considered impractical. > L4S has defined a congestion feedback mechanism so that these = congestion signals can get back to the sender. SCE offers that = =E2=80=9Cwe=E2=80=99ll propose something later=E2=80=9D. It should be straightforward to adjust AccECN so that it primarily = carries SCE information instead of unnecessarily detailed CE = information. That's one obvious solution, which we hoped those already = familiar with L4S would recognise without explicit prompting. We have outlines of other feedback methods, still awaiting conversion to = the proper document format, including one that doesn't require a new TCP = option (I understand there are objections to such things, centred around = paranoid firewalls) and which existing middleboxes and endpoints will = transparently ignore (like the rest of SCE). It uses the NS bit which = was also freed up by the obsoleting of Nonce Sum. The I-D presently available defines the SCE codepoint and very little = else. This is due to separation of concerns. Other I-Ds will define = feedback mechanisms, detailed modifications to congestion control = algorithms, and recommendations as to what AQMs should do. Perhaps if we get a chance to work, instead of responding to = manufactured outrage that we dare to propose something different, these = extra documents might surface in time for discussion. - Jonathan Morton