Home / Blogs

Congestion in the Backbone: Telecom and Internet Solutions

When a network is subject to a rapid increase in traffic perhaps combined with a rapid decrease in capacity (for example due to a fire or a natural disaster), there is a risk of congestion collapse. In a congestion collapse, the remaining capacity is so overloaded with access attempts that virtually no traffic gets through. In the case of telephony, everyone attempts to call their family and friends in a disaster area. The long standing telephony approach is to restrict new call attempts upstream of the congested area, for example by call gapping. This limits the amount of new traffic to that which the network can handle. Thus, if only 30% capacity is available, at least the network handles 30% of the calls, not 3% or zero.

There are comparable issues for the Internet backbone, but they are not so completely solved. As Wikipedia puts it:

Congestion collapse was identified as a possible problem as far back as 1984 (RFC 896). It was first observed on the early internet in October 1986, when the NSFnet phase-I backbone dropped three orders of magnitude from its capacity of 32 kbit/s to 40 bit/s, and continued until end nodes started implementing Van Jacobson’s congestion control between 1987 and 1988.

TCP congestion control solved day-to-day congestion collapse, but it didn’t deal with disasters such as the Taiwan earthquake of December 2006.

As a result of problems in the Internet backbone in Asia caused by that earthquake, there’s new discussion of Internet congestion. I stumbled on one interesting discussion on the NANOG (North American Network Operators Group) mailing list.

In this thread, the NANOG group seems to be arriving at conclusions similar to those of the telecom industry, i.e. throttle new traffic attempts upstream of the congested area. From Fred Baker:

So plan B would be to in some way rate limit the passage of TCP SYN/SYN-ACK and SCTP INIT in such a way that the hosed links remain fully utilized but sessions that have become established get acceptable service (maybe not great service, but they eventually complete without failing).

And from Sean Donelan:

This would be a useful plan B (or plan F - when things are really FUBARed), but I still think you need a way to signal it upstream 1 or 2 ASNs from the Extreme Congestion to be effective.

...what should the alternate queue plan B be?

Probably not fixed capacity numbers, but a distributed percentage across different upstreams…

Session protocol start packets (TCP SYN/SYN-ACK, SCTP INIT, etc) 1% queue
Everything else (UDP, ICMP, GRE, TCP ACK/FIN, etc) normal queue

And finally why only do this during extreme congestion? Why not always do it?

The thread contains over 50 messages and doesn’t reach a specific call-to-action (that I could detect), but it does show similar problems and similar potential solutions.

I would have thought there’d be a few old telecom folks on the NANOG list, but I guess not…

By Brough Turner, Founder & CTO at netBlazr

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign


Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byDNIB.com