problem 15

Initial TCP congestion window:

to check for congestion, the sender will send 10 packets and wait for a response from all before sending any more.

Why?

if the receiver cannot handle the slow rate, it won’t be able to handle a faster rate, wasting the sender’s capacity
if there is broader congestion on the network, the sender will contribute to the problem, without getting any faster responses from the receiver
- in the worst case, causes network collapse
adaptive: find the fastest rate without causing congestion

So sender could send 10 packets small packets very quickly. If sending coast-to-coast, the fastest possible ACK would be 60 ms (RTT, round trip time).

but we also need to include the 3-way handshake
60 ms: SYN, SYN-ACK
60 ms: ACK/GET, ACK response
120 ms to get the first byte

So how much data in the initial window?

10 packets * 1440 bytes / packet = 14400 bytes = 14.4 KB

So if the sender could packet an entire website in that window, the receiver would be able to load the website in 120 ms rather than 180 ms or more (saving at least one round trip time).

I think that’s reasonable for a small static blog:

1 character / byte * 5 words / character * 500 words = 2500 bytes
I honestly don’t have a good estimate for the size of HTTP headers, HTML, CSS, etc. But I can’t imagine it being more than 2500 bytes.
So if each component is 2500, then 2500 * 4 = 10000 bytes = 10 KB! We could send the entire page in the initial congestion window.

Let’s check the math by looking at the size of my blog:

my homepage is 2KB
- 688KB if you count my font! Maybe I should use a standard one…
a post with lots of JavaScript animation and svgs is 161KB
my most popular post full of gifs is 7.5MB!
a basic, text-only post is 8KB

I’m very happy to send imagines and JavaScript animations, but the font is way more than I thought! I might have to go through some of the standard fonts again.