https://blog.apnic.net/2022/01/26/beyond-bufferbloat-end-to-end-congestion-control-cannot-avoid-latency-spikes/ Skip to content APNIC Home [icon-squar] MyAPNICAcademyBlogOrbitRExNetOXDASH Log in Home Whois and website search [ ] Search Advanced Whois Make a payment Close Search Search APNIC.net OR enter Whois database query [ ] * Get IP + Get IP + Make a payment + Membership + FAQs * Manage IP + MyAPNIC + Using Whois + IPv4 exhaustion + Go IPv6 + Routing Registry + Make a payment * Training + About + Events + APNIC Academy + Community Trainers + Courses * Events + Conferences + Calendar + Sponsorship + Code of Conduct * Insights + APNIC Labs + DASH to secure your networks + REx + NetOX to solve routing issues + Raw Data * Community + Orbit + Community demographics + Policy Development + Fellowship + Addressing policies + Internet community + Code of Conduct + Technical Assistance + Root servers + Security at APNIC + ISIF Asia + APNIC Foundation + NRO Number Council (NC) * 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 * Advanced Whois * Make a payment * APNIC Home * Get IP + Get IP + Make a payment + Membership + FAQs * Manage IP + MyAPNIC + Using Whois + IPv4 exhaustion + Go IPv6 + Routing Registry + Make a payment * Training + About + Events + APNIC Academy + Community Trainers + Courses * Events + Conferences + Calendar + Sponsorship + Code of Conduct * Insights + APNIC Labs + DASH to secure your networks + REx + NetOX to solve routing issues + Raw Data * Community + Orbit + Community demographics + Policy Development + Fellowship + Addressing policies + Internet community + Code of Conduct + Technical Assistance + Root servers + Security at APNIC + ISIF Asia + APNIC Foundation + NRO Number Council (NC) * 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 Skip to the article Beyond bufferbloat: End-to-end congestion control cannot avoid latency spikes By Bjorn Teigen on 26 Jan 2022 Category: Tech matters Tags: bufferbloat, congestion, Guest Post, latency, QUIC, TCP 7 Comments Tweet Blog home [beyond-buffer-555x202] End-to-end congestion control methods, such as TCP and QUIC, are the main ways of avoiding congestion on the Internet, and much research has gone into improving the latency performance of TCP. In a recent paper, we at Domos, describe a fundamental limitation of these methods -- they cannot avoid latency spikes. Our paper addresses an awkward problem that is obvious to a part of the community (hello control theory people), but which many researchers and engineers frequently either ignore or overlook. The initial motivation for the work was a recent workshop at the Internet Architecture Board (IAB). During the workshop, a common misunderstanding (even among experts in the field) became apparent -- that end-to-end congestion control can deliver reliable low latency if we just tune it correctly. That is not true for networks where link capacity can change rapidly, such as Wi-Fi and 5G. Two recent survey papers (Survey 1 and Survey 2) both state that large variations in capacity are one of the main problems for congestion control in 5G networks. Yet, there are no references to fundamental limitations in either survey. TCP, bufferbloat, and the promise of a responsive Internet Bufferbloat has been identified as a common source of latency on the Internet. Nichols and Van Jacobson describe Bufferbloat as 'unnecessary queuing'. Bufferbloat is caused by poor congestion signalling leading to a 'standing queue' at bottleneck interfaces. A standing queue adds latency without improving throughput and is therefore just wasting everyone's time. Lots of progress has been made on reducing bufferbloat in the Internet, perhaps most notably by Dave Taht, Toke Hoiland-Jorgensen, Jim Gettys, and Kathleen Nichols. In the latest iOS release, there is a tool called RPM, which is designed to measure and detect bufferbloat, and browser tools exist as well. Removing unnecessary queuing is a win-win. However, to get close to the ideal speed-of-light Internet, removing standing queues is not enough. Transient queues, often called 'good queues' because they help improve link utilization, can be large enough to contribute significantly to performance problems. Figure 1 -- Perfect operation at saturation. The ACKs 'clock' the sender to perfectly fill the bottleneck link to 100% capacity.Figure 1 -- Perfect operation at saturation. The ACKs 'clock' the sender to perfectly fill the bottleneck link to 100% capacity. Figure 2 -- What happens when capacity drops. The green ACKs mark the first congestion signal seen by the sender. Notice that the queue is already formed by the time the sender knows about the congestion.Figure 2 -- What happens when capacity drops. The green ACKs mark the first congestion signal seen by the sender. Notice that the queue is already formed by the time the sender knows about the congestion. How good is TCP latency under perfect conditions? In the paper, we model the best possible case for an end-to-end congestion controller and work out how much latency we'd see on the bottleneck link if its capacity is suddenly reduced. The mathematics is simple, and we can compute the peak latency using the factor of capacity change (1/r) and how much time it takes to send a signal from the point of congestion to the traffic source (d). 'd' depends on the speed of light. One trip around the earth at the speed of light takes 133 milliseconds, so the speed of light is significant in these calculations. As we can see in Figure 3, the queuing latency can grow to several hundred milliseconds for values of C and d that are not uncommon on the Internet. [Figure-3-]Figure 3 -- Minimum queuing delay with end-to-end congestion control and no packet loss. A key point is that this is the theoretical optimum for any and all end-to-end congestion control algorithms. The results are valid for all versions of TCP, QUIC, adaptive bitrate streaming methods, and all other end-to-end congestion control schemes you can possibly think of. Congestion signalling methods cannot work around this problem either, so our analysis is also valid for Explicit Congestion Notification methods such as Low Latency Low Loss Scalable Throughput (L4S). How can latency spikes be avoided? We have concluded that end-to-end congestion control alone is not enough to provide the reliable low-latency Internet that 5G marketers have promised us. What are our other options? We have come up with a list of solutions that can help us out in different scenarios: 1. See the future. If a congestion controller can react before capacity is reduced, then peak delays are smaller (this is equivalent to reducing d). This might be possible for cases where capacity drops are a result of things moving around. 2. Underutilize the link. If we use the link at 10% capacity, then a capacity drop to 1/10th is not noticed. This is a good solution if the bandwidth is cheap enough, but it is expensive to build networks that are 10 times as big as they need to be! 3. Treat traffic differently. This is like underutilization, but smarter. The idea is to underutilize the link, but only for traffic that is latency sensitive. Never fill more than 1/10th or 1/20th of the capacity with time-sensitive traffic, and suddenly you can handle large capacity drops. The rest of the link can be filled with traffic that is not as latency sensitive. The caveat is that when the capacity drops, the latency-sensitive traffic must be given priority on the link until capacity bounces back up. If this is handled at the point of congestion, then we can have the best of both worlds. 4. Link diversification. If the same traffic is sent over more than one link, then the end-to-end connection can be made much more reliable because the chance of both links reducing capacity at the same time is small (assuming they are not correlated!). I will leave you with a question: Are we trying to make end-to-end congestion control work for cases where it can't possibly work? If so, then accepting the limitation we describe here is a necessary step towards making the reliable low-latency Internet a reality. Bjorn Ivar Teigen is Head of Research at Domos, and a PhD candidate at the University of Oslo. His research interests are in queuing theory, distributed systems, and Machine Learning with applications in modelling and optimizing real-world networks. Rate this article --------------------------------------------------------------------- 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. 7 Comments 1. Dave Taht January 29, 2022 at 10:23 am Re your pt 3, I would have called out the potential of fair queuing and in running your latency sensitive flows at , say, 1/ 10th the rate of the capacity seeking ones. This is essentially the optimum we have today with qdiscs like fq-codel and cake, and works very well with modern day lower bitrate voip, request/ response, and videoconferencing. Aside from that I agree with your main points and loved the heatmap. Thx for the cite, too! Reply | 2. Dave Taht January 29, 2022 at 10:27 am There's been promising work here to make 5G, WiFi and Starlink behave better at the point of congestion: https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848/ And this also, being used in google's wifi products, leveraging even more of kathie nichol's later work on these subjects. https://chromium.googlesource.com/chromiumos/third_party/kernel/+ /refs/heads/stabilize-quickfix-13310.76.B-chromeos-4.14-gw/net/ sched/sch_arl.c Reply | 3. Christian Huitema January 30, 2022 at 2:50 am How can I reproduce these simulations? What link models are you using? How can I model the latency and delay variations of the links? Reply | 4. Bjorn Ivar Teigen January 31, 2022 at 8:20 pm @Dave Thanks for the feedback! Agree with your points as well, fq-codel and cake are both great and deserve more deployment. The cake with adaptive bandwidth stuff is interesting. Have seen the discussions but haven't delved into the detail yet. @Christian The results are based on a first-principles analysis, not on simulations. In the paper (https://arxiv.org/abs/2111.00488) I explain how the results are derived. If you have any more questions feel free to contact me at bjorn@domos.no. Reply | 5. Dave Taht February 2, 2022 at 3:03 am Re pt 1: Signalling beforehand is very possible with heavily scheduled links (in rough order of possibility), like starlink, wifi, lte, cable and gpon. Presently, for example, starlink is adjusting available bandwidth on a 15s interval, wifi is a function of stations * the needed txop size (waaay more complicated for mu-mimo). Reply | 6. Kevin Smith February 2, 2022 at 8:53 pm Very interesting article, thanks! I'm an engineer for a cellular operator, where E2E congestion has historically struggled with the radio air interface volatility - e.g. available bandwidth to a terminal varying by an order of magnitude or more in under a second due to reduced SINR, fading, reflections etc. By the time the TCP server reacts the conditions have often changed - and the radio layers are busily doing their own retransmissions and transmission modifications (ARQ and HARQ). But these radio layer retransmissions are not visible to the transport layer, meaning the transport layer will retransmit segments that are already queued at the radio layers. So a 'joined up' approach between the radio and transport layers could mitigate that...also to note that radio schedulers transmit based on (1) the received signal strength of the user's terminal, which is constantly signaled to the radio base station, and (2) the size of the user's individual packet queue. Scheduler buffers per user may be allowed to build up to make best use of good signal strength when available, which may be another cause of bufferbloat. Thanks! Reply | 7. Bjorn Ivar Teigen February 4, 2022 at 6:08 am @Kevin Thanks for the interest! The issues you describe are very familiar from my experience working with WiFi. Seems like TCP was very much designed for wired links and the variable latency and bitrate of wireless really mess with some of the algorithms. Interesting stuff, and lots of room for improvement! Reply | 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 [ ] [ ] Notify me of follow-up comments via email. You can also subscribe without commenting. [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 * Adli Wahid * Aftab Siddiqui * Geoff Huston * George Michaelson * Jen Linkova * Job Snijders * Kathleen Moriarty * Paul Wilson * Ulrich Speidel * Vitaly Kamluk * A Khalil Azizi * A S M Rizvi * AbdelRahman Abdou * Abhishek Jain * Achie Atienza * Adam Gosling * Adam McFillin * Adam Oest * Adeel Sadiq * Adiel Akplogan * Adisorn Lertsinsrubtavee * Adli Wahid * Adrian Farrel * Adrian Wan * Afifa Abbas * Afsheen Saadat * Aftab Siddiqui * Agustin Formoso * Ahmad Darki * Ajay Kumar * Akimichi Ogawa * Alain Aina * Alan Mauldin * Albert Gran Alcoz * Alden Hilton * Alec Muffett * Alejandro Acosta * Alex Band * Alex Boten * Alex Turing * Alex Yen * Alexander Azimov * Alexander Kozlov * Alfred Arouna * Ali Abedi * Ali Norouzi * Amanda H A Watson * Amaury Van Bemten * Amrita Choudhury * Anand Buddhdev * Anant Shah * Andra Lutu * Andre Gelderblom * Andreas Dewes * Andreas Reuter * Andree Toonk * Andrei Robachevsky * Andrew Ayer * Andrew Campling * Andrew Cormack * Andrew Cushen * Andrew Gray * Andrew Sullivan * Andrew Toimoana * Andrijana Todosijevic * 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 * Athina Fragkouli * Audrey Randall * Aurelien Aptel * Austin Hounsel * Austin Ruckstuhl * Avery Pennarun * Ayesha Iftikhar * Aysha Labiba * Ayush Mishra * Azfar Adib * Azhar Khuwaja * Azura Mat Salim * Baojun Liu * Baptiste Jonglez * Barry Greene * Bart Hogeveen * Basileal Imana * Bastian Kanbach * Batmagnai Erdene * Beau Gieskens * Ben Cox * Ben Du * Ben Schwartz * 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 * Brandon Hitzel * Brenda Buwu * Brenden Kuerbis * Brent Carey * Brett Bralley * Brian Carpenter * Brian Nisbet * Brian Trammell * Brianna Boudreau * Bruce Davie * 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 Buckridge * Chris Grundemann * Chris Parker * Chris Ritzo * Chris Siebenmann * Christian Giese * Christian Huitema * Christoph Dietzel * Chuan Jiang * Ciprian Popoviciu * Clarence Filsfils * Claudio Jeker * Clemens Mosig * Colin Perkins * Constance Bommelaer * Constantin Sander * Constanze Dietrich * Craig Miller * Craig Ng * Craig Rowland * Dale Roberts * Dan Fidler * Dan Groshev * Dan Li * Daniel Dib * Daniel Kopp * Danilo Giordano * Danny Alex Lachos Perez * Danny Pinto * Daryll Swer * Dashzeveg Baatartsogt * 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 * Diptanshu Singh * Dirk Trossen * 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 * Ege Cem Kirci * Eliot Lear * Elizabeth Krumbach Joseph * Ellisha Heppner * Elly Tawhai * Elvin Prasad * Emile Aben * Emily Gallarde * 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 * Eugene Bogomazov * Eunju Pak * Eyal Estrin * Fabian Bustamante * Fakrul Alam * Farha Diba * Fenglu Zhang * Ferenc Fejes * Fernando Gont * Flavia Salutari * Flavio Luciani * Florentin Rochet * Florian Holzbauer * Florian Streibelt * Foy Shiver * Francesco Ferreri * Francesco Sassi * Franck Martin * Francois Michel * Frane Maroevic * Frank Denis * Frank Herberg * Franziska Lichtblau * Fred Christopher * Fred Templin * Fredrik Lindeberg * Ganga R Dhungyel * Gaurab Raj Upadhaya * Gautam Akiwate * Gavin Reid * Geoff Huston * George Kuo * George Michaelson * George Odagi * George Sadowsky * George Salisbury * Giacomo Giuliari * Gianmarco Pagani * Giovane Moura * Gonchig Altansukh * Gordon King * Greg Ferro * Gregory Mounier * Guangliang Pan * Guillermo Baltra * Guoliang Yang * GZ Kabir * Ha Dao * Haisheng Yu * Han Zhang * Hanna Kreitem * Hannah Durack * Hanno Bock * Harish Chowdhary * Haya Schulmann * Helen Hollins * Hideyuki Sasaki * Hinne Hettema * Hiroki Kawabata * Hiroko Kamata * Hiromu Shiozawa * Hisham Ibrahim * Hoang Nguyen Phong * Houlin Zhao * Hyeonmin Lee * Hyojoon Kim * Ignacio Castro * Ihita Gangavarpu * Ike Kunze * Ilker Nadi Bozkurt * Imtiaz Rahman * Indya Bolton * Ioana Livadariu * Italo Cunha * Ivan Ristic * Ivana Tomic * Ivo A. Ivanov * Ivy Yip * Izumi Okutani * Jaclyn Knight * Jacob Davis * Jacob Ginesin * Jahangir Hossain * Jake Bauer * Jake Flint * Jake Holland * James Ah Wai * James Bensley * James Kettle * James Pavur * James Richards * James Shank * Jamie Gillespie * Jan Harm Kuipers * Jan Ruth * Jan Schaumann * Jan Zorz * Jan-Piet Mens * Jane Yen * Jari Arkko * Jason Livingood * Jason Smith * Jasper den Hertog * Jawad Ahmed * Jay Daley * Jay Ford * Jeff Chan * Jeff Fry * Jeff Man * Jen Linkova * Jenine Beekhuyzen * Jeremy Harrison * Jerry Lundstrom * Jessica Shen * Jessica Wei * Jethro Webston * Jia-Rong Low * Jilong Wang * Jim Cowie * Jim Forster * Jim Vella * Jimmy Lim * Jing Qiao * Jinghua Bai * 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 Althouse * John Bambenek * John Curran * John Garrity * John Jack * John Jason Brzozowski * John Kristoff * John Scudder * John Welborn * Jonathan Brewer * Jonathan Magnusson * Jordan Carter * Jordan Jueckstock * Jordi Paillisse * 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 * Justin Loye * Justin Wilson * Kaajal Kumar * Kaan Onarlioglu * Kanagaraj Krishna * Karan Sharma * Karel Hynek * Karl Lovink * Karla Skarda * Kasek Galgal * Kashyap Thimmaraju * Kathleen Moriarty * Katsuyasu Toyama * Kavya Bhat * Kazunori Fujiwara * Ke Ma * Keisuke Kamata * Kemal Sanjta * Kenjiro Cho * Kenny Huang * Kenrick Lin * Kensuke Fukuda * Kevin Backhouse * Kevin Bock * Kevin Jin * Kevin Ku * Kevin Meynell * Kevin Vermeulen * Kevon Swift * Keyu Man * Khee Hong Loke * Khwaja Zubair Sediqi * Kiruthika Devaraj * 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 * Lari Huttunen * Lars Prehn * Lars-Johan Liman * Leandro Bertholdo * Leandro Navarro * Lee Howard * Leo Vegoda * Leonid Todorov * Leslie Daigle * Lia Hestina * Liang Wang * Liang Zhao * Liangcheng Yu * Libin Liu * Lindsay Graham * Linjian Song * Lisa Corness * Lisandro Ubiedo * Liz Izhikevich * Loba Olopade * Lorenzo Cogotti * Louise Tromp * Luca Sani * Lucas Pardue * Luuk Hendriks * M. Yasir M. Haq * Maarten Botterman * Maarten Wullink * Maciej Korczynski * Madeline Carr * Maemura Akinori * Mai Thu Thuy * Major Hayden * Mallory Knodel * Manaf Gharaibeh * Mannat Kaur * Mansour Ganji * Marc Bruyere * Marcin Nawrocki * Marco Chiesa * Marco Cilloni * Marco Hogewoning * Marcus Brinkmann * Marcus Keane * Marek Majkowski * Maria Namestnikova * Maria Theresa Perez * Mariano Scazzariello * Mariko Kobayashi * Marilyn Zhang * Mario Loffredo * Mark Andrews * Mark Karpilovskij * Mark Nottingham * Mark Prior * Mark Smith * Mark Tinka * Markus Dahlmanns * Markus Legner * Markus Sosnowski * Marten Porte * Martin Hannigan * Martin Hoffmann * Martin Langer * Martin Thomson * Martin Winter * Martino Trevisan * Mary Rose Ofianga-Rontal * Masanori Yajima * Masataka Mawatari * Massimo Candela * Mat Ford * Matsuzaki Yoshinobu * Matt Larson * Matt Oh * Matt Palmer * Matt Ringel * Matt Stith * Matthew Thomas * Matthias Wichtlhuber * Matthijs Mekking * Mattijs Jonker * Max von Hippel * Maxime Mouchet * Maxime Piraux * Md Abdul Awal * Megan Baker * Melchior Aelmans * Melody Bendindang * Merike Kaeo * Metin Acikalin * Michael Kende * Michael Patterson * Michael Rabinovich * Michael Schapira * Michael Schneider * Michelle Thorne * Mika Kerttunen * Mike Hollyman * Mike Hwang * Mike Kosek * Min Sung Jung * Mingming Zhang * Mingwei Zhang * Minzhao Lyu * Miwa Fujii * Mohamad Dikshie Fauzie * Mohamed Awnallah * Mohamed Boucadair * Mohamed Kassem * Mohammad Larosh Khan * Molay Ghosh * Momoka Yamamoto * Moritz Muller * Mubashir Sargana * Muhammad Moinur Rahman * Muhammad Yasir Shamim * Mujtaba Hussain * Mukhammad Andri Setiawan * Munkhbat Gansukh * 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 * Niels Provos * Nihit Tandon * Niklas Vogel * Nikolai Hampton * Nikos Kostopoulos * Nils Wisiol * Nirav Atre * Nooshin Eghbal * Nor Fadzilah Abdullah * Nurul Islam Roman * Nusenu * Nyamkhand Buluukhuu * Oanh Nguyen * Oky Tria Saputra * Olafur Gudmundsson * Olamide Omolola * Oliver Gasser * Oliver Michel * Olivier Tilmans * Omar Alrawi * Omar Ansari * Ondrej Caletka * Ondrej Sury * Otto Moerbeek * Pablo Hinojosa * Paolo Lucente * Paresh Khatri * Parkpoom Tripatana * Pasan Lamahewa * Patrick McManus * Patrick Sattler * Patrik Faltstrom * Paul Dale * Paul Grubbs * Paul Wilson * Pavel Odintsov * Pawel Foremski * Pawel Urbanek * Pedro Marcos * Pengxiong Zhu * Pete Sclafani * Pete Stevens * Peter Blee * Peter Hansteen * Peter Lowe * 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 * Pim van Pelt * Piotr Kijewski * Platon Kotzias * Pranav Kondala * Praneet Kaur * Pubudu Jayasinghe * Qasim Lone * Quincy Liao * Rachee Singh * Rafael Cintra * Raffaele Sommese * Raffaele Zullo * Rahul Makhija * Rajnesh Singh * Ralph Dolmans * Ralph Holz * Ram Sundara Raman * Ramakrishna Padmanabhan * Rami Al-Dalky * Ramin Yazdani * Ran Ben Basat * Ranysha Ware * Raphael Hiesgen * 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 * Rob Schult * Robbie Mitchell * Robert Alexander * Robert Kisteleki * Robin Marx * Roderick Fanou * Roger Meyer * Rohana Palliyaguru * Roland Meier * Roland van Rijswijk-Deij * Rolf Winter * Romain Fontugne * Ron Bonica * Ron Winward * Ronald van Kleunen * Rowena Schoo * Roy Arends * Rudiger Birkner * Russ White * Ryan Beckett * Ryan Gerstenkorn * Ryo Nakamura * Sachin Ashok * Safiqul Islam * Said Jawad Saidi * Said Zazai * Salvatore Cuzzilla * Sam Sham * Samaneh Tajalizadehkhoob * 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 * Satadal Sengupta * Satoru Matsushima * Satoru Tsurumaki * Sayda Kamrun Jahan Ripa * Scott Hollenbeck * Scott Shenker * Sebastian Castro * Sebastian Neef * Sebastian Zander * Seiichi Kawamura * Seluvaia Kauvaka * Seth Schoen * Shah Sahari * Shahee Mirza * Shahzeb Mustafa * Shamim Reza * Shamsullah Shams * Shane Alcock * Shane Kerr * Sharada Yeluri * Sharat Chandra Madanapalli * Sheetal Kumar * Sheikh Md Seum * Shermaine Yung * Sherry Shek * Sheryl Hermoso * Shian-Shyong Tseng * Shinoj Pittandavida * Shishio Tsuchiya * Shivan Sahib * Shoko Nakai * 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 * Stijn Pletinckx * Sue Graves * Suetena Faatuuala Loia * Suksit Sripitchayaphan * Sunny Chendi * Susan Forney * Svaradiva Devi * Swapneel Patnekar * Swaran Ravindra * Sylvain Cortes * Sylvia Cadena * Szymon Trocha * Taejoong Chung * Taiji Kimura * Talha Paracha * Tan Kean Siong * Tan Tin Wee * Tanya Shreedhar * Tashi Phuntsho * Teav Sovandara * Temitope Lawal * Terry Sweetser * Teun Vink * Thein Myint Khine * Theo Jepsen * Theophilus A. Benson * Thijs van den Hout * Thomas Holterbach * Thomas King * Thomas Koch * Thomas Krenc * Thomas Millar * Thomas Patzke * Thomas Scheffler * Thomas Wirtgen * Thy Boskovic * Thymen Wabeke * Tianxiang Dai * Tim Bruijnzeels * Tim Chown * Tim Fiola * Tim Raphael * Timm Bottger * Timo Longin * Timothy Winters * Tiong Beng Ng * Tobias Fiebig * Todd Arnold * Tom Barbette * Tom Carpay * Tom Coffeen * Tom Do * Tom Harrison * Tom Hollingsworth * Tom Krizek * Tom Perrine * Tomek Mrugalski * Tommaso Caiazzi * Tomoaki Tani * Tony Finch * Tony Li * Tony Scheid * Tony Smith * Tony Tauber * Torsten Zimmermann * Trinh Viet Doan * Truong Khanh Huyen * Tuan Nguyen * Tugsorshikh Badarch * Tushar Swamy * Ulrich Hauser * Ulrich Speidel * Usama Naseer * Uta Meier-Hahn * Vanessa Maria Fernandes * Vashkar Bhattacharjee * Vasileios Giotsas * Vasileios Kotronis * Vasilis Chryssos * Venkat Arun * 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 * Wen-Tsung Chang * Werachart Muttitanon * Wes Hardaker * Wilaiwan Phanarin * Wilhelm Boeddinghaus * Willem Toorop * William Lu * Willy Sutrisno * Winfried Tilanus * Wita Laksono * Wout de Natris * Wouter de Vries * Xiang Li * Xiao Zhang * Xiaohong Deng * Xiaoqi Chen * Xing Li * Xinlei Yang * Xuewei Feng * Yali Liu * Yeo Lee Chin * Yevheniya Nosyk * Yi Cao * Yiming Zhang * Ying Tian * Ying-Chu Chen * Yoshibumi Suematsu * Yoshinori Takesako * Yoshitaka Aharen * Younghwan Choi * Yuedong Zhang * Yunfei Ma * Yurie Ito * Yury Zhauniarovich * Yuta Takata * Yuxiang Yang * Zachary Bischof * Zaid Ali Kahn * Zaifeng Zhang * Zain Shamsi * Zen Ng * Zhenyu Li * Zhiyi Chen * Zili Meng * Zinan Lin * Zolzaya Shagdar Show All (907) Show Pinned (10) 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 * Internet Governance * Internet of Things * IPv4 * IPv6 * ISIF Asia * ITU * IXPs * Japan * measurement * networking * NOGs * NRO * opinion * Pacific * peering * podcast * RIPE NCC * RIRs * ROAs * routing * RPKI * security * TCP * Thailand * Three of the best * tools * Whois Related Articles * Loops_bannerReducing the control loop in congestion control by Zili Meng November 1, 2022 Guest Post: Decoupling the control loop from full path congestion control helps to bypass bottleneck routers, reducing video buffering. * mindthegapCongestion control algorithms are not fair by Venkat Arun November 23, 2022 Guest Post: Current CCAs lead to starvation. What can we do about it? * Traffic Jam on Coronation Drive, 1954[Podcast] Low Earth Orbit and the TCP congestion... by George Michaelson November 23, 2023 Geoff Huston discusses LEO satellites and TCP congestion control. * tuning-fork_bannerImproving network performance with Dynamic... by Anant Shah January 24, 2022 Guest Post: CDN shares how it detects cases where BBR provides improved performance enabling them to provide more custom congestion control. APNIC Home Connect with us * Facebook * Twitter * YouTube * Flickr * Weibo * Slideshare * LinkedIn * RSS (c) 2024 APNIC ABN 42 081 528 010 * Privacy * Contact * Help Centre * NRO News * Service Status * Careers * Feedback