Is TCP Past It?

The Internet community is a nostalgic bunch – they’re rightly proud of the way the Internet has evolved and continues to muddle through in a chaotic sort of way.

And they’re also keen to hang onto protocols as long as possible, assuming that these protocols are still basically working – again a very sensible approach that complies with the First Law of Rural Mechanics (“if it ain’t broke, don’t fix it”).

Take the routing protocols OSPF (Open Shortest Path First) and BGP (Border Gateway Protocol), for instance. There have been several suggestions that these be completely revamped to meet the new challenges of the Internet, and these have been strongly resisted by the Internet Engineering Steering Group (IESG) hierarchy, down through the Internet Engineering Task Force (IETF) working groups. To be fair, it’s not easy to design good routing protocols, and the argument used is generally that the newer proposals don’t offer sufficient advantages over OSPF and BGP to warrant the disruption that the migration would cause.

But in the case of one stalwart IP protocol I think the case is becoming pretty watertight. It’s time to pension off the Transmission Control Protocol (TCP) for something better. It works tolerably well at the moment, but mark my words, in a few years' time trade journalists will be writing articles predicting the end of civilization as we know it, all because TCP is past it.

To put things in perspective, my view is this: Most users see adequate throughput from TCP applications today. So we don’t need to panic just yet. But power users are already seeing performance bottlenecks with the protocol, and that means that us mainstream folks will see those same problems in four or five years.

I’ve explained these problems in a Report that is being published concurrently with this column.

I believe one conclusion is unavoidable. The ultimate solution to this problem is to replace TCP with something else – TCPv2 if you want to call it that for nostalgic reasons. This means that we have to change software in IP host computers. In fact, it’s a problem on a similar scale to the IPv4 to IPv6 migration, and we know how much progress that’s made in the past 10 years.

There are lots of people working on this problem, but I think the time is right to open the debate a bit more widely than the Internet community – out to some of the folks who will need to start preparing for this migration when it finally comes about.

So if you’re seeing TCP performance issues today, let us know. If you’re working on TCP performance enhancements, why not tell us how things are going? You can do this by posting on the message board attached to this article, or by sending information to me at [email protected]. Please put “TCP Input” in the subject field so I can find it easily.

Hopefully, by sharing information with the people who are going to be working hard to implement the future migration, we can make sure it happens as smoothly as possible.

— Geoff Bennett, Director, Light Reading University

Page 1 / 8   >   >>
jim_smith 12/4/2012 | 11:54:59 PM
re: Is TCP Past It? Geoff,

Other than increasing the window size and perhaps changing the way TCP interprets lost acks, what else do we need to change?

When I hear the word "revamp", it conjures up an image that says "TCP is fundamentally broken", which is not true.

I suggest we use the word "retune" instead of "revamp".

skeptic 12/4/2012 | 11:54:55 PM
re: Is TCP Past It?
I've heard these same ideas expressed for years.
And they are always wrong.

There is NO problem with TCP itself. TCP is
a very simple-minded protocol.

- Does connection establishment need to be
- Does the state machine need to be changed?
- Does the sliding window/ack methodology need
to change?
Maybe. But before it changes, someone
better produce some research that WORKS and
that is BETTER. We have (as a community)
been down the selective ack road before and
it didn't pan out. If you want to change it,
you first have to show how all the old problems
are gone now.
And the best way to solve the worst
instances of this problem might be to expand
end-to-end MTU's in the internet to a common
bigger value. The current values are just
historical artifacts, not necessarly driven
by sound reasons anymore. Again, you don't
need to change TCP to enable a 32k MTU.

- Does the congestion mechanism in TCP need to
YES. Its old. But, (emphisis) IT IS NOT
CHANGES. The hardest thing in TCP today isn't
the technical issues, its getting those idiots
at microsoft to make any changes at all (or
even in some cases follow the existing standards).
Microsoft seems to spend more energy on talking
paperclips than they do on networking.

I look at TCP, the existing research and
alternatives over the past couple decades and
can't find any justification for changing it
at the protocol level.

rainbowarrior 12/4/2012 | 11:54:52 PM
re: Is TCP Past It?

I clicked on your report and got nothing but your protocol interworking page.

So I still don't see where you're coming from. Sure I'd love to redesign TCP but I can't imagine any problem in the protocol compelling a change that would effect so many apps.

Peter Heywood 12/4/2012 | 11:54:47 PM
re: Is TCP Past It? Geoff's reasons for thinking TCP is reaching the end of its useful life are in this report:


Unfortunately, the original link in this column led you to the wrong report. I've fixed it now.

Geoff and I are aware that greater minds than ours think TCP is getting out of date. We're hoping that we've done enough in this column and report to encourage them to come out into the open and explain the technical issues to LR's readership.

snarfulent 12/4/2012 | 11:54:43 PM
re: Is TCP Past It? 10Gbps throughput on a single TCP connection carried thousands of miles is a "specialty" application, as is TCP over very high latency links. Tuning and extending TCP to improve performance in these specialty applications has been a research topic for years.

Extending this notion to a prediction of the death of TCP is a bit of a stretch, though, as it implies a common inadequacy to be seen by a significant subset of users. But what's the application for carrying this level of data to anything other than a tiny percentage of endpoints?
Mark Seery 12/4/2012 | 11:54:40 PM
re: Is TCP Past It? Hi Geoff,

So worthwhile discussion to have, but a few points.

1) Aversion to change is a complex problem. Obviously involves elements of religion, power struggles, work avoidance, avoidance of flag days, etc. But there is also the line of thought that suggests, that even if you start from scratch, you might end up with the same thing (witness the evolution of MPLS for example).

2) You have characterized slow start as a way to get better performance, but I think that is only stating half the algorithm. It is also a way of getting worse performance - and this is deliberate. Look at the very assumptions that RED/WRED are based on. So why is this? Well, it was thought necessary to throttle back individual sessions when they see congestion so as to protect the health of the overall Internet. So I don't think you can separate the inidividual characteristics of a single TCP session, from the dynamics of the Internet as a whole. Ask yourself what would be the resultant dynamic within the Internet as a whole if everyone had these super fast TCP sessions and there was no backoff.

3) In future discussions on this subject, if you really want to spice things up, separate the TCP issue into its use as an end-user protocol, and its use as a control plane transport ;-)

So bottom line is I think you have to look at the system as a whole, and you have to ask yourself can you really create a new TCP without looking at the overall effects. If you cannot, then of course TCPv2 would look very much like TCPv1 + some of the tuning that has been noted, IMHO.

All modes of networking are a package of interelated things. It is very hard to dissect and change one aspect, in a radical way, without resultant unintended/unknown consequences.

skeptic 12/4/2012 | 11:54:37 PM
re: Is TCP Past It? 10Gbps throughput on a single TCP connection carried thousands of miles is a "specialty" application, as is TCP over very high latency links. Tuning and extending TCP to improve performance in these specialty applications has been a research topic for years.
Its not even a research topic. All the research
in this area was done years ago. The conclusions

- Raise MTUs. The 1500 byte MTU internet is
past its time. If you raise the MTU, the number
of packets per window goes down and the effect
of loss isn't as dramatic.

- The TCP protocol isn't the problem. Nothing
forces anyone to use slow-start for these maximum
speed applications. slow-start ISNT in the TCP
standard. If you don't like it, you can create
an adaptive mechanism to avoid it when the
bandwidth-delay product is large.

- The most common application for high-speed
TCP/IP is file transfer. And that application
can be adapted to use parallel TCP sessions and
barring problems in the end-station OS (which
there will be), it avoids many of the problems.

- If you really have a 10Gbps real-time TCP
application, its probably not a good idea for
you to be pushing all that data through the
public best-effort internet anyway.
beowulf888 12/4/2012 | 11:54:30 PM
re: Is TCP Past It? Sure I can see certain situations where TCP is a drag on network performance, but just how critical is this problem?

BTW: I think the "world wide wait" example in your article has less to do with TCP's inefficencies than HTTP's haphazard way of requesting and sending blocks of data (which could be fixed by pipelining connections).

So under what circumstances would you need a super-efficent TCP? Certainly not real time applications, which could use UDP or RTSP. Would you need an efficient TCP for huge FTP blasts?

Granted, TCP can be tuned to be more efficient by tweaking its windowing behavior, etc., but is this really a burning problem?

gbennett 12/4/2012 | 11:54:27 PM
re: Is TCP Past It? snarfulent said:

10Gbps throughput on a single TCP connection carried thousands of miles is a "specialty" application, as is TCP over very high latency links.

That's correct today. But the point is that we add a zero onto the end of Ethernet performance every 4 years. What's "speciality" today will be "power user" in 4 years, "mainstream business" in 8 and a "universal requirement" in 12.

Since any change in an end system protcol will be strongly resisted, as Mark Seery points out, then maybe we need to start thinking about this soon.

Tony Li 12/4/2012 | 11:54:27 PM
re: Is TCP Past It?
I have to concur with skeptic here. The issue is not with the protocol, it is with the implementation. The gist of your article seems to be a complaint about slow start without due consideration of the necessity of congestion avoidance.

Yes, we can and should get more sophisticated in this area, but nothing is served by a new protocol. As has been done repeatedly, new implementation algorithms can be put in popular implementations (e.g., BSD) and source can be distributed. From there, this will trickle into more common operating systems. This will be driven by end users who actually have an issue.

TCP can continue to evolve in this way for quite some time. The basics of TCP are not likely to need fundamental changes anytime soon. Sliding window protocols and three way handshaking are pretty basic and there's sufficient extensibility through options so that we can continue to make progress with this framework for quite some time.

The sky is NOT falling.

Page 1 / 8   >   >>
Sign In