|
The following article is an excerpt from the recently released Internet Analysis Report 2004 - Protocols and Governance. Full details of the argument for protocol reform can be found at ‘Internet Mark 2 Project’ website, where a copy of the Executive Summary can be downloaded free of charge. The report also comments on the response of governance bodies to these issues.
In releasing this section for comment, I would like to point out that the report’s conclusions are based on a cumulative examination of various protocols and systems. We are at a point of time where other protocols and systems are equally problematic—the report points to some significant problems with DNS structure and scalability, and also points out that, to all intents and purposes, the basic email protocol, SMTP, is broken and needs immediate replacement.
As the report states, “There are many problems facing the Internet at the current time. Those closest to each problem are making substantial efforts in isolation from other major issues to address their particular problems, often however seeking short term fixes rather than longer-term solutions. A more coordinated approach across all areas seems necessary for resolution”.
Introduction
The Internet was developed in the 1970s and 1980s, initially as a means to connect mainframe computer systems for timesharing purposes. The system introduced for this fairly basic purpose has expanded to become a global multimedia information and communications system, connecting personal computers, phones, and hundreds of millions rather than the hundreds of devices originally foreseen.
Some of the significant developments not foreseen at the time of the original design include:
Parts of the system are now over 20 years old, and the Internet is required to perform a number of important functions not included in the original design. New protocols have been developed, and various patches have been applied to base protocols, not always evenly. It seems appropriate to examine whether the current systems and processes are still appropriate.
TCP/IP (or TCP and IP) have been described as the pair of protocols that make the Internet what it is. To purists, use of TCP/IP is the fundamental distinction that describes the Internet.
Essentially, TCP/IP describes system-neutral protocols for transportation of data across the internet between different systems.
Invented in the 1970’s, largely adopted in the late 1980s, TCP/IP hit its first big problem in the early 1990s when it became apparent that the numbering system (see DNS section of the report) was going to run out of numbers in the foreseeable future. IPv6 was mooted as the means to address this problem.
IPv6 had its formal beginnings in 1991. Although other issues were involved, the numbering system was a major catalyst for activity.
Work then began on the next generation Internet protocol, and many issues were put on the table for discussion but eventually dismissed as the protocol took on a manageable form. Traffic prioritization was one thing that went by the board.
The first recommendations for the new protocol emerged in 1994. After some discussion they were finalized in 1995. It took till April 1996 to move much further forward, and to define the transition phases as to how the network would adopt the new protocols.
That might be regarded as the beginnings of an adoption phase—some five years after the need was agreed to. However, in 2004—some 13 years after the problem was first worked on—implementation is at a low level. Not even the central root servers of the Internet had adopted the protocol by June 1994. No detailed analysis as to why adoption has been so slow appears to have been undertaken.
It appears that TCP/IP’s main advantage is its capacity to scale backwards to existing old systems. Apart from that it appears to be in need of fairly significant modification for scaling to the future, where voice traffic, Internet television and other factors (see Future Needs section of the report) may demand a more sympathetic base protocol.
TCP (The Transport Control Protocol) in particular has come in for significant criticism, and a growing body of experts believe it will need to be replaced. Indeed, if it were easy to change a fundamental Internet Protocol this may have been done some time ago. It’s the complexity of the change management problem that has delayed action rather than lack of recognized need for change.
Traffic Prioritization Issue
Although TCP/IP has proven to be remarkably robust, it may not scale to the future. In particular, TCP/IP does not know how to differentiate between traffic priorities (e.g. visiting a website requires a fairly immediate response as soon as we click on it, email delivery can wait a few seconds). This lack of prioritization is one of the major causes of the “slowness” of the Internet as perceived by users (real speed is something quite different and has a lot of other factors).
Unsuitability for Financial Transactions
As pointed out by Dr. Greg Adamson,
“A financial transactions architecture must be deterministic: the result of the transaction in the overwhelming majority of cases has to be what was meant, and when it is not there should be evidence of what went wrong. The design of the Internet protocol suite TCP/IP is non-deterministic. It aims to achieve overall reliability in a network, not necessarily individual reliability for each segment of that network. This concept of ‘best effort’ is core to the Internet’s design and to an understanding of the Internet’s flexibility. While the telephone network will reject an attempt to connect if the destination is unavailable (a busy signal), the Internet will send information out in the hope of success, by design (best effort). There are many methods for overcoming the limitations that this creates, including within the TCP protocol itself, but the design choice of ‘connect if a full service available’ or ‘make every effort to get any part of the message through’ remains. The original design specification states:
[The Internet Protocol has] no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service (Postel 1981).”
Security Issues
There are also security issues with TCP/IP, with researchers warning of vulnerabilities that need to be addressed. In April 2004, a major alert was issued to deal with a fundamental vulnerability.
Performance Issues
Users of large scale sites are already experiencing problems with the protocol, which tends to suggest that ordinary users will become affected in the near future, as bandwidth and processing availability continues to grow.
Assessment
TCP—if not TCP/IP—needs to be replaced, probably within a five to ten year time frame. The major issue to overcome is the migration issues (see below)
Migration Considerations
The problem of a new TCP is as complex (if not more so) that the TCPIPv4/v6 changeover which the Internet community has found very hard to deal with.
However, the factors in slow IPv6 deployment largely revolve around the fact that there is no communicated compelling reason to change. Given that a point of time will arise when changes to TCP are necessary for basic performance, it can be expected that, if a migration is conducted with appropriate change management planning, the adoption will be far quicker and far smoother than the IPv6 changeover. However, some basic factors need to be taken into account:
Conclusion
The efforts to change TCP/IP must continue, and in the medium term appear to need to take on additional momentum. The efforts need to be considered in the light of other major protocol problems, so that a more coherent approach to protocol reform or replacement emerges.
Sponsored byCSC
Sponsored byRadix
Sponsored byWhoisXML API
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byVerisign
Sponsored byIPv4.Global
The marketing effort that has been invested in this report is impressive. A friend of mine who has no Internet-specific expertise (although interested in technology generally) heard about it on the radio here in Australia and asked me if I knew of it. But the fact that the report is being sold as a product makes it intrinsically less valuable to me. Not only can I not afford to buy it (as a PhD student), I wouldn’t consider it very valuable if I were given a complimentary copy, since the limited readership reduces the amount of intelligent discussion available on it.
To the extent that the report itself is publicly available (in summary form above and executive summary on their website) I find it lacking. Many of the issues over which alarm bells are raised are not news at all, but well known to readers of CircleID. Indeed, they are, by and large, the very reason why we are gathered here. Many of the issues will be news only to the chronically out-of-touch.
To the extent that solutions are hinted at in the summary, they are controversial. This isn’t a bad thing in and of itself, but I’m disturbed by the overall tone in which the solutions are expressed: namely, that the urgency of the situation means unpopular decisions must be made and more or less enforced on the Internet at large by fiat, for the benefit of all concerned. This was ever the technique of the despot: manufacture a crisis, and offer to take the reins temporarily so that the community may be guided safely through.
A cynical reading of the recommendations in the executive summary reveals a sinister plot to establish the “Internet Mark 2” empire in the time frame of three to seven years, at which point the technical and political decisions will be safely out of the hands of inept volunteers, and securely in the hands of the new elite, whoever they may be. Silly though this interpretation is, it fits the facts. I don’t actually believe it to be their agenda, but their tone makes it clear that they aren’t looking for friends in the rank and file of the IETF.
Lastly certain parts of the report (in summary form) seem just plain disingenuous. I refer particularly to the alleged unsuitability of the Internet for financial transactions, above. There may be good reasons why the Internet is unsuited for certain kinds of transaction, but none are presented here. The suggestion that TCP is non-deterministic is misleading: TCP provides a reliable stream-oriented connection between endpoints over an unreliable datagram substrate (IP). All the criticisms aimed at “TCP/IP” in the Adamson quotation actually refer only to raw IP.
The very idea of a “deterministic network”, suggested as a design option, is fantasy: networks in the real world suffer from non-deterministic real-world inconveniences, like back-hoes severing cables, or spontaneously combusting switches. A TCP/IP session is more likely to survive such a real-world inconvenience (if an alternate route is available) relative to a purely circuit-switched network (which is my best guess as to what they mean by “deterministic”) precisely because TCP is designed to shield the application from a certain degree of real-world unreliability. Perhaps they meant deterministic with regards to response times, but the relevance of that to the issue at hand is not obvious.
Thus, the criticism of TCP/IP seems nothing more than smoke and mirrors. Furthermore, they fail to explain how the issues raised are at all relevant to financial transactions. By this stage, I’m starting to feel that they take me for some kind of sucker.
I could go on, but I doubt it would be fruitful. As someone who is actively concerned with the very real problems we face on the Internet today, I was hoping for rather more out of the time I invested in reading this article and the executive summary. My final impression is that the report was intended to be sufficiently sensational that a profitably large number of CEOs would buy it and pass it on to their technical staff with a sticky note saying, “do we need to be concerned about this stuff?” If the report is at all motivated by a sincere (even if misguided) wish to make the Internet a better place, I failed to pick up on it.
Harsh judgement, I know, but there you have it.