From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 47B0F3B29D for ; Wed, 29 Sep 2021 06:36:22 -0400 (EDT) Received: by mail-lf1-x12a.google.com with SMTP id b15so8689438lfe.7 for ; Wed, 29 Sep 2021 03:36:22 -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=lld310r7FslNN3FXlrQqHDjBpxUDIRYQZXPXBQqUN7I=; b=bDkl+XUuRoOgxSAGJWQ1LY4rJ1RR72PsIkoPJxQ3iMrlxdVbs0qL8K/zHteTwgmhWG YpYFbWjADXk410yZlnnDMs1enHuchlavqMNr8764ZfY8MO9HN8k8h398YoJApjrE0Q/R 8qqGRlMCyGwh3dYYa0mYbFDn5or0bCFfrBLKSZlehr89Vpsgxu3fa83qg2t8BlbuSK2M nRaB6w8Y+IsKIa7wm2AhZvBrAryp+rMX4UgV9MIG3eqoetYwcUZYMTSrQXf3r9RI9OU0 17o0hEf2VwTewVVa0nuKaXBqhCwCUtId4WJ4tuw9UMfmMYeQSqj1Dp+dTTUIUtxAaGSl +EAg== 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=lld310r7FslNN3FXlrQqHDjBpxUDIRYQZXPXBQqUN7I=; b=okWUX1w/uDWQ7aze2aBGGXSzjUpmE6G65yfVuy1Dp7M6X40Jtg8Eyn+FMvfn1g1JdT lYVkUeo/1mMheoPZ0Uk6qiEjwNtv9Y918t4eqJb1Z1qoDndrAahnavefGINhY8ajjDPs a0o/AnS52wqbWIKf+8dpGUJ4g9xMMfU3sEAOGJS16qlSY0DSms759LTOfe6IMPLGHNH2 GFehypTxF9jL6b0DT9Q6y1Vcg2M6tyOVJ1AcQM590AQEErezWIHyZ+Sm7/dWA6lCdSKh HZu1bhpkt8LfEDIdAjHI8reuNq2qu6VL1O4hIg3tuA7JS9qPlToghPL+zHKcU8VT4fr9 GVfw== X-Gm-Message-State: AOAM530ndwG02by3zJGVsBwoudJSAFRofxUBGYl2AFoX2cftLMgL4Iyi AXCXxaLPb6ypu5dEUAOPWPIonvj81qc= X-Google-Smtp-Source: ABdhPJwK77J7ob3x8DiOajerAByd/+p7q3zmrmT2G7dnRnlypEe1O2gjEfsko8fOiAuFK5tz+BNkRw== X-Received: by 2002:ac2:44cd:: with SMTP id d13mr10404902lfm.85.1632911780466; Wed, 29 Sep 2021 03:36:20 -0700 (PDT) Received: from smtpclient.apple (176-93-88-52.bb.dnainternet.fi. [176.93.88.52]) by smtp.gmail.com with ESMTPSA id q2sm198980lfo.174.2021.09.29.03.36.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Sep 2021 03:36:19 -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 X-Priority: 3 (Normal) In-Reply-To: <1632867355.4986972@apps.rackspace.com> Date: Wed, 29 Sep 2021 13:36:18 +0300 Cc: Bob Briscoe , "Mohit P. Tahiliani" , ECN-Sane , Asad Sajjad Ahmed Content-Transfer-Encoding: quoted-printable Message-Id: References: <1632867355.4986972@apps.rackspace.com> To: "David P. Reed" X-Mailer: Apple Mail (2.3654.100.0.2.22) Subject: Re: [Ecn-sane] paper idea: praising smaller packets 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: Wed, 29 Sep 2021 10:36:22 -0000 > On 29 Sep, 2021, at 1:15 am, David P. Reed = wrote: >=20 > Now, it is important as hell to avoid bullshit research programs that = try to "optimize" ustilization of link capacity at 100%. Those research = programs focus on the absolute wrong measure - a proxy for "network = capital cost" that is in fact the wrong measure of any real network = operator's cost structure. The cost of media (wires, airtime, ...) is a = tiny fraction of most network operations' cost in any real business or = institution. We don't optimize highways by maximizing the number of cars = on every stretch of highway, for obvious reasons, but also for = non-obvious reasons. I think it is important to distinguish between core/access networks and = last-mile links. The technical distinction is in the level of = statistical multiplexing - high in the former, low in the latter. The = cost structure to the relevant user is also significantly different. I agree with your analysis when it comes to core/access networks with a = high degree of statistical multiplexing. These networks should be built = with enough capacity to service their expected load. When the actual = load exceeds installed capacity for whatever reason, keeping latency low = maintains network stability and, with a reasonable AQM, should not = result in appreciably reduced goodput in practice. The relevant user's costs are primarily in the hardware installed at = each end of the link (hence minimising complexity in this high-speed = hardware is often seen as an important goal), and possibly in the actual = volume of traffic transferred, not in the raw capacity of the medium. = All the same, if the medium were cheap, why not just install more of it, = rather than spending big on the hardware at each end? There's probably = a good explanation for this that I'm not quite aware of. Perhaps it has = to do with capital versus operational costs. On a last-mile link, the relevant user is a member of the household that = the link leads to. He is rather likely to be *very* interested in = getting the most goodput out of the capacity available to him, on those = occasions when he happens to have a heavy workload for it. He's just = bought a game on Steam, for example, and wants to minimise the time = spent waiting for multiple gigabytes to download before he can enjoy his = purchase. Assuming his ISP and the Steam CDN have built their networks = wisely, his last-mile link will be the bottleneck for this task - and = optimising goodput over it becomes *more* important the lower the link = capacity is. A lot of people, for one reason or another, still have links below = 50Mbps, and sometimes *much* less than that. It's worth reminding the = gigabit fibre crowd of that, once in a while. But he may not the only member of the household interested in this = particular link. My landlord, for example, may commonly have his wife, = sister, mother, and four children at home at any given time, depending = on the time of year. Some of the things they wish to do may be = latency-sensitive, and they are also likely to be annoyed if = throughput-sensitive tasks are unreasonably impaired. So the goodput of = the Steam download is not the only metric of relevance, taken = holistically. And it is certainly not correct to maximise utilisation = of the link, as you can "utilise" the link with a whole lot of useless = junk, yet make no progress whatsoever. Maximising an overall measure of network power, however, probably *does* = make sense - in both contexts. The method of doing so is naturally = different in each context: 1: In core/access networks, ensuring that demand is always met by = capacity maximises useful throughput and minimises latency. This is the = natural optimum for network power. 2: It is reasonable to assume that installing more capacity has an = associated cost, which may exert downward pressure on capacity. In = core/access networks where demand exceeds capacity, throughput is fixed = at capacity, and network power is maximised by minimising delays. This = assumes that no individual traffic's throughput is unreasonably = impaired, compared to others, in the process; the "linear product-based = fairness index" can be used to detect this: = https://en.wikipedia.org/wiki/Fairness_measure#:~:text=3DProduct-based%20F= airness%20Indices 3: In a last-mile link, network power is maximised by maximising the = goodput of useful applications, ensuring that all applications have a = "fair" share of available capacity (for some reasonable definition of = "fair"), and keeping latency as low as reasonably practical while doing = so. This is likely to be associated with high link utilisation when = demand is heavy. > Operating at fully congested state - or designing TCP to essentially = come close to DDoS behaviour on a bottleneck to get a publishable paper = - is missing the point. When writing a statement like that, it's probably important to indicate = what a "fully congested state" actually means. Some might take it to = mean merely 100% link utilisation, which could actually be part of an = optimal network power solution. =46rom context, I assume you actually = mean that the queues are driven to maximum depth and to the point of = overflow - or beyond. - Jonathan Morton=