/How changing the size of initcwnd affect the timestamps of an http/3 request

How changing the size of initcwnd affect the timestamps of an http/3 request

I am using Lubuntu as OS and in this blog QUIC, HTTP/3 and initcwnd will be defined. Then the changing of the initcwnd size and how it affects the timestamps will be shown.

QUIC(Quick UDP Internet Connections) is a new internet transport protocol that is encrypted by default planning of eventually replacing TCP and TLS on the web. QUIC has a lot of advantages such as accelerating HTTP traffic(low-latency connection establishment), make it more secure and reliable.

Several versions of HTTP are used currently with each newer version better than the old one. Nowadays HTTP/1.1 and HTTP/2 are widely used, while HTTP/3 is in the final stages of standardisation in the Internet Engineering Task Force (IETF). HTTP/3 is currently still being experimented on and support is offered by Cloudflare. HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocol. HTTP/3 permits use of a larger number of streams (2⁶²-1) than HTTP/2 which is managed by QUIC. HTTP/3 will perform the QUIC handshake and if successful issue the request.

Initcwnd(Initial Congestion Window) is the initial number of packets in flight across the network. The congestion window(cwnd) can either decreases, increases or stays the same depending on how many packets make it back and how fast they return after the initial burst. The TCP Congestion Control, similar to water flowing through a pipe, measures the pressure a network can withstand and then adjusting the volume in an attempt to maximize flow without bursting any pipes.

Now, to do the experimenting with initcwnd, we need to download quiche, which is an implementation of the QUIC transport protocol and HTTP/3, from github. For testing purposes I forked the repository first.

But you can download it directly with this command on the terminal :

git clone --recursive https://github.com/cloudflare/quiche

Enter the downloaded repository by using the “cd” command as shown above. Afterwards you will need cargo to be able to compile quiche, it requires Rust 1.39 or later to build. Cargo is the Rust package manager and it downloads your Rust package’s dependencies. So if you already have Rust installed, for cargo to be able to compile some commands need to be available. Those commands are “cmake”, “go” and “perl”. Then if cargo and these commands are installed, write this command to compile quiche:

cargo build --examples

Then if you wish to see if quiche has been compiled successfully run this code:

cargo test

Now to see the initcwnd value, we should enter this path:

cd src/cc

And then if you use the “ls” command you will see that there are two files namely “mod.re” and “reno.rs”. Use a text editor to open the “mod.rs” file which contains the initcwnd value.

As you can see above the value of “INITIAL_WINDOW_PACKETS” is set to 10.

Now to test it we need to send a HTTP/3 request to “cloudflare-quic.com” and we will use wireshark to watch the packets that are sent and came back.

Firstly, you have to enter this path from quiche:

cd target/debug/examples

Then open wireshark and start to capture packets, and run this code to send a request a HTTP/3 website:

RUST_LOG="info" ./http3-client https://cloudflare-quic.com

After that go on wireshark and observe only the QUIC protocols.

Observe the Timestamps of the packet and write it down.

Now we will change the initcwnd value to see if this affects the time it takes for the packet to come back.

Go back to this path:

Then use your text editor to edit the “mod.rs” file as shown below:

Put the initcwnd value to 4.

Now go back to quiche directory then again to this path:

Start to capture the packets using wireshark and make another HTTP/3 request with this command:

RUST_LOG="info" ./http3-client https://cloudflare-quic.com

After it is done, open wireshark to see the changes.

As you can see the Timestamps are less when initcwnd is decreased.

So, when the initcwnd is decreased from the original value, packets takes less time to come back and HTTP/3 request are faster.

A question that might be raised is, why didn’t they not already put the default value of initcwnd to 4? And since its default value is set to 10, it causes the blocking and resulting latency and jitter problem up to 2.5 times much worse. The jitter problem means networks that are overcrowded with traffic experience poor performance as too much bandwidth is being consumed by active devices. If initcwnd is set to higher value, Web latency during the slow start algorithm phase of a connection is reduced. The majority of connections on the Web are short-lived and finish before exiting the slow start phase, making TCP’s initial congestion window (initcwnd) a crucial parameter in determining flow completion time. If the initial congestion window is increased it will speed up short Web transactions while maintaining robustness. Then what is the right answer, should the initcwnd be set to 4 or 10?

So some advantages of increasing the initcwnd value are:

a) Reduce latency.
 Increasing init cwnd enables transfers to finish in fewer RTTs(number of Round-Trip Times).

b) Keep up with growth in Web page sizes.
 An average sized page requires multiple RTTs to download when using a single TCP connection with a small initcwnd. To improve page load times, Web browsers routinely open multiple concurrent TCP connections to the same server. Web sites also spread content over multiple domains so browsers can open even more connections. Increasing init cwnd will not only mitigate the need for multiple connections, but also allow newer protocols such as SPDY to operate efficiently when downloading multiple Web objects over a single TCP connection.

c) Allow short transfers to compete fairly with bulk data traffic.
 Internet traffic measurements indicate that most bytes in the network are in bulk data transfers (such as video), while the majority of connections are short-lived and transfer small amounts of data. Because short-lived connections, such as Web transfers, don’t last long enough to achieve their fair-share rate, a higher initcwnd gives them a better chance to compete with bulk data traffic.

In conclusion, increasing the initcwnd value has a lot of positive on Web transfer latency. A much simpler solution of increasing the initcwnd to a value recommended with current network speeds and Web page sizes is practical, easily deployable and immediately useful for enhancing Web latency transfer. In the future, a larger initial congestion window will also reduce the need for applications to use multiple concurrent connections to increase download speed.