If we look further into the pattern of packets being sent between the client and the server (the source of the file being transferred). We can plot the number of packets sent by the server to the client, since the last UDP packet was sent from the client to the server. Logically, the client must be providing feedback to the server about the rate at which it is receiving packets, since if packets are taking a long time to arrive there is probably a queue building up along the path between the server and the client - if so, then the server should lower its sending rate.

Time since the last UDP packet from client to source — Plot of the number of UDP packets from source ⇒ client since last UDP packet client ⇒ source. Note that a very large number of values fall along a horizontal line - with only a few points about this line. However, there are a lot of points below this line.

Transcript

So I got interested and said, Hum! Is there a pattern and I said, Well obviously the client is sending packets back to the server once in a while to give it information and then the server is deciding how many packets it should send because it wants to send packets at no faster rate than they successfully make it there, if packets are lost then it needs to reduce its rate. So here's the relative time between when the last UDP packet was sent from the client to the source and the number of UDP packets sent from the source to the client. And we see as expected that initially, they're both exchanging packets and the number of that are being sent by the server is slowly increasing until it reaches this plateau, and mostly it sends along at that rate, but sometimes it sends faster and we can see these examples of cases where it's such a burst of packets right after the clients had sent a UDP packet to it. And then we see this interesting looking what looks like a mess down here. Right. But if we actually look at that we can start to see "hum" there is a pattern to that.