Encryption overhead
What if we want to secure our data to hide as much as possible from the bad guys?
The answer here is to encrypt our payload, and, in Instant Connect's case, the RTP header as well. (ICE can't encrypt the UDP, IP, or Ethernet headers as the network then wouldn’t know how to deliver the datagram.)
For performance and security reasons, ICE uses the
Advanced Encryption Standard, or "AES", encryption algorithm which produces encrypted data in 16-byte blocks. So, if we encrypt 1 byte of data, our encrypted output is 16 bytes. If we encrypt 15 bytes, it is still 16 bytes. If we encrypt 16 bytes, however, the output is 32 bytes. If we encrypt between 16 and 31 bytes, the output is still 32 bytes. Encrypting 32 bytes, will produce 48 bytes of output. And so on. Basically, AES encrypts on 16-byte
boundaries. That extra padding (which varies in size) is going to affect the size of the data we're transmitting.
Also, ICE operates AES in what's known as
Cipher Block Chaining, or CBC, mode. And CBC requires that an extra blob of random data is added to the encrypted output—16 bytes of random data, in fact. This is known as the
Initialization Vector, or IV.
Together, the 16-byte block operation and the IV added to each packet substantially increases the size of the packet and therefore our bandwidth utilization.