Case II: Real-time Video Broadcast

 

Assume we want to broadcast signed video on the Internet. The system requirements are as follows:

• The data rate of the stream is about 2 Mbps, about $512$ packets of $512$ bytes each are sent every second.
• Some clients experience packet drop rates up to $60\%$, where the average length of burst drops is $10$ packets.
• The verification delay should be less than $1$ second.

The high packet drop rate makes it difficult for signature packets to reach the receiver. To increase the likelihood of signature packets to arrive, we send them twice -- but within a delay, since packet loss is correlated. If we approximate the loss probability by assuming the signature packet losses are uncorrelated if they are sent within a delay, the probability that one of them arrives is approximately $1\; -\; 0.62=\; 0.64$. Since the packet loss is so high and verification delay relatively short, we send a a signature packet every $200$ packets. This translates to about $2.5$ signatures per second, which we consider as a low computational overhead. We assume that the signature packets have about the same size as the data packets, so in $512$ bytes we can fit one $1024$-bit RSA signature and the $80$ bit hash of $40$ previous packets.

We chose these parameters based on good engineering practice. To find better parameters for the number of chunks that the hash is split into and the number of chunks required to verify the packet, we used a simulation. The simulation shows that the best combination for this case uses $50$ bytes per packet to insert $25$ chunks of two bytes of the hash of previous packets. Including the signature packets, the average communication overhead is about $55$ bytes per packet. The simulation predicts the average verification probability over the final $2000$ packets of $97\%$, with the minimum verification probability $90\%$.