> The protocol totally ignores drops, for flow control. Instead, it measures change in transit time. The receiver knows, the sender needs to know, but the useful lifetime of the measurement is less than the transit time. This should make an engineer think "control theory!" (and did). So, the receiver reports a stream of transit time samples back to the sender, which feeds them into a predictor, which controls transmission rate. Simple, in principle, but the wide Internet is full of surprises.
Would you be willing to talk more about this, for someone not as intimately-familiar with the details?
I've reported most of what I know. I was involved in the data layer. Flow control was done by the PhDs.
But, imagine the route as a series of packet queues. Packet is sent, arrives at the first router, spends time in the queue, gets sent, put on the next queue, waits, goes, until it's delivered. If the total time taken, compared to the last packet's, is more, that means the queues are growing. If the total time is less, the queues are shrinking. You adjust your rate to stabilize them. Other flows are being added and removed all the time, so the optimal rate varies in steps over the course of the session.
This involves control theory, Kalman filters, PID, the whole business.
As a general question, I'm curious how a tactile learner might be able to get a decent grasp of pretty much everything you just described, in a practical setting, without breaking the bank.
:)
How good is GNSS at simulating latency, buffer saturation, etc on a simulated network and how much complexity would I need to contemplate factoring in to build an accurate model of the average organically evolved, ad-hoc, multi-WAN-spanning sprawling corporate network?
I can't think of a more concrete, instructive starting point for someone interested in figuring out an alternative/reimplementation.
It really is a matter of learning the hard way the phenomena that show up on real networks in the wild. Aspera spent a decade incorporating responses to all these lessons into their code.
You can get 80% there quickly, 90% there in two years, but the rest is just hard. A versatile simulation environment feeding the algorithm with synthetic time events according to a configured schedule is probably the best way to ramp up quickly, but I don't know anything about GNSS.
One tricky phenomenon is bimodal and even N-modal delay samples from traffic split across different routes.
Around 2014, Aspera replaced most of the code wrapped around the algorithms to become much more nimble about applying them in more circumstances.
I see. I get the impression Aspera is built on a really simple solution, "pressure-adjusted" over a very long time to account for the fact that the real world isn't a vacuum :D
Hearing I can get to 80% quickly is encouraging from a MVP viability point of view, thanks. (And also from a fail-fast perspective; I've now gotten to wondering how much additional performance might be eked out of start-stop style traffic, and it's good to know it won't take long to find out whether the pursuit is worthless or not. Yay.)
I read the second half of that second paragraph as describing a network model simulation that "compiles" a particular routing graph/topology into a set-in-stone sequence of packet events that you then later analyze...? (I'm interpreting "the algorithm" is my target application code, and "synthetic time events" and "configured schedule" as hints at non-real-time pregeneration. This may be incorrect.)
Eek, the delay distributions you describe almost sound like they might be NP-complete to solve.
The idea of fast simulation is to feed just your sending-rate update algorithm with fake time samples, with nothing like actual packets anywhere, so you can get very quick evaluation of your algorithm's numerical behavior under a wide variety of conditions.
Routes tend to start monomodal and split and rejoin at specific times, so it is not usually as bad as you imagine. Also, the number of routes does not get large.
Would you be willing to talk more about this, for someone not as intimately-familiar with the details?