<div dir="ltr">fully congested: zero throughput, maximum (infinite) delay....<div><br></div><div>v</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 29, 2021 at 6:36 AM Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On 29 Sep, 2021, at 1:15 am, David P. Reed <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>> wrote:<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
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.<br>
<br>
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:<br>
<br>
<a href="https://en.wikipedia.org/wiki/Fairness_measure#:~:text=Product-based%20Fairness%20Indices" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Fairness_measure#:~:text=Product-based%20Fairness%20Indices</a><br>
<br>
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.<br>
<br>
> 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.<br>
<br>
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.<br>
<br>
- Jonathan Morton<br>
_______________________________________________<br>
Ecn-sane mailing list<br>
<a href="mailto:Ecn-sane@lists.bufferbloat.net" target="_blank">Ecn-sane@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/ecn-sane" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/ecn-sane</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Please send any postal/overnight deliveries to:</div><div>Vint Cerf</div><div>1435 Woodhurst Blvd </div><div>McLean, VA 22102</div><div>703-448-0965</div><div><br></div><div>until further notice</div><div><br></div><div><br></div><div><br></div></div></div>