Every now and then we get asked why our focus is so heavily on improving HTTP transport, instead of (say) the underlying TCP protocol. After all, TCP is used to haul around lots of other types of data besides HTTP, so wouldn’t it make sense to apply the IP-over-ICN technology to optimize those applications as well?

The crux of the matter is the savings in network capacity we expect to obtain[1]. HTTP has very clean semantics, and applications such as video transport often result in numerous requests for the same content in a short period of time. This provides us with a (small) window of opportunity to create ad-hoc multicast relations, based on our path-based forwarding approach, allowing us to deliver said content in a single multicast transmission, resulting in significant multicast gain and thereby saved capacity. Our experiments and simulations have thus far shown up to 80% reduction in bandwidth consumed by video transport through the use of this coincidental multicast technology. Let us see how significant such reductions would be in the Internet scale.

In developed countries, HTTP video transport currently takes over 65% of all network capacity, and Netflix alone is responsible for over 35% of all network traffic in the US[2]. The second largest application in terms of traffic consumption is Bittorrent, running on top of both TCP and UDP, with an approximately 20% share. All other TCP applications bundled together would come a distant third, with some 6-7% traffic share in total.

Suppose then that we were able to develop the ultimate TCP handler, that would magically transport the application payload for these other TCP applications from the senders to the receivers without consuming network resources at all. The 7% reduction in global network load that would be achieved is certainly nothing to sneeze at. However, just looking at the raw numbers, similar gains can also be achieved in the following alternative ways:

• Using coincidental multicast to reduce video traffic by just slightly over 10%.
• Reducing just Netflix traffic by 20%.
• Developing a native Bittorrent handler that would result in 30-40% capacity savings.

We hope the reader would agree that each of these three approaches sounds significantly more realistic than the described magic-tech TCP handler, especially when contrasted with the over 80% gains we have shown in a running system.

Finally, let us conclude by putting a small but persistent myth to rest. Every now and then we hear a claim that due to the lack of a dedicated TCP handler, our IP-over-ICN solution does not support general TCP applications. Nothing could be further from the truth. The very first component of our NAP that we developed was the general IP handler that supports anything that runs on top of IP, and does so with similar performance to native IP. In fact, our very first demonstrations showed that existing TCP services run just happily over our ICN core. But capacity-wise these services are not the big game. Video over HTTP is.

[1] Our flexible routing solutions can also be used for reducing latency and optimizing network performance in other ways, but these approaches are already protocol agnostic and work for TCP, UDP and other protocols in equal manner; thus we focus on capacity in this post.

[2] P. Richter et al., Distilling the Internet’s Application Mix from Packet-Sampled Traffic, Proc. of PAM 2015. Cisco VNI 2015. Sandvine Global Internet Phenomena 2015.