https://blog.apnic.net/2022/05/24/tcpls-modern-transport-services-with-tcp-and-tls/ Skip to content * Blog search [ ] Search Advanced Whois * Advanced Whois * Make a payment * Login * Select APNIC Direction + APNIC + Training + Academy + Blog + REx--The Resource Explorer + NetOX + DASH APNIC APNIC home * Get IP + Get IP Addresses / ASN + Make a payment + Membership + FAQs * Manage IP + MyAPNIC + Transfer IP and ASNs + Using Whois + Go IPv6 + Reverse DNS + Routing Registry + Make a payment + FAQs * Training + About + Events + Courses + Sponsor + Fees + Videos + Community Trainers + APNIC Academy * Events + Conferences + Calendar + Sponsorship + Code of Conduct * Research + Labs + REx--The Resource Explorer * Community + Policy Development + Addressing policies + Internet community + Code of Conduct + Technical Assistance + Root servers + Security at APNIC + ISIF Asia + APNIC Foundation + NRO NC + Mailing lists * Blog * Help Centre * About + APNIC Region + APNIC Membership + Executive Council + Service updates + Team + Annual Reports + Transparency + APNIC Survey + Corporate Documents + Publications Archive + Careers + Glossary * Contact * Select APNIC destination + APNIC + Training + Academy + Blog + REx--The Resource Explorer + NetOX + DASH * Login Skip to the article TCPLS: Modern Transport Services with TCP and TLS By Florentin Rochet on 24 May 2022 Category: Tech matters Tags: Guest Post, QUIC, TCP, TLS Tweet Blog home [TCPLS_DroneChopper_Banner-555x202] TCPLS is an intertwined TLS1.3/TCP design that we developed with colleagues from UCLouvain and ULiege. If you have never heard about TCPLS, the first thing that might come to your mind is "What does the acronym mean?" Much like QUIC, TCPLS is not an acronym. It simply conveys the idea that bringing TCP and TLS closer brings benefits to network applications. Some of the features of TCPLS can be found in QUIC, yet the two protocols have significant differences. In our last post, we wrote about the initial research steps we took in developing TCPLS. In this post, I'd like to present the similarities and differences to QUIC, backed by some experimental results. Why QUIC is amazing Both QUIC and TCPLS are modern transport protocols -- they offer an interface to modern transport services to the application layer. QUIC was designed at Google and has evolved with the involvement of many actors through the IETF standardization process. QUIC is great. Everything is implemented in userspace, which means that QUIC's lifecycle can follow the application's lifecycle that embeds it. It offers more control to their designers, assuming they're distributed the same way. Moreover, QUIC embeds cryptographic techniques to secure the application payload and secure its header and control information. This last bit is a truly awesome thing about QUIC. Wait? Why would it be useful to make confidential protocol information? Nobody cares right? This is not confidential information, it is just boring fields! You know what? You're right, nobody cares about confidentiality for protocol specifications, except in some privacy-preserving models that care about uniformity (and not confidentiality!) but that is not the point I'd like to make here. What we care about as engineers and practitioners is that the protocol works on the Internet. And we want the protocol to be extensible, which means that it should also work in the distant future for potentially unexpected novel needs supporting extended features. To achieve this, QUIC, like TCPLS, takes advantage of another property of cryptography algorithms. Modern Cryptographic algorithms are said to be probabilistic. Basically, they're randomized algorithms producing an output that looks random for anyone that does not hold the secret. And if you apply twice the algorithm to the same input, you should also get a different, totally random output that can only make sense for the secret holder(s). And that's exactly the property we require for header information; it should look random and be unpredictable to avoid anyone on the path deriving any assumption about its inner workings. Such assumptions can become wrong with time, and contributes to Internet ossification, breaking the ability to extend or change how protocols work over the Internet. QUIC solves the extensibility issue that TCP has. And you know what? Since TLS 1.3, we can do the same for TCP! TCPLS is even more amazing TCPLS solves the same issue as QUIC, is in userspace, provides new and modern transport features that directly work on the Internet, and is ensured to work through time thanks to the randomized protocol information. But unlike QUIC, which works above UDP, TCPLS takes advantage of decades of performance optimizations made to TCP and has also a few other tricks up its sleeves. What about the famous Head of Line (HoL) blocking avoidance that QUIC provides with independent transport streams? TCPLS has that too! TCPLS provides a stream abstraction to the application layer. Those streams can be steered over different TCP connections belonging to the same TCPLS session, or multiplexed over the same TCP connection. That's up to the application to choose. The TCPLS design offers an extremely lightweight trick to join together multiple TCP connections, and have independent cryptographic contexts derived from the same key. These different crypto contexts are a requirement for HoL blocking avoidance because we need the different connections to encrypt and decrypt independently. Illustration showing how the AEAD Nonce of TCPLS Streams is derived from TLS 1.3.Figure 1 -- The AEAD Nonce of TCPLS Streams is derived from TLS 1.3. Illustration showing how TCPLS supports joining additional TCP connections to a TCPLS session.Figure 2 -- TCPLS supports joining additional TCP connections to a TCPLS session. The SESSID and COOKIE in the Server-Hello are encrypted with the handshake key. Assuming we use TCP TFO, TCPLS also has a 1-RTT initial handshake, as QUIC does. It provides multipath capabilities similar to MPTCP straight out of the box and connection migration and handover due to an outage (we call that feature failover). Bandwidth aggregation or regular 1-path connections is also a choice up to the application to make. Some could benefit from multiple IP paths, others do not care, and that's fine when options are on the table! Graph showing recovery delays of TCPLS compared to MPTCP during a single outage.Figure 3 -- Recovery delays of TCPLS compared to MPTCP during a single outage. Let's compare the pair Recently, we conducted a few benchmark experiments to compare TCPLS with a few QUIC implementations. The testbed consisted of three servers equipped with an Intel Xeon CPU E5-2630 2.40 GHz. Two of these machines are used as a client and a server, and the third one is used as a middlebox on the path. Each machine was equipped with an Intel XL710 2x40 Gbps NIC. For all experiments, with all implementations, we used a single thread on each machine to run the client and server. Illustration showing the performance measurements setup, which includes a client, a server and a router/middlebox.Figure 4 -- Performance Measurements Setup. C = Client. S = Server. R = Router/ Middlebox. Bar graphs showing the throughput comparison between TCPLS, TCP/TLS, and three QUIC implementations.Figure 5 -- Throughput comparison between TCPLS, TCP/TLS, and three QUIC implementations. The TCPLS prototype is faster than several major QUIC implementations while offering a superset of transport services and similar flexibility. So, what can potentially explain TCPLS >= 2x QUIC's raw throughput? There are a few technical reasons: 1. QUIC uses UDP. Because of this, QUIC packets encrypt at once and at best 1,472 bytes of payload to hold over a standard MTU. However in practice, that can break over the Internet, and Google QUIC deployment has found 1,350 bytes to be a good compromise that would reduce the likelihood of a broken connection. This is low compared to the maximum 16,384 bytes that a TCPLS packet can handle, which means that using the same crypto algorithm over QUIC and TCPLS, encryption and decryption of a stream of data goes faster on TCPLS. 2. The UDP stack is much less performant than the TCP stack. The most prominent example of this is the sendmsg/recvmsg interface that can handle only one UDP packet per call. These are system calls. Calling them too often implies a serious performance penalty due to the context switch between the kernel and the userspace. This context switch on Linux has been made more costly recently due to an implemented defence against the Meltdown exploit. This has a worse impact on QUIC than TCPLS because QUIC requires more context switches to carry the same quantity of data than TCPLS. 3. Continuing on the previous issue, QUIC has all of its transport logic within the userspace. TCPLS has some of its transport logic still within the kernel. The reliability of the stream is still ensured by the TCP kernel implementation and no context switch is required to ensure reliability. QUIC does context switching for data reliability, which implies a penalty. For TCPLS, in the failover case, some TCPLS-level acks are still required to be processed. However, the frequency for a connection reliability property is much less demanding than acknowledgment strategies for data reliability. 4. TCPLS has better support for transport offload in existing network interface cards (NICs). TCPLS uses TCP segmentation offload (TSO), which is implemented into the NIC. QUIC uses Generic Segmentation Offload (GSO), which is a software strategy in front of the NIC. 5. TCPLS's design supports a contiguous zero-copy receiver. QUIC does not. At best, QUIC can support a fragmented zero-copy strategy, which has reduced performance and is more difficult to manipulate. However, the tricks we developed within TCPLS to enable a contiguous zero-copy receiver can be ported to the QUIC design. A sixth reason that we could not evaluate -- the Internet is more TCP friendly. Firewalls and other middleboxes are used for TCP but disregard UDP packets in many similar usage scenarios, potentially leading to connection reachability issues and performance downgrades. The impact of this on QUIC is yet to be determined and understood. All in all, we see why TCPLS outperforms QUIC. We are impressed by the raw performance some of the QUIC stacks have achieved, especially MsQuic and Quicly, given the handicap they start with. It is possible that, with time, the gap between QUIC and TCPLS shortens. However, we're unconvinced, from the reasons described above, that QUIC could ever catch TCPLS without losing part of its current identity in the process (for example, its userspace flexibility). Oh, and guess what? TCPLS can be written from any existing TLS 1.3 library. Everything can be efficient, effective and quick to develop! Learn more about TCPLS from our research paper with my colleagues Emery Assogba, Maxime Piraux, Korian Edeline, Benoit Donnet and Olivier Bonaventure. We are also making ongoing efforts to propose a design to the IETF. We welcome feedback to help us make this a reality! Contributors: Maxime Piraux, Korian Edeline, Benoit Donnet. Florentin Rochet is an Assistant Professor in Computer Security at the University of Namur and a researcher in privacy and security mainly applied to computer networks. Rate this article Discuss on Hacker News --------------------------------------------------------------------- The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog. Leave a Reply Cancel reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment * [ ] Name * [ ] Email * [ ] [ ] Save my name and email in this browser for the next time I comment. [ ] Yes, add me to your mailing list [ ] [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] Top Get Updates Please leave this field empty[ ] Email *[ ] Show options [Subscribe!] Select list(s):[ ] Daily[*] Weekly Thanks for subscribing! Check your inbox or spam folder to confirm your subscription. Authors * Geoff Huston * Paul Wilson * A Khalil Azizi * AbdelRahman Abdou * Abhishek Jain * Achie Atienza * Adam Gosling * Adam McFillin * Adam Oest * Adeel Sadiq * Adiel Akplogan * Adisorn Lertsinsrubtavee * Adli Wahid * Adrian Wan * Afifa Abbas * Afsheen Saadat * Aftab Siddiqui * Agustin Formoso * Ahmad Darki * Ajay Kumar * Akimichi Ogawa * Alan Mauldin * Alden Hilton * Alec Muffett * Alex Band * Alex Boten * Alex Turing * Alex Yen * Alexander Azimov * Alfred Arouna * Ali Abedi * Ali Norouzi * Amaury Van Bemten * Amrita Choudhury * Anand Buddhdev * Anant Shah * Andra Lutu * Andre Gelderblom * Andreas Dewes * Andreas Reuter * Andree Toonk * Andrei Robachevsky * Andrew Campling * Andrew Cushen * Andrew Gray * Andrew Sullivan * Andrew Toimoana * Andy Mindnich * Andy Newton * Anju Mangal * Anna Maria Mandalari * Annaliza Mulingbayan * Anosh Khan * Anriette Esterhuysen * Anthony Lee * Anton Strydom * Anup Changaroth * Anurag Bhatia * APNIC * Apoorv Shukla * Arash Molavi Kakhki * Arian Niaki * Aris Tzermias * Arjuna Sathiaseelan * Arth Paulite * Artyom Gavrichenkov * Asad Ali * Asanka Sayakkara * Ashil Oogarah * Ashwin Kumar * Ashwin Rangan * Audrey Randall * Aurelien Aptel * Austin Hounsel * Austin Ruckstuhl * Avery Pennarun * Ayesha Iftikhar * Ayush Mishra * Azfar Adib * Azhar Khuwaja * Azura Mat Salim * Baojun Liu * Baptiste Jonglez * Barry Greene * Bart Hogeveen * Basileal Imana * Ben Cox * Ben Du * Benjz Gerard Sevilla * Benno Overeinder * Bert Hubert * Bhadrika Magan * Bhumika Sapkota * Bikram Shrestha * Bill Hess * Bill Stearns * Bill Woodcock * Bjorn Teigen * Blake Anderson * Blas Trigueros * Brenda Buwu * Brenden Kuerbis * Brent Carey * Brian Carpenter * Brian Nisbet * Brian Trammell * Bruce Spang * Byambajargal Jamsran * Byron Ellacott * Byungjin Jun * Cameron Steel * Carsten Strotmann * Caspar Schutijser * Cecilia Testart * Cengiz Alaettinoglu * CF Chui * Champika Wijayatunga * Che-Hoo Cheng * Cheeyong Tay * Cherie Lagakali * Chia Ling (Jolin) Chan * Chika Yoshimura * Ching-Heng Ku * Chris Amin * Chris Ritzo * Christian Giese * Christoph Dietzel * Chuan Jiang * Ciprian Popoviciu * Clarence Filsfils * Claudio Jeker * Clemens Mosig * Colin Perkins * Constance Bommelaer * Constanze Dietrich * Craig Miller * Craig Ng * Craig Rowland * Dale Roberts * Dan Fidler * Dan Li * Daniel Kopp * Danilo Giordano * Danny Alex Lachos Perez * Danny Pinto * Daryll Swer * Dave Mill * Dave Phelan * David Anderson * David Burkett * David Dawson * David Holder * David Holsgrove * David Huberman * Dean Pemberton * Debashis Pal * Debopam Bhattacherjee * Deepak Vasisht * Denesh Bhabuta * Dennis Baaten * Desiree Miloshevic * Dewangga Alam * Dewole Ajao * Dhruv Dhody * Di Ma * Diego Pino Garcia * Dmytro Shypovalov * Donatas Abraitis * Doug Madory * Doug Montgomery * Dr Bahaa Al-Musawi * Dr Govind * Drikus Brits * Duane Wessels * Duncan Macintosh * E. Marie Brierley * Ed Horley * Edward Lewis * Edwin Sandys * Eliot Lear * Elizabeth Krumbach Joseph * Elly Tawhai * Elvin Prasad * Emile Aben * Emily Stark * Emir Beganovic * Eneken Tikk * Enno Rey * Enric Pujol * Eric Lawrence * Eric Loos * Eric Vyncke * Erik Hjelmvik * Erik Rye * Erin Scherer * Eshaan Bansal * Esteban Carisimo * Eunju Pak * Fabian Bustamante * Fakrul Alam * Farha Diba * Ferenc Fejes * Fernando Gont * Flavia Salutari * Flavio Luciani * Florentin Rochet * Florian Streibelt * Foy Shiver * Francesco Sassi * Franck Martin * Frane Maroevic * Frank Denis * Frank Herberg * Franziska Lichtblau * Fred Christopher * Fred Templin * Ganga R Dhungyel * Gaurab Raj Upadhaya * Gautam Akiwate * Gavin Reid * Geoff Huston * George Kuo * George Michaelson * George Odagi * George Sadowsky * Giacomo Giuliari * Gianmarco Pagani * Giovane Moura * Gonchig Altansukh * Gordon King * Greg Ferro * Gregory Mounier * Guangliang Pan * Guillermo Baltra * GZ Kabir * Ha Dao * Han Zhang * Hannah Durack * Hanno Bock * Harish Chowdhary * Helen Hollins * Hideyuki Sasaki * Hinne Hettema * Hiroki Kawabata * Hiroko Kamata * Hiromu Shiozawa * Hisham Ibrahim * Hoang Nguyen Phong * Houlin Zhao * Hyojoon Kim * Ignacio Castro * Ihita Gangavarpu * Ike Kunze * Ilker Nadi Bozkurt * Imtiaz Rahman * Ioana Livadariu * Italo Cunha * Ivan Ristic * Ivana Tomic * Ivo A. Ivanov * Ivy Yip * Izumi Okutani * Jaclyn Knight * Jacob Davis * Jahangir Hossain * Jake Bauer * Jake Flint * Jake Holland * James Ah Wai * James Pavur * James Richards * James Shank * Jamie Gillespie * Jan Harm Kuipers * Jan Ruth * Jan Zorz * Jan-Piet Mens * Jari Arkko * Jason Livingood * Jason Smith * Jasper den Hertog * Jawad Ahmed * Jay Daley * Jay Ford * Jeff Fry * Jeff Man * Jen Linkova * Jenine Beekhuyzen * Jerry Lundstrom * Jessica Shen * Jessica Wei * Jethro Webston * Jia-Rong Low * Jim Forster * Jim Vella * Jimmy Lim * Jing Qiao * Joanna Kulesza * Joao L. Sobrinho * Joao Luis Silva Damas * Joao M. Ceron * Job Snijders * Joel Jaeggli * Johanna Amann * Johannes Krupp * Johannes Weber * Johannes Zirngibl * John Bambenek * John Garrity * John Jack * John Kristoff * John Scudder * John Welborn * Jonathan Brewer * Jordan Carter * Jordan Jueckstock * Jordi Palet Martinez * Josef Gustafsson * Joseph Salowey * Joy Chan * Joyce Chen * Juan Ramon Santana * Juha Saarinen * Julia Evans * Julian Martin Del Fiore * Julien Gamba * Jun Murai * Kaajal Kumar * Kaan Onarlioglu * Kanagaraj Krishna * Karel Hynek * Karl Lovink * Karla Skarda * Kasek Galgal * Kashyap Thimmaraju * Kathleen Moriarty * Katsuyasu Toyama * Kazunori Fujiwara * Ke Ma * Keisuke Kamata * Kemal Sanjta * Kenjiro Cho * Kenny Huang * Kenrick Lin * Kensuke Fukuda * Kevin Bock * Kevin Ku * Kevin Meynell * Kevin Vermeulen * Kevon Swift * Keyu Man * Khee Hong Loke * Klee Aiken * Kobayashi Masayuki * Koen van Hove * Koichi Kunitake * Koki Nakagawa * Konrad Wolsing * Korian Edeline * Kostas Zorbadelos * Kris Shrishak * Kurt Lindqvist * Kyle Drake * Kyle Schomp * Lan Wei * Lars Prehn * Lars-Johan Liman * Leandro Bertholdo * Leandro Navarro * Lee Howard * Leo Vegoda * Leonid Todorov * Leslie Daigle * Lia Hestina * Liang Wang * Liangcheng Yu * Linjian Song * Lisa Corness * Lisandro Ubiedo * Liz Izhikevich * Loba Olopade * Lorenzo Cogotti * Louise Tromp * Luca Sani * Luuk Hendriks * Maarten Botterman * Maciej Korczynski * Madeline Carr * Maemura Akinori * Mai Thu Thuy * Major Hayden * Manaf Gharaibeh * Mansour Ganji * Marc Bruyere * Marcin Nawrocki * Marco Chiesa * Marco Cilloni * Marco Hogewoning * Marcus Brinkmann * Marcus Keane * Maria Theresa Perez * Mariko Kobayashi * Marilyn Zhang * Mario Loffredo * Mark Andrews * Mark Karpilovskij * Mark Nottingham * Mark Prior * Mark Smith * Markus Dahlmanns * Markus Legner * Marten Porte * Martin Hannigan * Martin Hoffmann * Martin Langer * Martin Thomson * Martin Winter * Mary Rose Ofianga-Rontal * Masanori Yajima * Masataka Mawatari * Massimo Candela * Mat Ford * Matt Larson * Matt Oh * Matt Palmer * Matt Ringel * Matt Stith * Matthew Thomas * Matthias Wichtlhuber * Mattijs Jonker * Maxime Mouchet * Md Abdul Awal * Megan Baker * Melchior Aelmans * Merike Kaeo * Metin Acikalin * Michael Kende * Michael Patterson * Michael Rabinovich * Michael Schapira * Mika Kerttunen * Mike Kosek * Min Sung Jung * Minzhao Lyu * Miwa Fujii * Mohamad Dikshie Fauzie * Mohamed Boucadair * Mohammad Larosh Khan * Molay Ghosh * Moritz Muller * Mubashir Sargana * Muhammad Moinur Rahman * Muhammad Yasir Shamim * Muzamer Mohd Azalan * Nadir Hassan * Nafeez Islam * Nalini Elkins * Narayan G * Narelle Clark * Natale Bianchi * Nate Sales * Nathalie Romo Moreno * Nathalie Trenaman * Neta Rozen Schiff * Nick Buraglio * Nick Hilliard * Nick Janetakis * Nico Schottelius * Nicola Rustignoli * Nicole Wajer * Nihit Tandon * Nikolai Hampton * Nikos Kostopoulos * Nils Wisiol * Nirav Atre * Nurul Islam Roman * Nusenu * Nyamkhand Buluukhuu * Oky Tria Saputra * Olafur Gudmundsson * Olamide Omolola * Oliver Gasser * Oliver Michel * Olivier Tilmans * Omar Alrawi * Ondrej Caletka * Ondrej Sury * Otto Moerbeek * Pablo Hinojosa * Paolo Lucente * Paresh Khatri * Parkpoom Tripatana * Pasan Lamahewa * Patrick McManus * Patrik Faltstrom * Paul Dale * Paul Wilson * Pawel Foremski * Pawel Urbanek * Pedro Marcos * Pengxiong Zhu * Pete Sclafani * Pete Stevens * Peter Blee * Peter Hansteen * Peter Maynard * Peter Peele * Petr Spacek * Petros Gigis * Phil Lavin * Phil Mawson * Philip Homburg * Philip Paeps * Philip Smith * Philipp Jeitner * Philipp Richter * Pier Carlo Chiodi * Piotr Kijewski * Platon Kotzias * Pranav Kondala * Praneet Kaur * Pubudu Jayasinghe * Quincy Liao * Rachee Singh * Rafael Cintra * Raffaele Sommese * Raffaele Zullo * Rahul Makhija * Rajnesh Singh * Ralph Dolmans * Ram Sundara Raman * Ramakrishna Padmanabhan * Rami Al-Dalky * Ramin Yazdani * Ran Ben Basat * Ranysha Ware * Raquel Rugani Lage * Raskia Nayanajith * Ray Bellis * Rebekah Houser * Remi Gacogne * Rene Bakker * Rene Wilhelm * Renee Burton * Richard Cziva * Richard Jimmerson * Richard Nelson * Richard Patterson * Richard Read * Rick McElroy * Rishabh Chhabra * Robbie Mitchell * Robert Kisteleki * Roderick Fanou * Rohana Palliyaguru * Roland Meier * Roland van Rijswijk-Deij * Romain Fontugne * Ron Bonica * Ron Winward * Ronald van Kleunen * Roy Arends * Rudiger Birkner * Russ White * Ryan Beckett * Ryan Gerstenkorn * Ryo Nakamura * Sachin Ashok * Said Jawad Saidi * Said Zazai * Salvatore Cuzzilla * Samantha Douglas * Samit Jana * Samuel Steffen * Sandra Davey * Sandra Siby * Sangeetha Abdu Jyothi * Sanjaya * Sara Dickinson * Sarah Escandor-Tomas * Sarmad Hussain * Sarvesh Mathi * Sasha Romijn * Satoru Matsushima * Satoru Tsurumaki * Scott Hollenbeck * Scott Shenker * Sebastian Castro * Sebastian Zander * Seiichi Kawamura * Seluvaia Kauvaka * Seth Schoen * Shah Sahari * Shahee Mirza * Shahzeb Mustafa * Shamim Reza * Shamsullah Shams * Shane Alcock * Shane Kerr * Sheetal Kumar * Sheikh Md Seum * Shermaine Yung * Sherry Shek * Sheryl Hermoso * Shian-Shyong Tseng * Shinoj Pittandavida * Shishio Tsuchiya * Shuai Hao * Shucheng Liu * Shumon Huque * Shusei Tomonaga * Siena Perry * Simon Baroi * Simon Bauer * Simran Patil * Siva Kesava * Sivaram Ramanathan * Sofia Silva Berenguer * Sonam Keba * Song Bing * Spiros Thanasoulas * Srikanth Sundaresan * Srimal Andrahennadi * Stanley Osao * Stefan Mehner * Stefan Ubbink * Steinthor Bjarnason * Stephan Marwedel * Stephane Bortzmeyer * Stephen McQuistin * Stephen Ryan * Stephen Strowes * Steve Crocker * Steve Santorelli * Sue Graves * Suetena Faatuuala Loia * Suksit Sripitchayaphan * Sunny Chendi * Susan Forney * Svaradiva Devi * Swapneel Patnekar * Sylvain Cortes * Sylvia Cadena * Szymon Trocha * Taejoong Chung * Taiji Kimura * Talha Paracha * Tan Kean Siong * Tashi Phuntsho * Teav Sovandara * Terry Sweetser * Theo Jepsen * Theophilus A. Benson * Thomas Holterbach * Thomas Koch * Thomas Krenc * Thomas Millar * Thomas Patzke * Thomas Scheffler * Thomas Wirtgen * Thymen Wabeke * Tianxiang Dai * Tim Bruijnzeels * Tim Fiola * Tim Raphael * Timm Bottger * Timothy Winters * Tobias Fiebig * Todd Arnold * Tom Barbette * Tom Carpay * Tom Do * Tom Harrison * Tom Hollingsworth * Tom Krizek * Tom Perrine * Tomek Mrugalski * Tomoaki Tani * Tony Finch * Tony Li * Tony Scheid * Tony Smith * Tony Tauber * Torsten Zimmermann * Trinh Viet Doan * Truong Khanh Huyen * Tuan Nguyen * Tugsorshikh Badarch * Ulrich Hauser * Ulrich Speidel * Usama Naseer * Uta Meier-Hahn * Vashkar Bhattacharjee * Vasileios Giotsas * Vasileios Kotronis * Vasilis Chryssos * Veronika McKillop * Vesna Manojlovic * Vicky Risk * Vijay Sivaraman * Vijay Varadharajan * Viktor Dukhovni * Vincent Bernat * Vitaly Kamluk * Vittorio Bertola * Vivek Nigam * W K Shiu * Wanqing Tu * Warren Finch * Warren Kumari * Wassie Goushe * Wayne Thayer * Werachart Muttitanon * Wes Hardaker * Wilaiwan Phanarin * Wilhelm Boeddinghaus * Willem Toorop * William Lu * Willy Sutrisno * Winfried Tilanus * Wita Laksono * Wout de Natris * Wouter de Vries * Xiao Zhang * Xiaohong Deng * Xiaoqi Chen * Xing Li * Yali Liu * Yeo Lee Chin * Yi Cao * Yiming Zhang * Ying Tian * Ying-Chu Chen * Yoshibumi Suematsu * Yoshinori Takesako * Yoshitaka Aharen * Younghwan Choi * Yuedong Zhang * Yunfei Ma * Yurie Ito * Yuta Takata * Zachary Bischof * Zaid Ali Kahn * Zaifeng Zhang * Zen Ng * Zhenyu Li * Zinan Lin * Zolzaya Shagdar * More Tags * APNIC Foundation * APNIC Training * ASNs * Australia * BGP * capacity development * CERTs * China * DNS * DNSSEC * Event Wrap * Guest Post * How to * IANA * ICANN * IETF * IGF * India * Indonesia * Internet Governance * Internet of Things * IPv4 * IPv6 * ISIF Asia * ITU * IXPs * Japan * measurement * networking * NOGs * NRO * Pacific * peering * Policy * RIPE NCC * RIRs * ROAs * routing * RPKI * security * Taiwan * TCP * Thailand * Three of the best * Whois Related Articles * Introducing TCPLS: A game of transport protocolsIntroducing TCPLS: A game of transport protocols by Florentin Rochet April 15, 2021 Guest Post: QUIC combines features of TCP and TLS to speed up web object transfers, but it has its flaws. What if there was another way to combine TCP and... * TCP path brokenness and transport layer evolutionTCP path brokenness and transport layer evolution by Korian Edeline November 3, 2020 Guest Post: Study looks at how prevalent middleboxes are within the Internet and measures the percentage of traffic affected by them. * Efficient multipath transport with QUIC in large-scale video servicesEfficient multipath transport with QUIC in large-scale video... by Yunfei Ma December 8, 2021 Guest Post: Alibaba shares their experience developing XLINK, a multipath extension for QUIC. * OMNI and the 6M's of modern internetworkingOMNI and the 6M's of modern internetworking by Fred Templin May 18, 2022 Guest Post: Before establishing a new adaptation layer in the Internet architecture, it's important to consider the primary motivating reasons, that is, the 'why' as opposed to the 'how'. Connect with us * Facebook * Twitter * YouTube * Flickr * Weibo * Slideshare * LinkedIn * RSS (c) 2022 APNIC ABN 42 081 528 010 * Privacy * Contact * Help Centre * NRO News * Service Status * Careers