Got Speed?

Every protocol has a limit on how quickly it can deliver things.

So how does Fenrir compare to the classical TCP?

The theory

The theory is quite simple. The Bandwidth delay product states that:

Bandwidth * Delay = Maximum data in travel

That is, the maximum amount of data non acknowledged at any given time has a maximum.

This is very important for satellite links, were there might be enough bandwidth, but the delay greatly limits the amount of bandwidth that can be used.

TCP limits

TCP was not thought with satellite links in mind, and had a maximum receiving window of only 2^16 bytes. By the bandwidth delay product, this means that we were limited to 116 KB/s when using geo stationary satellite links.

This was not very good, so a TCP option was introduced to lift the limitation by shifting the receiving window up to 14 times, bringing the total data in transit closer to 2^30, and thus the total usable bandwidth of the TCP connection was around 1.8GB/s.

Fenrir limits

In Fenrir we don’t specify the receiving window per each stream in every packet, as that is handled in the control stream.

The default maximum counter in the stream is 2^30 bytes. That gives us a top speed of about 1.8 GB/s on a 550ms satellite link. That is slightly more than TCP, as we can use the full 30 bits instead of shifting the 16 bits, as that would force the 14 less significant bits to zero.

But we are not finished yet! TCP only has a single stream, but in Fenrir we actually have up to (2^16)-1 user streams that can transfer data concurrently, and all of this brings the maximum transfer speed of Fenrir to 116 TB/sec on a single connection.

Still, this is a only side-effect of how Fenrir handles transfers, it wasn’t a design objective. Currently the top-of-the-line satellites have a total bandwidth of about 140Gb/s (~17.8GB/s), meaning they could handle almost 10 full-bandwidth TCP connections. …or a single Fenrir connection working at .015 % of its maximum capacity.

…Got speed?

-Luker