A Reflection of Customary Programming Languages & Adaptation of Latest Network Optimization Techniques

Editor’s Note: Below is a brief transcript taken from our dialogue with Martin Horčička, Engineering Manager at Akamai Technologies. The interview mainly talks about customary programming languages, and his early work around UNIX-like OS, networks and development. Martin also gave a few tips on multi-connection and P2P capabilities, and the UDP-based, secure transport protocol for HTTP optimization for networks relating to his current project with Akamai. You can find a Chinese version of this article here. Martin will give two topics in LiveVideoStackCon 2019 Shenzhen, and talk about The Challenges of Deploying HTTP over QUIC at Scale and QUIC Performance Optimizations.

Author / Martin Horčička

Planning / LiveVideoStack

LiveVideoStack: Hello Martin, firstly can you briefly introduce yourself to the LiveVideoStack readers and some technical details of your work currently?

Martin Horčička: Hi, I’m an engineering manager of the QUIC team at Akamai Technologies. My team is based in Prague in Czechia and we are responsible for providing a QUIC protocol implementation for integration into Akamai software, supporting the integration, deployment and performance tuning. We are part of the Protocol Optimization organization, focusing on improving and tuning network protocols.

Apart from long-term maintenance of compatibility with Chromium-based software and support of new Google QUIC versions, we currently work on several CPU usage optimizations, a mechanism for improving the QUIC performance on reconnections and most notably on the support of IETF QUIC. We expect that the work on IETF QUIC will be our most important set of tasks for 2020.

LiveVideoStack: Based on your work experience, we noticed that originally you started out as a Unix system administrator and moved up the ranks in becoming a software development engineer and engineering manager later on. Does a higher position or job level means that you no longer do basic coding?

Martin Horčička : Getting to software development over system and network administration at an ISP and operating system testing may seem like a long way, but I wouldn’t change it, because it provided me great opportunities to get familiar with software, networks and customer expectations from various perspectives and at various levels of details. I got the context and the experience needed for the next part of my career. All my jobs involved software development in some form. Moving on to dedicated development positions was thus a logical consequence.

My current managerial position doesn’t allow me to spend time on coding anymore and I admit that I miss it to some extent. On the other side, I stay in touch with the implementation at the architectural level, I’m involved in multiple interesting projects in parallel, I take part in setting our future direction and most importantly I can work with many very talented people.

LiveVideoStack: We know you have used C, Python, Perl, Shell and Java Programming Languages for software development. As a senior software development engineer, what’s your take on the development of programming language for the past few years?

Martin Horčička: As a user of mainly C++ for the last 9 years, I observed with pleasure that the evolution of this language has finally started to make steady progress. In the past, C++ first suffered from the lack of a standard and then from inability to move on. Now C++ gets regular updates and the problem with progress shifted to organizations that use it, because they often struggle with overcoming their resistance to change, in order to transition to a new standard every few years. C++ still has some inherent problems, though - mainly its complexity and the fragmentation of its users in opinions on how to use it well (e.g. with or without exception handling).Personally, I’m also missing the concept of “batteries included”, known from Python - i.e. getting a rich library along with the language - but I definitely know people who would disagree with me on that point.

It’s great to see new programming languages being developed and new ideas tested. In my opinion, they will surely benefit from not having to pull the weight of an ISO standard. On the other side, they may also suffer from being under control by one company. Anyway, I hope that one of them emerges to be a widely honored successor to C++ one day.

LiveVideoStack: Before that, you had even tested out Giga (a new form of UDP-based proprietary transport protocol), as we know QUIC was also a UDP-based low-latency internet transport layer protocol, what made you decide to stop working on Giga and switch your attention to QUIC instead?

Martin Horčička: Giga was our first entry into the area of UDP-based transport protocols. We rather rushed in with the idea of replacing the commonly used retransmission-based packet loss recovery mechanism by forward error correction (FEC). Gradually we got to understand that FEC is not a solution by itself, how complicated the environment of production network is and how carefully we need to progress with the transport protocol research and development. We learned a lot during that project.

Later, Akamai acquired Octoshape - a Danish company with solutions for video streaming acceleration. They brought another UDP-based protocol with interesting fusion of transport and application layers. It introduced concepts such as awareness of the played video bitrate in transport-layer decisions. We were considering ways of possible merging our two UDP-based protocols when Google announced their intention to have QUIC standardized under IETF. We welcomed it as an opportunity to join forces and move our optimization efforts from proprietary area onto a future standard base. We thus shifted our focus to QUIC and discontinued our older protocols gradually.

LiveVideoStack: UDP-based QUIC is most frequently compared with TCP-based SPDY, as these protocols and technologies exist mainly to solve data transmission problems. What do you think of the impending outcome that QUIC will replace TCP network eventually?

Martin Horčička: Even though SPDY evolved into HTTP/2, perceived as a successor of HTTP/1.1, we can’t really say that it replaced HTTP/1.1.Considering that TCP is incomparably more ubiquitous than HTTP, it isn’t going to leave us in the foreseeable future, in my opinion. TCP works great undermost conditions, it’s well known, widely supported and its operation is very efficient. QUIC was originally intended as an experimentation platform, from which the most successful features would be integrated into mainstream protocols. We could see how QUIC Crypto inspired TLS 1.3 with 0-RTT connection handshakes, for example. I believe that this trend will continue in some form and TCP will keep slowly evolving, benefiting also from the easier and faster experimentation possible with QUIC.

LiveVideoStack: Personally, how do you view the relationship between QUIC and TCP? The QUIC protocol holds the upper hand over the TCP in terms of higher efficiency, speed and utilizing less resources. What kind of implementation or adjustments can be made to QUIC to be optimized even further?

Martin Horčička: From our statistics, QUIC performs better than TCP in some cases and similarly or worse in others. So far, QUIC requires notably more resources (especially CPU) than TCP - the tens of years of TCP optimizations must be visible somewhere. From the perspective of a content delivery network operator, my view is pragmatic - let’s use QUIC when it brings notable benefits and let’s keep using TCP in the other cases. I believe that further improvements and optimizations will incrementally decrease QUIC’s resource usage and increase the percentage of cases when its use would be worth it, but I don’t think that TCP would be going away anytime soon.

From the areas of possible further optimizations, I would emphasize the support of large UDP traffic in operating systems’ kernels, network interface cards and surely also the QUIC implementation itself. We very much need to have QUIC specification finalized first, though, so that it would stop being a moving target to such a great extent.