Earlier quoted context omitted.
> 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 transmi…
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 le…
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.