From nobody Sat Oct 16 19:17:10 2021 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6623A076C for ; Sat, 16 Oct 2021 19:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OY2uox-1EhR for ; Sat, 16 Oct 2021 19:17:01 -0700 (PDT) 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 ietfa.amsl.com (Postfix) with ESMTPS id 534533A0763 for ; Sat, 16 Oct 2021 19:17:01 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id e19so1670188ljk.12 for ; Sat, 16 Oct 2021 19:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kC4hffkDWV5KlgHCjNrwngG6Yl/mQiACWweqNU89uQs=; b=mcPisXFRJkKq6n7inI+9M+MRqhrcMBRx5fcC+ppovau3CB8XakGh4BCNIrCxKgRREW dPPv1EbsiKFKXz/0WTumfhZ24QQwHtisexf8OmGDEKncIEEJYugcTXFoox6RKeHFC3Ox c3I1qQ9IRY3ShOf0gr0cmQXYhTVEtimVSw244QktY64IGryim/PWZ3klgvOjaz0l7fGJ hd4YUCqtaj4VnkWtmLBET9vS38qPAzkjyFeLO+BJwRXK0L/k9qo0w1Dr7mbeJ9xabnE/ 1iHn9xQIc/n8pS341EuIeW2h/6zg6zCToigwv+Iyoakpm1/FZpFfDbCx5V3kt6nPF507 4Gew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kC4hffkDWV5KlgHCjNrwngG6Yl/mQiACWweqNU89uQs=; b=M+85dvd7Bu6b4hMSlyflcMfl4VqHgppwy1Y7XlXoEPIulRofTbvZ5CrlGq/5ovl4Dq vlglOgyqjjm7TYOZYLNX6SMAPqpzPaLLN9czsmNBp/Z6EyQ7N71yVhrVUVHALZKyMR67 tqCb7v3m8EhWmrhUV8q/b2XA64LnRZD54JrBEqGl1POAyegttAI++0wOcoH6xuYaEktd Er2jxrfjZ0it3uvmioIRFmptb5IK0sI/sUS8T0RwZ1t6IKvN3xkPTZ2Ue60Nwbrkyzrq JRXDoqYKPD8SOJ98B8QNerpstEoKDsp+tjM05q5aIrEyps/pcmGQCfNscV2vQZTxT3pu bZlQ== X-Gm-Message-State: AOAM532ns6alVDQMMO0ZnsvGpoUpCewJuWVje5kDtuQwIniYOJGMtTTV iZr3GXdh5y8ioL6l8VgAWSM= X-Google-Smtp-Source: ABdhPJy61fJC2A9FWSqn6bZuBTwA1QbNh4oGU095GfJL/aVHJYCpcqGEuyhMvLRIvgLqllZLwJ7OAA== X-Received: by 2002:a2e:b05a:: with SMTP id d26mr22488775ljl.77.1634437018852; Sat, 16 Oct 2021 19:16:58 -0700 (PDT) Received: from smtpclient.apple (176-93-88-52.bb.dnainternet.fi. [176.93.88.52]) by smtp.gmail.com with ESMTPSA id h7sm1113993ljh.97.2021.10.16.19.16.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Oct 2021 19:16:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Jonathan Morton In-Reply-To: <24307985-3450-a4db-5ca0-8d51d4195155@bobbriscoe.net> Date: Sun, 17 Oct 2021 05:16:57 +0300 Cc: Luca Muscariello , Gorry Fairhurst , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2D04A7C8-2C0D-46AA-86BB-D5CDD0D2A5CE@gmail.com> References: <7dd8896c-4cd8-9819-1f2a-e427b453d5f8@mti-systems.com> <360988450.1173982.1630607180962@mail.yahoo.com> <8415BA1F-2806-4224-9D9F-EB256DA7DF41@gmx.de> <24307985-3450-a4db-5ca0-8d51d4195155@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [tsvwg] start of WGLC on L4S drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2021 02:17:08 -0000 > On 17 Oct, 2021, at 2:38 am, Bob Briscoe wrote: >=20 >> If TCP had been designed with a scalable congestion control from the=20= >> start, we would have had L4S with no need for a scheduler at all. The=20= >> scheduler is primarily a transition mechanism, to isolate from = Classic=20 >> traffic. But no traffic /needs/ to be Classic, it's just how "stuff=20= >> happened". >>=20 >> I do not think this is true in this specific case.=20 >> There is an advantage in terms of goodput for applications to use=20 >> loss-based congestion control and create bigger queues (in >> absence of isolation). >=20 > [BB] This may be true in the short term for non-latency sensitive bulk = traffic, especially over variable capacity (e.g. radio) links where = buffered packets can fill newly available capacity while the e2e = congestion control catches up. >=20 > Nonetheless, there is also the unscalable aspect of loss-based = congestion control where, as flow rate scales, it takes longer and = longer (minutes) to recover after each loss [RFC3649]. As was pointed = out in footnote 6 of [Jac88], the noise sensitivity gets worse as flow = rate scales. Meaning, even if there's a very low level of transmission = losses or new flows arriving, a flow keeps getting knocked down by each = noise event, while it's slowly trying to regain its previous position. >=20 > It's possible that some new approach will get out of that unscalable = rut, but it's been quite resistant to solutions so far. BBRv2 has = already had to reinstate a capped dependence on loss probability, in = order to remain backward compatible with the legacy of loss-based = congestion controls. The setting of that cap will have to keep being = reduced in order to scale flow rate, so it is trapped in the same noise = sensitivity problem.=20 I think it's very disingenuous for you to quote only a paper from 1988, = at the very dawn of TCP congestion control research, in support of this = argument. At that time, only the Reno algorithm was in use, and Reno = does have widely-acknowledged scalability problems, especially with = respect to random loss on high-BDP paths. It's actually rather strange, = given that fact, that TCP Prague uses only the Reno growth function = while claiming to be a "scalable transport". However the deployed state of the art today is CUBIC (as you very well = know), and CUBIC is considerably more scalable than Reno (in the upward = direction, at least), especially in the face of low levels of random = loss. On the research side there is also Scalable TCP, an MIMD = algorithm that is even less sensitive to random loss than CUBIC. This sensitivity to random loss is easily shown to be a function of the = cycle time of the congestion-control loss-response sawtooth; iff loss = events occur more frequently than this cycle time, the average cwnd will = trend downwards. In Reno (and Prague), this cycle time is proportional = to RTT and to the square of throughput. In CUBIC, the cycle time is = roughly proportional to throughput and mostly independent of RTT. In = Scalable TCP, the cycle time is proportional to RTT and independent of = throughput. (These generalisations assume constant segment size, etc.) > I don't know whether bulk flows will prefer to continue to use the = classical approach with more buffering, or the scalable approach with = frequent control signals. I'm just saying it's not as clear-cut as you = make out. They will likely choose the option that is universally available and = yields the maximum goodput. In the present state of L4S, that is = clearly "Classic". > As a fairly close analogy, can you imagine any individual or company = gaming a PIE AQM to induce more latency on their own flow, in order to = impose more latency on others in the same household? The goal would not be to increase latency. The goal would either be to = selfishly increase throughput for their own traffic (which could be done = using Relentless TCP at the sender side, exploiting exactly the same = effect with a drop-only AQM as L4S would impose in a shared ECN AQM), or = to increase packet loss and thus degrade service for the other traffic = (which could be done using a simple flood, driving the AQM into a high = dropping probability). These scenarios are so common, and so easy to = imagine, that they should be part of a standard security analysis - and = neither of them would result in substantially higher latency on the = path, since in both cases it is assumed that the AQM effectively = controls the queue delay to its target. DualQ offers attackers a very easy way to gain higher throughput for = themselves. With some traffic, it also offers an easy to to increase = packet loss as high as 100% for a particular type of target traffic. = These are problems over and above those of PIE, which are relatively = minor by comparison. - Jonathan Morton=