Download Moving beyond TCP

Moving beyond TCP/IP
 Look at the title and discuss in pairs what you think the text will be about
Fred Goldstein and John Day for the Pouzin Society 4/2010
The triumph of the TCP/IP protocol suite in today’s market is nearly complete. A
monoculture of networking has emerged, based on Internet protocols originally developed in
the 1970s and popularized in the 1980s. With this level of acceptance and a near-universal use
of IP for purposes well beyond the original designers’ intent, one can imagine that TCP/IP
really represents the final stage in networking, from which all future solutions must slowly
evolve.
This belief, however popular, is not necessarily correct. TCP/IP was a very important stage of
network evolution. It was designed for the ARPANET, which the Department of Defense
built as a resource-sharing network to reduce the cost of its research. It showed promise and
conclusively demonstrated alternative forms of networking that had not previously been
shown at such a scale. But it was not set up to primarily do research on network technology
per se.
There was no such network; research on networking was incidental to its mission.
It was, if anything, too successful. Because the ARPANET and TCP/IP worked reasonably
well, was government-funded, and had no strong competition, it went into production too
early. Its technology was adopted by the later Internet, as well as by many private networks,
and it has been simply accepted as a given.
The Internet itself has been a huge popular success, in large part because of its low-priced
business model. It hasn’t been as successful for its providers; the ISP industry has never been
very profitable, and the early growth of the Internet was largely subsidized by the huge
infusion of overvalued equity during the 1997-2000 stock boom. IP has absorbed the glow
from the Internet’s halo. It is hard to distinguish between the Internet and its protocols. But
they are not the same thing. For the Internet to prosper in the long term, it needs to move
beyond TCP/IP.
The experiment was a success. Now is the time to analyze its lessons and start moving ahead.
Unfortunately, the Internet Engineering Task Force has not been learning these lessons. It has
been acting as a promotional body for TCP/IP itself. It confused commercial success with
technical excellence. It has tragically decided that the evolution of IP is to IP Version 6. This
decision, made in the early 1990s before the Internet was even in widespread commercial use,
has distracted the networking community. A different direction is needed.
TCP/IP was designed for a limited set of tasks
When the ARPANET began in 1969, it was designed to demonstrate the then-radical notion
of packet switching. The mere notion that a network could handle small blocks of data, rather
than create constant flows like a phone call, needed to be demonstrated. The original
ARPANET protocol was called NCP. It was, in today’s terms, connection-oriented: Before
data could be passed between two points, a connection had to be set up. What differed from
the connection oriented telephone network was that the actual network capacity was only
consumed on demand, not merely by having a connection present. But NCP was also a very
rigid protocol, designed to ensure reliability of transmission on a hop by hop basis. This may
have been a good idea given the networks of its day. The ARPANET backbone ran at 50
kilobits per second. This was very fast at the time!
The NCP ARPANET is not today’s Internet. It was closer to what the public packet-switched
networks that were developed in the 1970s called X.25. These networks were optimized for
terminal-to-host applications. It was a dead-end technology that dominated European markets
in the 1980s.
But it was a French researcher, Louis Pouzin, who saw the early ARPANET and had a
different idea about how to perform packet switching. He postulated that the switches in the
middle of the network didn’t have to keep track of connections; they just had to pass packets
as they arrived. Error correction and flow control could be handled at the edges of the
network. He designed and built the first connectionless network, CYCLADES, in 1972. He
also noted in a 1974 article that it was possible for packets to be passed between separate
networks, each with its own administration and policies. This idea was picked up later that
year by ARPANET researchers, along with connectionless networking. We now know it as
the Internet, the network of networks.
ARPANET researchers created a new set of protocols, with TCP for end-to-end error and
flow control and IP for the connectionless middle. They did not receive universal acceptance
even then. When submitted to the International Federation for Information Processing (IFIP)
for international standardization, alternatives closer to Pouzin’s work were found more
suitable. The latter were submitted to ISO for its pending OSI program. But the Department of
Defense continued with TCP/IP.
It was phased in and, by 1983’s “flag day”, completely replaced NCP. And around that time,
Berkeley released a free, open source implementation of TCP/IP. It included the key
application protocols of its day, too: FTP for file transfer, SMTP for email, and TELNET,
which was largely used for remote terminal login. While designed for Berkeley Unix (BSD),
it was adaptable to other systems too, and helped make TCP/IP popular. It worked, and while
the original code was rather sloppy, the price was right.
TCP/IP’s strength, as with its contemporaneous alternatives, was in dealing with bursty data
traffic. It scaled reasonably well, thanks to Moore’s Law, and with some rather critical
adaptations made in the mid-1980s, adapted to high-speed local area networks. It easily
handled new applications, including file and print services and the World Wide Web.
But it was not designed to replace every other network. Packet switching was designed to
complement, not replace, the telephone network. IP was not optimized to support streaming
media, such as voice, audio broadcasting, and video; it was designed to not be the telephone
network. Packet voice was tested over the ARPANET in the 1970s, so the idea is not new.
However, streaming over IP’s “best effort” model of capacity allocation doesn’t mix well
with data traffic. This was recognized by the late 1980s and streaming packet protocols, with
defined flows, were designed; the most successful was ST-II (see RFC 1190). But these didn’t
catch on. Instead, the rapid growth of capacity in the Internet backbone allowed streams to
just hitch a ride, working just well enough to catch on. It was a case where good enough was
the enemy of the best. The IP juggernaut was unstoppable.
A path forward
So if IP is so imperfect, can anything be done about it? Of course… but it’s not going to be
handled by incremental upgrades or missteps like IPv6. Instead, what John Day has done in
his Patterns in Network Architecture: A Return to Fundamentals is start afresh, taking into
account lessons learned in the 35 years of TCP/IP’s existence, as well as the lessons of OSI’s
failure and the lessons of other network technologies of the past few decades. He has made
some key observations that point to a new direction.
Day has been on the net since 1970, and participated in early work on TCP, TELNET, and
FTP, as well as the IFIP working group referenced earlier. He was, for some years, the
rapporteur of the OSI Reference Model. That is, he chaired the committee that was charged
with developing the famous 7-layer model which had itself been invented in the late 1970s.
Early on, the OSI upper layer group recognized that the model itself was fundamentally
wrong! Layers 5, 6 and 7 were really one layer, and did not work as separate ones. This was
known by 1983 and the protocols were refined to allow them to be handled together. But not
all implementers or textbook authors understood this, and attempts to build OSI-compliant
applications atop separate layer 5 and 6 protocol machines met with so much difficulty that
the whole OSI program collapsed. And indeed one of TCP/IP’s strengths was that it lacked
these superfluous layers. The IP community of the day was if anything practical, apparently
more so than it is today.
But fixed protocol stacks themselves turn out to be the problem! The pattern that Day noted is
that protocol functions tend to alternate as one goes up the stack. This alternation reflects a
repeating unit consistent with interprocess communication. The error and flow control
protocol breaks up into two functions, data transfer, which sends data forward, and data
transfer control, which provides feedback from the receiver. These functions both happened
in both X.25’s layer 2 and 3 protocols, and it also describes the relationship between IP (data
transfer) and TCP (data transfer control). Applications themselves have a common pattern
too.
Lower layers thus tend to do the same things as upper layers, but on a more local scale, with
more flows aggregated into them. At the application layer, a single instance frequently
communicates between two computers. At the other extreme, a large network backbone link
may carry thousands of processes, headed between many different computers, part of the way.
Recursive layers
This leads to the first principle of our proposed new network architecture: Layers are
recursive. The same protocol can be used repeatedly in a protocol stack, encapsulating each
layer in another instance of itself. There is thus no need for purpose-built protocols for each
layer. There is also not a fixed number of layers in the stack. The number of layers between
the application and the physical medium is variable; at any given point, there are simply as
many as needed, no more, no less. But any given implementation only needs to deal with
itself, the layer above it, and the layer below it. The actual depth of the stack is essentially
invisible.
Layers are not the same thing as protocols; more than one protocol can make up a layer.
Because the same group of protocols is used repeatedly, the implementation is simpler than
the TCP/IP stack. There’s no need for separate protocols for “layer 2”, “layer 3”, etc. Because
the layers recurse, and can scale to form a large internet, the protocol suite that supports the
concept from Patterns in Network Architecture (PNA) is called the Recursive Internetwork
Architecture (RINA).
The protocols that make up the basic RINA layer include the Data Transfer Protocol (DTP)
which relays the payload in the forward direction. Its contents includes addressing
information and protection information (a checksum and a time-to-live counter which detects
routing loops).
The Data Transfer Control Protocol (DTCP) performs the error and flow control functions,
sending feedback from destination to source. Note that DTP has the payload, which is visible
outside of the layer, while DTCP operates entirely within the black box. A layer also has a
management protocol.
Another observation that Day made is that networking is just interprocess communications
(IPC), a standard function on modern computer operating systems. IPC within a single
computer is quite simple; it could just take the form of memory shared between two
processes. IPC between computers requires additional mechanisms to deal with issues such as
reliability of communications and synchronization. That’s where network protocols come in.
Are the following statements true, false or not give according to the text?
1. TCP/IP is the last word in networking. Any subsequent networking must be based on
it.
2. TCP/IP was put in place to help us learn about how networks work.
3. The ISP industry is making less money every year.
4. The NCP is not the same as a telephone network because its space is only filled when
used not, whereas in the latter case the space is physically present and thus always
used.
5. Although the department of defense used TCP/IP it was not widely accepted
elsewhere.
6. Packet switching was made to work alongside the phone network. It was not made as
an alternative to it.
7. The function of a protocol remains the same through the earlier layers, then switchers
at it nears the top.
8. RINA is not as straightforward a system as TCP/IP because it uses the same protocols
more than once in different layers.
Find words in the text that mean
1.
2.
3.
4.
5.
6.
7.
8.
9.
In itself
A ring of light around an object
Make money and succeed
Fixed – the opposite of flexible
To suggest a theory
badly-though out or lazily designed
An unstoppable force
The part of the network that all the other sections are connected to
To come round again repeatedly