Referring also back to
https://forum.kitz.co.uk/index.php/topic,23994.0.html.
The slow start calculation can possibly use certain parameters that rarely change their values. In the case of a host at small / medium business or domestic LAN, the maximum bandwidth in/out may very well be limited by the first link upstream of the LAN gateway router so it’s hop 2 where hop 1 is across the LAN only or wireless lan. I keep thinking about the idea of a network info server, which could be in a gateway router if the software is upgrades or to have a new standard module plugged into it, or else in some other server discoverable by various zeroconf methods and perhaps using multicast with a well known address. This is not a million miles away from the idea of DHCP. One could query such an info server and ask it for an enum value for the current network use-case or topology situation, which could come back with "internet access bottlenecked by link, at hop 2" bandwidth = 1 Gbps inbound | 0.2 Gbps outbound. Those bandwidth bottleneck values would be the limiting values regardless of the path to the remote destination, provided that we are using NIC xx = LAN i/f or WLAN i/f. In the case of a wireless LAN though, hop 1 might be the true bottleneck so would have to combine the two potential bottlenecks of the ever-changing wifi performance and the throughput of the internet access link hop 2. A flag telling us that the hop 1 is very variable rate, in the case of a WLAN, therefore hop 2 is not the true bottleneck would mean that it is not easy to use hop 2 or hop 1 rates as guides in a slow-start equation.
I don’t know how intelligent one can be if one knows that the throughput up/downstream cannot exceed some value but otherwise the current value is either unknown or has to be obtained immediately either by some probing procedure - for which I don’t have an algorithm - or obtained immediately as an instantaneous current value from the info server. In that latter case there’s the problem of how up-to-date such dynamic performance figures might be - presumably they would be very iffy. It might just be best to only use the "cannot exceed x" type,of information and that might or might not be useful, but I don’t know of algorithms that could take advantage of such "limit" or "max possible rate figures. It could prevent a very aggressive and far from slow slow start from dumping far far too much data into a link upstream, only for it all to get dropped, and possibly forming a big queue whilst tying up a link outbound. But you presumably would still be too aggressive and be causing a problem with an initial overestimate of an upstream rate in your not very slow slow start. The alternative in the case of wifi is to forget any algorithmic ‘enhancements’ and just do normal slow start without the use of parameter caching from older sessions.
That scenario / use-case is the enum value #1 where you are a host in a domestic or similar LAN or WLAN attached indirectly to the greater internet by an internet access link. The other major scenario / use-case enum #2 is ‘direct attach server’. Here there is no internet access that is link like FTTP / FTTx or xDSL in the first scenario. Here we assume that you are a server whose throughput is limited by its own NIC(s) plus the bandwidth of the LAN that the server is living on. This has to be combined with the load of all the traffic coming into out of the NIC.
So that very variable rate limits the performance of the whole path. Either the server at the far end is ‘free’ or it’s having to also deal with a lot of other traffic from other client machines, and their traffic could be taking up an unknown fraction of the server’s capacity at its NIC.
So does that latter observation mean that cached parameters and their use in informing slow start is only doable if you have an algorithm that can make use of limits that is "max possible" values ?
One other kind of parameter that might be a candidate for exploitation in some algorithm informing slow-start using cached info is latency. To be completely clear, we probably want one-way trip time, not round trip time here. So given that the destination machine cannot be closer than our own ISP’s router first encountered when we’re going upstream to The Isle of Dogs, say, where all known servers live, and this is now assumed to be use-case. From that point we have to cross n other fast, low latency inks to get to our server of some sort on another network. Or in my case we could be coming all the way back up Britain to Skye again, which is where the remote machine lives, and it’s Janet my wife’s machine. So two light travel times up/down the north-south length of Britain for just one half of an RTT. So that’s why I need to bribe AA and BT into having POPs in Edinburgh at the internet exchange or even setting up POPs in Inverness. The latter probably isn’t worth doing just to get only the lesser improvement in latency of Skye-Inverness vs Skye-Edinburgh. It’s about 210 miles from Edinburgh to Broadford in Skye according to Apple Siri, and it’s about 85 miles from Broadford to Inverness. So I make that an improvement of quite a bit less than 1 ms, roughly a saving of 0.67 ms latency = for the one way trip.
The way that a latency figure might possibly be used is because if the latency is high then you’re safe to dump a larger amount of initial data into the network when doing a protocol CONNECT at the very beginning of a slow-start-type conversation. Also latency is reliable; unless you change NIC and with it the possible method you’re using to connect to the internet, then the latency never decreases. Having a safe minimum latency is excellent; and if it increases because of traffic or some path-change then no harm is done to our algorithmic considerations.
There is a general point here. Cached info has to be stored in multiple-instance objects, one for each tuple of ( NIC + ISP + etc ) = at a minimum thr method of attachment to the internet = the internet access link / path. There may need to be some other fields in that tuple that I’ve forgotten. Changing ISP might have all kinds of effects on the significant parameters. I ought to have included something like "per-WLAN" or per SSID, but really that should be something where you put SSID values into sets of attachment / location / site classes. Moving to a different site: home / work / hotel / café / public wifi service or some such will all involve different wifi performance limits and dynamic congestion traffic load levels plus differing ISPs too. Do changes to that tuple mean switching to a different entry in the cache of slow-start informing parameters, or no cached info at all. I seem to remember that MS Windows had classes of wireless LANs but they were three in number and were only to do with trust levels, not identifying ISPs or internet access link types or identifying performance types. That was a worthwhile design of Microsoft’s as straight away it made some righteous security decisions for the user and it was easy to understand. The enum class values were something like: "home" vs "work" vs "public-something-service" (untrusted) but perhaps a few additional types were needed. I’m thinking about Windows 7, which was when I gave up on the WinNT family for good and because a semi-bedbound Apple person.
I do think that it’s not necessary to be totally pessimistic and assume that slow-start cannot be somewhat improved give imperfect, "limit" / "max" throughput info and latency in the outbound one-way trip (ie half an RTT).
I would love to do some more work on the info-server idea. Maybe people have already said ‘just use DHCPv4’ and add extensions to it, but this has to work in IPv6 and I’m not a huge fan of DHCP and I’m not keen on the idea of stretching it that far, way way beyond what it was initially designed for. I’m not a fan of DHCPv6 either, plus the fact that few people use it. So I’d like to do a clean new design, and to keep sysadmins happy, I don’t want to be loading up the network with traffic on a large LAN. So initial ideas involve the use of multicast.
