From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 7F7663B2A4 for ; Wed, 29 Sep 2021 06:55:41 -0400 (EDT) Received: by mail-wr1-x42f.google.com with SMTP id x20so3473799wrg.10 for ; Wed, 29 Sep 2021 03:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BgppMJTcyVKw58Vskn38VYiBA/3RFPHz2246/SraH5g=; b=E0DDeqly4n1JnrqJC/BR+HVhR8nwt3+a8w3NrSTUafhjm/khr971DZVZ8xYBYImRQD hILcscQNlQPXOkkrcSgiw8v5ls5BScrGpwhYAeL/f/fT850EVJ+0BTlGcmY/uVju7Wqj v7PE4bl5ob8ZeTAiRX8jYs9DUFyIlcsOc9CL+CPVKZ0lvddCb1dvwmh3eOwQpqwdUop4 W29itF0sr9Sb0xd9BHqrFy1unhOo7HQsxVA0YgtU2vFppj/6v1PZlXLf6J7j8ZlIMsId tk6swokzWFXon8zJgYHN1im4I5EeQ0DRVTiROVSCy889xUYH/3jbyeypWx1xkLNOGwxX tBPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BgppMJTcyVKw58Vskn38VYiBA/3RFPHz2246/SraH5g=; b=TiSK3ktNXFO56N5oWxfeNhohYVgff4HHEVZRvEnEj38lcrOQwXCDRhW1j4T81MlRPu oF71eoNUxjbFhOsKATRpoE3Gdh7OvPitJUOktlZx6DdV7u7nBUcPAWnqiKWonZdl3tQ1 5e28A1utAuhRum43zRB+qRqid2F6lIyPrBBF8KPwKsFN3Ytpu6soir9j3lTpbcFpWwot oaPDDMdRnbq4b7MxQcZX9ALz/pjf8H928ylrdrXKWfV9MQlotjy6LNKsl9BKWu7Atpbx NR0t7xEDyDsfUHYIJq5YPnSduJOy7u1pkO9X5kkKaU591PEX/ItJ3Xqz7N/yTkPr6cMx 76wQ== X-Gm-Message-State: AOAM532JPYMuxv5N+vBRK6e+tdFFytdVr5bub6fLd4j2cqGUCXOObpkq ieJAGfX8zWOiqoA6V1asEABzwYkpcRDyLFUm3UsUaQ== X-Google-Smtp-Source: ABdhPJwtxQRPVUZum5CV/KlAuPyxL2PIdXiy3e5FHj0DObUwLg/VhAZBZhHu+HLSq0E2Rcxagb7GDKTeiL5Nqyt6omQ= X-Received: by 2002:a5d:58d0:: with SMTP id o16mr5847883wrf.214.1632912939574; Wed, 29 Sep 2021 03:55:39 -0700 (PDT) MIME-Version: 1.0 References: <1632867355.4986972@apps.rackspace.com> In-Reply-To: From: Vint Cerf Date: Wed, 29 Sep 2021 06:55:27 -0400 Message-ID: To: Jonathan Morton Cc: "David P. Reed" , "Mohit P. Tahiliani" , ECN-Sane , Asad Sajjad Ahmed Content-Type: multipart/alternative; boundary="000000000000b71c5f05cd202b81" 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:55:41 -0000 --000000000000b71c5f05cd202b81 Content-Type: text/plain; charset="UTF-8" fully congested: zero throughput, maximum (infinite) delay.... v On Wed, Sep 29, 2021 at 6:36 AM Jonathan Morton wrote: > > On 29 Sep, 2021, at 1:15 am, David P. Reed wrote: > > > > 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=Product-based%20Fairness%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. From context, I assume you actually mean that the > queues are driven to maximum depth and to the point of overflow - or beyond. > > - Jonathan Morton > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane > -- Please send any postal/overnight deliveries to: Vint Cerf 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice --000000000000b71c5f05cd202b81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
fully congested: zero throughput, maximum (infinite) delay= ....

v


On Wed, Sep 29, 2021 at 6:36 = AM Jonathan Morton <chromatix99= @gmail.com> wrote:
> On 29 Sep, 2021, at 1:15 am, David P. Reed <dpreed@deepplum.com> wr= ote:
>
> Now, it is important as hell to avoid bullshit research programs that = try to "optimize" ustilization of link capacity at 100%. Those re= search programs focus on the absolute wrong measure - a proxy for "net= work capital cost" that is in fact the wrong measure of any real netwo= rk operator's cost structure. The cost of media (wires, airtime, ...) i= s 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-ob= vious reasons.

I think it is important to distinguish between core/access networks and las= t-mile links.=C2=A0 The technical distinction is in the level of statistica= l multiplexing - high in the former, low in the latter.=C2=A0 The cost stru= cture to the relevant user is also significantly different.

I agree with your analysis when it comes to core/access networks with a hig= h degree of statistical multiplexing.=C2=A0 These networks should be built = with enough capacity to service their expected load.=C2=A0 When the actual = load exceeds installed capacity for whatever reason, keeping latency low ma= intains 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 ea= ch 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.=C2=A0 All the s= ame, if the medium were cheap, why not just install more of it, rather than= spending big on the hardware at each end?=C2=A0 There's probably a goo= d explanation for this that I'm not quite aware of.=C2=A0 Perhaps it ha= s to do with capital versus operational costs.

On a last-mile link, the relevant user is a member of the household that th= e link leads to.=C2=A0 He is rather likely to be *very* interested in getti= ng the most goodput out of the capacity available to him, on those occasion= s when he happens to have a heavy workload for it.=C2=A0 He's just boug= ht a game on Steam, for example, and wants to minimise the time spent waiti= ng for multiple gigabytes to download before he can enjoy his purchase.=C2= =A0 Assuming his ISP and the Steam CDN have built their networks wisely, hi= s last-mile link will be the bottleneck for this task - and optimising good= put 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.=C2=A0 It's worth reminding the gig= abit fibre crowd of that, once in a while.

But he may not the only member of the household interested in this particul= ar link.=C2=A0 My landlord, for example, may commonly have his wife, sister= , mother, and four children at home at any given time, depending on the tim= e of year.=C2=A0 Some of the things they wish to do may be latency-sensitiv= e, and they are also likely to be annoyed if throughput-sensitive tasks are= unreasonably impaired.=C2=A0 So the goodput of the Steam download is not t= he only metric of relevance, taken holistically.=C2=A0 And it is certainly = not correct to maximise utilisation of the link, as you can "utilise&q= uot; the link with a whole lot of useless junk, yet make no progress whatso= ever.

Maximising an overall measure of network power, however, probably *does* ma= ke sense - in both contexts.=C2=A0 The method of doing so is naturally diff= erent in each context:

1: In core/access networks, ensuring that demand is always met by capacity = maximises useful throughput and minimises latency.=C2=A0 This is the natura= l optimum for network power.

2: It is reasonable to assume that installing more capacity has an associat= ed cost, which may exert downward pressure on capacity.=C2=A0 In core/acces= s networks where demand exceeds capacity, throughput is fixed at capacity, = and network power is maximised by minimising delays.=C2=A0 This assumes tha= t no individual traffic's throughput is unreasonably impaired, compared= to others, in the process; the "linear product-based fairness index&q= uot; can be used to detect this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://en.wikipedia.org/wiki/Fairness_measure#:~:text= =3DProduct-based%20Fairness%20Indices

3: In a last-mile link, network power is maximised by maximising the goodpu= t of useful applications, ensuring that all applications have a "fair&= quot; share of available capacity (for some reasonable definition of "= fair"), and keeping latency as low as reasonably practical while doing= so.=C2=A0 This is likely to be associated with high link utilisation when = demand is heavy.

> Operating at fully congested state - or designing TCP to essentially c= ome 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.=C2=A0 Some might = take it to mean merely 100% link utilisation, which could actually be part = of an optimal network power solution.=C2=A0 From context, I assume you actu= ally mean that the queues are driven to maximum depth and to the point of o= verflow - or beyond.

=C2=A0- Jonathan Morton
_______________________________________________
Ecn-sane mailing list
Ecn-san= e@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/ecn-sane


--
Please send any postal/ove= rnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd=C2= =A0
McLean, VA 22102
703-448-0965

<= div>until further notice



=
--000000000000b71c5f05cd202b81--