Two sinograms – out of phase with each other – shaping the short burst lengths?
First, we notice that the median number of packets sent by the server since the last packet was sent by the client was 857. There were 963 bursts of packets sent in ~90 seconds. We can fit a curve to the two sinewaves. The parameters for these sinograms are shown in the table. A frequency of 0.121951 Hz corresponds to (1/8.2) Hz. Note also that this time is just a a lot shorter than the round-trip time (~176 ms).
Shorter bursts to detect congestion or decrease in BW?
| parameter | sinewaves a | sinewaves b | units |
|---|---|---|---|
| scale | 410 | 410 | packets since last packet from client |
| v_offset | 410 | 410 | 〃 |
| offset | 4.05 | 8.1 | seconds |
| frequency | 0.121951 | 0.121951 | Hz |
The equation for the sinewaves has the form: y(t)=scale×sin(2π×frequency×t+φ)×voffset
φ is computed using the offset in time
Transcript
I started to see a pattern that I recognize. And this is a pattern that is basically very commonly used; it is an "eye pattern" whenever you have two different phase sine waves that are interacting - such as you might see in the case of a transmitter where you have one signal in-phase and another signal out of phase. So we actually compute - if we can fit these two sine waves - so we see the "a" component here, and we see points following along that, and we see the "b" component here delayed a hundred eighty degrees out of phase with it. We can see the scale of them, they each have a scale of about 410. And one of the fascinating things is if we add together the sine and cosine, what do we always get? We get one. And so if you multiply that one times 410 plus 410 sure enough that gives us a rate that's just under the rate at which it is regularly sending these bursts - in the lengths of sending these burst and of course this leads us to hypothesize that these ones that are longer bursts are probing to see if we have more bandwidth. While these two other phase signals are basically trying to transfer UDP messages from the server to the client but by using different burst lengths we are able to see: Are the queues along the way nearly full or not? So are we causing congestion or not? Because if we send a large burst of UDP datagrams and the queue is quite full, of course, some will fall off the end; but we just wasted network resources sending those packets because of course they're not making it to the final destination, and therefore we send a smaller burst of packets which is going to make it to the destination but in order to find out what the actual fill level of all of these queues along the way, we need to be probing with longer and shorter bursts and that - I believe this is what we can see from this diagram.