Say that you need to download a file that is 1 GB. Does the source prefer to send it to you with the most bandwidth you can handle, minimizing connection time, or preserving bandwidth at the cost of a longer connection?
I’m thinking about this as I watch the 5G download speed on my phone. During the day at home I typically get around 1 to 5 megabytes per second. At I get up to around 30 MB/sec. Once I used it for a download in the city near a university and got 120 MB/sec.
5G uses several frequency bands. I do not know what the range is on those EHF links, but they can be blocked by walls, trees, etc. and if you do not have a good connection you cannot expect multi-gigabit bandwidth.
That in absolutely no way whatsoever touches on my question.
I think it is at least a superficially plausible explanation why your download speed is slower at home, behind four walls, versus walking around in the city with line of sight to a bunch of millimetre-wave antennas. The source is not throttling you down, it just gives you the bandwidth available in each case. ETA if there are too many users per cell, that is a different story; I do not remember what the algorithm is in that case.
My WAG is: the source has a fixed amount of bandwidth available. They share that between all clients connected at any time, so if there are only a few people downloading files, you get yours much faster than if there are many. There no point in throttling you to preserve unused bandwidth.
The second paragraph was an aside. It is not the question. Responses to why 5G speeds can vary are not addressing the question.
WAG is all I have to offer, but I’ll echo @beowulff just above. Each step in the network has their own interests and priorities and workloads. Which can affect your delivered speed.
The no-kidding original source server normally has just one goal: get all your bits off its list of shit to finish ASAP. Which means expending the maximum bandwidth available for as short a duration as possible. Having you tying up a connection port / thread / etc. for longer than minimally necessary is a loser for them.
The only potential issue comes in when the source ends up with more separate traffic streams than it has bandwidth to service fully. Then they can either starve some completely to feed the others, or load-level so everybody gets something, albeit more slowly than they might. To be sure the server would prefer this situation be transitory over seconds or maybe a couple minutes, not long-lasting for many minutes, much less hours.
Lots of effort goes into load-matching all the components in the bucket brigade of a major content provider. Anything relatively under-provisioned is a bottleneck that is wasting the other expensive assets that are relatively over-provisioned.
OK, there are a couple dozen congestion control algorithms listed just on this page
and there are some tradeoffs between latency and throughput, the question is what algorithm they are using and with what parameters.
There is one framework where one assigns a utility function which measures what utility a user gets by transmitting at a certain rate, and then one tries to optimize the sum of the utility over all users.
This is exactly the type of answer I was wanting, and the answer that I suspected–they prioritize freeing up the connection over conserving bandwidth, because connections are the more limited resource.
Ideally they have enough of each versus the instantaneous demand.
But the failure, or at least slow-down, scenario occurs when they’re short of either or both. Running out of free connections manifests to the user as an unresponsive dead website. Running out of free bandwidth manifests as slow responses and slow downloads. The latter is more customer-friendly up to a point.
If the system gets into a sorta-jammed up state due to too many hogging connections that won’t release since they all want very large = long-duration downloads, one of the response steps is to shit-can some or all of those, breaking the logjam of long-running downloads. Which is where / why restartable download protocols get layered on top of TCP.
Conceptually, it’s a variation on the lock convoy problem. From the early days of multi-tasking it’s been known that stuff gets pathological as soon as you can’t service requests at least as fast as they’re arriving. So don’t go there if at all possible, because every possible cure has bad side effects.
Whether it’s CPU interrupts, OS locks, OS thread context switches, server TCP connections, or server file downloads, if you can’t keep up it’s gonna get ugly with even a small backlog quantity-wise. Which backlog could be measured in nanoseconds or maybe even minutes depending on what thing is backlogged.
The real answer is that there are many factors that influence internet download speed. There are physical links which have a specific speed. No matter how fast the server link is, if the next hop has a slower link, then connection throughput will slow down. The network stack usually implements a fair queuing algorithm, so that all active connections get an equal opportunity to put data on the link. There may be a connection limit for the service. For TCP, factors such as the Maximum Transmission Unit and the TCP Window Size control how many bytes can be sent before the sender gets acknowledgment of bytes received. In complex networks packets can be rate limited by Quality of Service tagging, or by other policy systems that use packet inspection to classify traffic into rate classes.
An ISP might rate limit subscribers connections based on download caps, or active subscribers. Or they might just let congestion algorithms try to deliver fair access to all subscribers. That usually does not scale well, though, so most will implement some sort of traffic management.
A modern fly in the ointment is streaming media. Which in the current age is the big dog of traffic. Here the enemy is jitter in delivery. Protocols like WebRTC, and the underpinning RTP, expend a lot of effort in buffer management to try to avoid judder in presented audio and video, but also try to balance this against latency. Sudden high bandwidth loads on the connections are likely to cause lots of cascading problems, and unsatisfied customers either watching streaming movies or, especially, video conferencing.
So there is a lot of incentive for ISPs to look to shaping traffic to avoid sudden changes in load.
There is a lot of both art and science in managing loads, bandwidth and the provisioning of services.
The basic method developed in the early days of public internet was the Slow Start algorithm. Send the first data packets at a slow speed and keep increasing the rate of later packets until some start getting lost, at which point you back off a bit to narrow down on the optimum speed. This was in response to congestion problems cause by always running at full tilt which led to networks getting swamped by re-sending packets which had timed out at bottlenecks. This has been around for decades so may have been finessed more recently.
I’m not sure what you’re asking exactly. It’s all packet based, so AFAIK it doesn’t work like that.
You aren’t the only responder who seemed confused. The question, put more simply, is: do providers prefer a connection to be maximum bandwidth for minimum time? For instance, if you wanted a 1,000 MB file, would they prefer to give you 100 MB/s for 10 seconds or 10 MB/s of their bandwidth for 100 seconds?
The way that I understand it works is that from your phone/computer to your provider, you either get the fastest connection they can manage at that time, or whatever you’re contracted to get, subject to technical constraints- traffic, sunspots, signal strength, etc…
But that doesn’t extend all the way to wherever you’re getting your file from. Let’s say you’re downloading a file from the SDMB (hypothetically). Your phone is connected to the nearest cell tower at the fastest speed that it and the phone can manage. But from there, all bets are off. That cell tower is connected to your provider’s network by its own connection, which is subject to its own constraints- distance, traffic, etc… That network is composed of other routers that also have their own connections to each other all with their own constraints. Eventually that network may be connected to another telecom’s network, etc… all the way to the SDMB.
Your bandwidth is limited by the slowest link in that chain. So you may have a full-bore 5G connection to your cell provider, and their network may be super fast, but if wherever you’re downloading from has a slow segment, that’ll be your bottleneck.
A way to think about it is like the Postal Service. Your mailman may have a truck, the post office may have a fast sorting machine, fast trucks, put it on airplanes, etc… but if somewhere in there, there’s a slow sorting machine, some kind of extended drive, or a truck breaks down, etc… that is what’s going to delay your letter, no matter how fast your postman is, how good the roads between the post office and your house are, etc…
Your download is effectively like if you took a book and mailed each page separately to the destination, and the receiver put them back together in the correct order.
Edited
See, again, that is all irrelevant information and it is my fault for adding that irrelevant second paragraph to the OP. The question a very simple “which of these two options does the the original, first stage source prefer” (asked out of idle curiosity). The details of the complexities of multi-stage network connections aren’t part of it.
Put it even more simply, it is like I am asking “which do you like more, chocolate ice cream or vanilla ice cream”?
If I’m understanding, you’re asking how the connection between your phone and your provider works?
You are not understanding. I don’t think I can make my question any simpler so you probably should just drop it. (LSLGuy understood the question and gave a good response.)