A Protocol for Packet Network Intercommunication April 7, 2009

Contributions:

This classical paper by Cerf and Kahn introduces the original version of the well-known TCP/IP protocol stack. Its main contribution lies in the abstraction of different underlying packet switched networks up to a mechanism of interprocess communication via an reliable, in-sequence byte stream. It hides implementation and environment details of the concrete networks the communication is happening on by removing assumptions of minimum packet sizes and fixed addressing schemes. Furthermore, they describe the Decorator-pattern to be used for wrapping multiple headers around a single packet, each serving a different communication component.

They also describe the functionality of a program called TCP (Transmission Control Program), which controls the network communication in each host on the network participating in the process-to-process connections. It is responsible for (de-)multiplexing the streams of each process on each communication end and ensures the reliability of the communication by providing mechanisms for establishing a connection, addressing processes, fragmentation, sequencing, retransmission and flow control between the communication partners. Definitions of the notion of a connection and a port are also given.

For all these mechanisms, it is described how the different fields and flags in the various headers are working together with the TCP implementation in order to achieve the implementation goals.

Problems:

The most glaring problem to me is the missing discussion of the processing overhead needed if all those mechanisms are implemented. Since all the mechanisms described stay on a conceptual level, the impact of actually implementing all of  them seems to be unclear.

Future work:

For this paper, the future work would consist mainly in building the specifications and prototype implementations for the proposed protocols. Once those are in place, they can be used to perform quantitative analysis on the performance sensitive issues of the protocols and how those networks behave under larger loads.

A Protocol for Packet Network Interconnection April 7, 2009

The paper introduces TCP (Transmission Control Protocol) as a protocol for providing internetwork routing, failure tolerant delivery, and flow control. These represent the main contributions of the paper.

TCP seems to have been born out of a need to handle delivery of messages across various networks. Networks that use protocols that may have different headers, packet design, maximum sizes, etc. TCP defines an internetwork packet format with sufficient information to send a packet from a source host in one network through any number of gateways to be received by a destination host (supporting TCP also) in another network. The network gateways may break apart the messages received to accommodate the particular needs of the network. The TCP packet design however allows for this and provides a simple set of rules to maintain appropriate TCP header information.

The unreliable nature of network transmission was also taken into account with TCP. The receiving host follows a protocol of acknowledging received packets. The source uses these acknowledgments to determine what data has been received and what is needed next by the receiving host. This mechanism also serves to provide flow control.

Flow control is a key characteristic of TCP. The positive acknowledgments returned to the source host also contain window size information. The window size indicates to the source host how much data can be received (and thus sent) before the receiver’s buffer fills up. This bit of information negotiates higher or lower transmission rates between the host pair and makes the protocol very flexible.

TCP has grown to become one of the key underlying protocols on the Internet, and this provides considerable proof that it has wide applicability. It is therefore difficult to identify “problems” with the protocol. One interesting point does stand out however. The introduction of a TCP address (comprised of 8 bits of network id and 16 bits of TCP identifier) seems a bit out of place. While the use of ports to distinguish endpoints on a host is a valuable level of indirection for host processes, identifying networks (and thus performing routing) using an 8 bit network id seems unrealistic. Indeed, it would seem that IP has replaced the need for such an id.

One of the common critisizms of TCP is that it uses considerable overhead to ensure reliablity. I would expect that given the overhead of positive acknowledgements that further research would be to explore the possiblity of a reliable negative acknowledgment equivalent/variant.

A Protocol for packet network intercommunication April 7, 2009

The obvious contribution of this paper is the introduction of the TCP protocol, something that remains with us to this day and was instrumental in the development of the modern internet. However the three greatest contribution that were a part of the overall theme, I feel, were:
1. The notion of a gateway as the standardized interface between two networks. The standardization of this idea enabled a large number of features, such as non-standardized fragmentation, that allowed the internet to scale as it became larger and a greater number of unique systems were connected.
2. The idea of standardized packets that enabled the network to be implemented using layers, adding layers of abstraction to the protocol. This was also critical in that different nodes on the network were not forced to read an entire message, only the part that they were concerned with. This is a huge performance consideration in modern systems that deal with billions of packets. Though the idea of layering had already been introduced, I feel their packet concept probably had a huge impact on the current 5 layer scheme due to its completeness of information and the thorough inspection that the authors gave to the different informational needs of the network.
3. The third thing that the paper contributed was the idea of using ports for the operating system to manage as its connection mechanism. This concept also standard today and provides for a flexible, yet standardized mechanism for to machines to communicate with each other. This also provided functionality for two ports to communicate with each other under the protection mechanisms offered by the operating system and the relatively simple management of multiple simultaneous connections.

The most glaring issue with this paper was the lack of implementation and real-world performance numbers of their proposed system. However, the authors do acknowledge this and state that that is the next step they plan to take. Some simple numbers would have helped them make their case though, as I imagine that there were a number of proposed protocols competing for acceptance at that time. Other than that, I think that the authors did a very complete job of addressing the different issues such as flow control, packet size, communication with the hosts, error detection, etc.

Future research in this area is relatively easy to determine as there have been a number of improvements to the protocol over the years that have mostly had to do with improved performance and scalability. Much of the current research in this area involves improved security features such as authentication between systems and other ideas that will make it harder to conduct malicious acts. The authors did not take this into consideration at the time, likely due to the fact that most computer users at this time were in academia, industry and government and could be consider trustworthy. They likely did not envision the size of the current internet and the growth of the personal computer. It is impressive however, how well TCP has scaled over the years.

A Protocol for Packet Network Intercommunication April 7, 2009

The biggest contribution in this paper appears to be the transmission control program, or TCP. The TCP as described here seems reminiscent of the stub/remote procedure call model presented in [1]. A TCP provides fragmentation and encapsulation of data, which makes it fairly easy to discern the destination of the packet and (to some extent) what to do with it once it gets there.

Second, TCPs provide some reliability mechanisms, in terms of retransmitting unacknowledged packets and checks for duplicate packets within a certain timeframe.

Third, the concept of gateways as an interface between multiple networks: a gateway is essentially a cut vertex on a network graph. The idea is that one can use two completely different protocols — one for each network — but still get the data through. The gateway may reconstitute and refragment packets as it sees fit, and may readdress something so that it goes to the proper place within a network. A possible analogy is currency-changing: it’s worth the same overall, but separated in different quanta and accepted in different places. I would imagine that the concept of network address translation is a derivative of this.

The paper mentions using a window for retransmission of packets to avoid the problem of finite sequence numbers. However, to transmit a very large piece of data, one might run out of sequence numbers, especially if transmitting a large number of small packets.

References

1. A. D. Birrell and B. J. Nelson, “Implementing Remote Procedure Calls”, ACM Transactions on Computer Systems, Vol. 2, No. 1, pp. 39-59, February 1984.

A Protocol for Packet Network Intercommunication April 7, 2009

This paper discusses the protocol for sharing of resources that exist in different packet switching heterogeneous networks. This paper introduces the ideas that we see in present day TCP/IP. Though IP term has not been used in the paper, it is implicit in the ideas of Gateway and routing across different networks. Here communication has been discussed at process level. It is assumed that each host can have more than one process that needs to communicate with other processes on different hosts. It has been mentioned that individual switching networks can differ in implementations. Some of these include addressing modes of individual networks, difference in data size of individual networks, timing procedures for determining the success or failure of transmission, end-to-end restoration procedures for complete recovery from the mutation of data,

Status information, routing, fault detection requires co-ordination among networks. Paper introduces the concept of Gateways to resolve these differences among different networks by providing suitable interfacing at the boundaries. It is further assumed that common protocol is used between HOST’s and processes in different networks. Gateways have the responsibility for proper routing of the packets. Gateways determine the routing based on the source and the destination address embedded in the packet in the form of internetwork header. Internetwork header also contains the sequence number and byte count used for proper sequencing of data at the destination host and error recovery by the host. One important step performed by the Gateways is reformatting of data. It has been anticipated that in future it would be very difficult to increase the maximum permitted packet size in response to new technology. This looks true even today. Most importantly re-formatting insulates the internetwork communication from changes in packet size of individual networks. Though it looks natural to do the reassembly of packets also in Gateways to reduce the complexity at host level/process level or to take advantage of large packet size paper rejects this idea on the grounds that it may lead to serious buffering problems, potential deadlocks, the necessity of all fragments of a packet to pass through the same gateway resulting in the increased delay. Paper introduces the TCP which handles the transmission and control as well as multiplexing and de-multiplexing of segments on the behalf of processes. Concept of port address is also discussed to permit a process to distinguish between multiple message streams. Paper also discusses the reassembly and sequencing. Issues introduced by having finite number of sequence are also introduced in context of retransmission and duplicate detection. Retransmission has been envisioned to be required only due to infrequent over demand for limited buffer resources. Concept of window is used for detecting the duplicates while re-transmission. Further connections are introduced for the fact that processes reuse the ports and these are not static.

A Protocol for Packet Network Interconnection April 7, 2009

This paper describes a protocol which seems to be the predecessor of the TCP/IP suite used today by the Internet. It makes the argument that packet networks are likely to use different conventions, which makes trying to standardize on one packet format difficult, if not impossible. Therefore, they propose a standardized internetwork header, which can be read and interpreted (at least in some sense) by the gateways between different networks. This internetwork header contains all of the information necessary to determine the destination of the packet as well as information useful for sequencing and fragmentation. On top of this internetwork header, individual networks are free to add a local header or trailer to allow the packet to traverse that particular network on its way to the next gateway or the destination host. Also described in this paper are addressing formats (network/TCP/port), sequence numbers (which address bytes relative to the start of the message stream), and a very powerful retransmission mechanism. The retransmission mechanism uses a “window” over which data can safely be sent, with the notion that it is safe to send data as long as the receiver knows that it is not receiving outdated packets. The only complicating factor is synchronizing the sequence numbers at the beginning of an association, which is handled by providing a special SYN bit to indicate the start of an association.

In my opinion, the biggest problem with this paper is that they provide no flexibility for future network growth. While the fragmentation mechanism is excellent for supporting larger and larger packet sizes as technology advances, the addressing scheme (as we have seen with the push from IPv4 to IPv6) is limited by what they see as the largest conceivable network. Unfortunately, networks have become much larger than the initial network designers could conceive. Perhaps it would have been better to allocate more bits to the address space (just a stopgap unless it is taken to the extreme a la IPv6), or even better, to somehow make it possible to specify how many bits were being used for addressing. As long as only a few bits are necessary, the header can stay small, but as more bits are required, the header can grow slightly to greatly increase the address space.

Future research in this area might include ways to make the protocol more flexible in the face of networks which greatly surpass the properties of networks conceived of in this work. As mentioned with variable-size addresses above, maybe the approach should be to make a standard, but flexible format which allows organic growth, which might ease the pain we are currently feeling in the transition to IPv6, which requires a dual-stack architecture.

A Protocol for Packet Network Interconnections April 7, 2009

The authors make the observation that hosts often need to communicate across homogeneous networks, and that the best way to facilitate this is through gateways at the network boundaries. This approach handles formatting and fragmentation issues without compromising the integrity of the message. A key point is that gateways can perform fragmentation as needed but should not be responsible for reconstructing segments. This is left to the end host, because there are no guarantees that any one node other than the host will have all the packets go through it, and because the processing done at the gateways should be kept to a minimum. This follows from the end-to-end argument.

This paper introduces the concept of a reliable message queue between two processes. This is a natural and powerful abstraction for designers as it allows a process to provide a message and a destination and not have to worry any further about transportation. Key points are that each host must have a globally unique identifier, and that the notion of a locally unique port must be introduced to handles multiple processes on the same host.

The most important thing about the protocol is that its functionality is built on top of an unreliable, best effort network. By constructing the protocol around a sliding window, the authors are able to achieve reliable, in-order delivery. In addition, they are able to leverage the size of the window to implement flow control. This again falls in line with the end-to-end argument, and represents the “smart” host’s attempt at deducing the state of the network without any explicit information.

I would say that a drawback of this paper is that it does not contain any formal verification or at least simulation results. One or both of these would have been very useful in backing up the major contributions like flow control. The authors provided a solid framework for implementing TCP, but it does not seem that they actually deployed it at this point.

This is an incredibly significant paper in the history of networking research, and the concepts contained in it have been thoroughly analyzed, refined, and followed up on. In this context it is useful to think about what fundamental new directions future research could take. One such direction could be to identify abstractions other than the shared queue that TCP provides that might be useful for process communication. I believe that as the internet evolves and overlay networks become prominent a variety of special purpose abstractions will find widespread use.

A Protocol for Packet Network Intercommunication April 7, 2009

Important:

1. The internetwork packet format allows communication among network comprised of various underlying technologies. Ad-hoc procedures for internetwork communication do not scale and require particular expertise to implement. Standardized gateways facilitate interoperability among various networking technologies. A standard format allows widespread deployment and interoperability. Wide-area communications among distinct yet interconnected networks becomes a commodity available to neophytes.
2. Reliable end-to-end messaging is required for most networked data applications. Ad-hoc procedures for reliable communication do not scale and require particular expertise to implement. A standard procedure allows widespread deployment and interoperability. The protocol addresses issues required for reliable communications. Guaranteed delivery is assured even when packets are dropped, fragmented, or reordered. Reliable wide-area communications among distinct yet interconnected networks becomes a commodity.
3. Flow control optimizes performance. It prevents the receiver from becoming overwhelmed and dropping delivered packets. Packet loss at the receiver or in the network wastes network capacity. The network must carry the dropped packets more than once.  Increasing flow improves end-user performance. The difficulty is balancing performance and utilization.

Problem:

Security is not addressed. Malicious users are not anticipated. TCP connections can be hijacked if one end becomes unable to communicate. Denial of service attacks can prevent an end-station from receiving and can cause hosts to practically cease functioning.

Future:

End users are required to implement security above the TCP layer. This becomes another instance of the wide-area interoperability problem the packet format and TCP address. A standard for secure interoperability is required. Techniques for identifying and eliminating an attack or forestalling attacks altogether are required.

Scalable flow control that doesn’t waste network resources but allows high speed data transfer is required. Links that are asymmetric in capacity are challenging. Dropped acknowledgments are as harmful as dropped data packets.

A Protocol for Packet Network Interconnection April 7, 2009

This paper discusses the need for a common protocol between different packet switch internetworks in order to communicate effectively between these networks. The authors design a protocol that can handle packets of different size, provides error checking, flow control, congestion control, and an addressing mechanism for the network hosts and the processes running on these hosts. Some of the key points of this paper are:

1. A common protocol between different networks can ease communication while allowing the underlying networks to be as different as they want. There needs to be a ‘gateway’ to connect any two networks together, and for this gateway to be able to route messages easily between networks, there needs to exist an agreed upon protocol. The gateway can use the agreements of the protocol to translate messages between the two networks. For example, having an agreement on the smallest possible packet size, the gateway might split a large packet from network A into two smaller packets to be handed to network B.
2. The paper suggests that each host should be responsible for translating its messages to the agreed protocol. To do so, a transmission control program (TCP) should reside on each host. The TCP might fragment outgoing messages into smaller segments, or put together incoming segments as one message. The TCP determines which process the incoming messages are intended for.
3. The notion of ports allows process-to-process communication between the hosts, with each port being used by a specific process on the destination host. The TCP handles the job of multiplexing and demultiplexing network messages based on the specified port. Sequence numbers in the packet allow for duplicate elimination and for out of order transmission of messages. A checksum is provided for error detection. A ‘window’ size allows for flow control. The use of acknowledgment messages makes it easy for a busy host to ignore incoming packets intermittently, since they would be retransmitted by the sender if no ACK messages are received.

One glaring problem would be that there are no experimental results to assess the practicality of the proposed protocol. Although the authors agree on this, they do not provided further analysis or speculation about any overhead that the proposed protocol might have. The addition of TCP on each host has extra processing overhead, and the protocol’s packet header adds to network traffic as well. The paper also does not discuss if the protocol is flexible enough to handle future modifications. They further assume that 8-bits for a network address “seems sufficient for the foreseeable future”. We have seen that such assumptions about the future needs tend to fail unless the assumptions are flexible and are allowed to change when needed.

There has been research done on how to modify the existing protocols to match the needs of the internet. IPv6 was designed to cope with the growing needs in addressing, but it has been a slow process to incorporate this new protocol into new devices. Perhaps a more flexible solution for the future would be a variable length communication protocol that can easily be extended to cope with the future needs (I am not aware of any research on this, as I have little knoweledge of computer networks).

A Protocol for Packet Network Intercommunication April 7, 2009

This paper talks about a protocol design and philosophy that supports the sharing of resources that exist in different packet switching networks. It tries to address the downsides of using different protocols for distinct networks and introduces Gateway as the means for interfacing between different networks and unifying the protocol.

The gateway performs the task of routing the packets between different networks. It also takes care of variation in individual network packet sizes by fragmenting the packets which are then reassembled at the destination host. The author argues that gateway is the best place to fragment (if need arises) because it has the knowledge of individual network packet size demands it connects. But, at the same time, it is not an ideal place to reassemble them before delivery because it can lead to buffering problems, potential deadlocks, necessity for all fragments to pass through the same gateway and increased delay in transmission. Therefore, one of the important highlights of the paper is introduction of gateways.

Another important highlight of the paper is the Transmission control program (TCP) which runs on the hosts and handles the transmission and acceptance of messages on behalf of processes it serves. Multiplexing and demultiplexing of segments among processes are fundamental tasks of the TCP. This is accomplished by way of the process header embedded in the packet. The address formats for packets are discussed and gateway is entrusted upon the task of routing the packet by observing the destination network ID. The packets can arrive out of order at the destination hosts depending on the way they are routed and it is task of TCP to reassemble them for a particular process using sequencing of packets. The finite number of distinct sequence numbers poses a problem during retransmission and duplicate detection and the concept of window is proposed. This concept of window sequencing ensures that sender will not transmit more than w bytes without receiving an acknowledgement from the receiver. The sliding window also allows for variation of window size which leads to better flow control. Certainly, the concept of sliding window is crucial in coping network congestion in today’s increasingly complex and busy networks.

The paper also talks about the transmission and receiver control blocks for instructing the TCP regarding the information needed for extracting and sending the process data and computing checksums and message delivery respectively. The concept of associates is discussed in the event of finite port identifiers with the hosts and SYN, REL and LISTEN functions are discussed for establishing, accepting and terminating the connections between hosts.

A Protocol for Packet Network Intercommunication April 7, 2009

(i) Three most important things

1. There needs to create a protocol that allows for variation in individual network packet sizes. The paper introduces the idea of a Gateway as an interface between networks that can reformat an incoming packet so that the data can be passed along to the next network.

2. There needs to be a scheme to handle transmission failure. The paper proposes the use of timeouts and acknowledgments to handle transmission failures. A TCP transmits packets and waits for acknowledgments and if no acknowledgment is received for a particular packet then the TCP will retransmit.

3. In order for communication to take place between two processes, there needs to be a way for one to address the other. The paper claims that interface message processors do not have to open and close connections from source to destination in ARPANET because the connections are essentially always open since the address of every source and destination is never reassigned. The first packet sent to the receiver is marked so that the receiver knows it’s the first packet of the transfer and can synchronize with the received sequence number.

(ii) Most glaring problem

The most glaring problem would be that no experimentation has been done. The paper provides a detailed description of the protocol but the protocol needs to be implemented so that a realistic evaluation can be conducted. Usually we don’t know what we are missing until we actually implement our design.

(iii) Future Research Directions

Future research directions for this work would be to actually implement the protocol proposed in the paper. There should be follow up paper with the results of their implementation and address any problems that arose in the process. The follow up should also address how their protocol would hold up if implemented at a large scale.

A Protocol for Packet Network Intercommunication April 7, 2009

This is a seminal paper in the history of networking and packet switching communication. The paper presents the design concepts and decisions that the authors followed for the definition of the TCP/IP protocol suite.

(i)Three most important things/properties of the protocol suite presented in the paper:

1)Separation of concerns. In the paper the authors distinguish clearly what are the responsibilities that need to be addressed by the TCP and the IP protocol. The main IP’s task is to route packets over the network from the sender to the receiver. It is also task of the IP protocol to enable dynamic interconnection between different network technologies. This interconnection is performed by the gateway that decodes the incoming IP packet’s header and adapts, by using the fragmentation technique, the packet’s size to the size required by the outgoing network technology. The gateway does not reconstruct nor reorder the fragmented packets. This is performed by the receiver using the sequence number contained in the message. The rationale behind this is that otherwise the gateway should have to deal with the buffering of several incoming packets in order to rebuild at each step the original message. This would create several buffering problems as well as it would very hard to implement since the packets can follow different paths to go from the sender  to the receiver.

The TCP instead is responsible for multiplexing and demultiplexing of segments among processes. The authors define the concept of association as a state where two processes are ready to communicate over the network. This happens when they exchange with each other the port numbers through which they will communicate.  A communication between two processes is identified by the two hosts plus the relative port numbers. The TCP provides a full set of features, such as reassembly and sequencing of the incoming packets, retransmission and duplicate detection, flow control and a correct and complete (reliable) transmission of the message from end to end.  All these features are enabled by the TCP through three fields in its header: the sequence number, the window size and the checksum, plus an acknowledgment of each segment received. Probably the most remarkable thing about the TCP is that even if it was designed when only few dozen of computers were connected over a network,  it has been able to perfectly serve the needs of an infinite number of applications and to connect billions of people around the globe and lately also in the space. We can definitely claim the the TCP/IP suite was one of, if not the one,  the best engineered communication protocol.

2)Layering. TCP/IP are two different protocols that work one on top of the other. Though this cooperation between the two, a reliable and efficient communcation is performed. As said at the previous point, TCP connects two different processes over the network by using the service offered by the IP. Each protocol exposes a well defined interface to the other protocol. The TCP provides to the IP all the information needed by the IP to deliver the segment such as source and destination address. The IP bundle up the segment, or a part of the segment, in a packet and send it through the network to the destination host. During the routing from an end to the other, only the information contained in the IP’s header is used for the routing. The transmission over the network is completely transparent for the TCP. Once the IP has delivered the packet to destination, the TCP comes into play and with its fields and functionalities it is able to reorder and reconstruct the message.

3)Network independence. The TCP/IP protocol is able to provide a reliable packet switching communication over every kind of network technology. The IP can adapt the packet size to different network requirements as well as the TCP can then reconstruct and reorder the packets, verify the correctness of the whole message with the checksum and ask for retransmition of a message in case something went wrong during the transmission.

(ii) Most glaring problem.

The authors define this complete suite of transmission protocol but they do not present any result about the performance. A protocol could potentially offer very fancy and complex features at the cost of a big transmission overhead. Today we perfectly know that it is not the case of the TCP/IP, since it has over proven its quality and efficiency. But at the time they did not know it yet, or at least they do not mention it in the paper.

(i)Future research.

The TCP/IP has been extensively tested and studied for over 35 years and it has proven to be a vey good protocol suite. However, since the new IP, the Ipv6, is coming out, it would be interesting to perform a complete end-to-end argument analysis over the TCP features to see whether by moving down some of them to the IP level we could get a performance benefit.

A protocol for Packet Network Interconnection April 7, 2009

1. Gateways are the only nodes that require knowledge of outside networks.

In the protocol proposed by the paper, nodes called gateways are used to interconnect different networks that implement different protocols. One of the more appealing features of this protocol is the fact that gateways are the only nodes in a network that need to have knowledge of external, connected networks. The other nodes in the network are insulated from having to support any additional protocol. They need not have knowledge of addressing methods, error-checking methods, packet size or other features that define the protocol of a connected network. The gateway performs all address translations and if required embeds the inter-network packet in a header defined the protocol of the local network so that all the nodes in the network need to do is route the packet according to the new home-network header (if added).

2. Packets may need to be fragmented as they cross networks. Efficient accounting and protocol to support this

Packets may need to be split as they pass through gateways of different networks to meet the maximum-packet size requirement of the current network. The paper makes note of this fact and in all methods that it proposes ensure that this is taken into account and accommodated. It provides for ES flag so that if a packet containing a complete segment is split at a gateway, the receiving TCP knows how to reassemble the segment and identify the packet containing the last segment. This also allows for the original checksum for the complete segment to be used. No checksum needs be calculated for each smaller packet formed. The TCP also knows the packet that contains the checksum for the segment. It also proves an efficient (for most purposes) and fair method of accounting and charging for packets carried by a network that takes into account this fact. It says that the price of carrying a packet through a network is proportional to the size of the packet. This way, even if a single packet is split into 5 smaller ones, the transmitting network only has to pay 1/5^th the price of carrying a the complete packet for each of the smaller packets. Hence, fairness is maintained.

3. Window method supports retransmission, duplication detection, flow-control and inter-connected networks

The paper uses windows to achieve both re-transmission/duplication detection and flow-control. Though the window strategy isn’t original to the paper, the paper does a good job of identifying the method that would work efficiently with the underlying structure (inter-connected networks implementing different protocols) and could be used to realize multiple features that a communication network needs to provide (flow control and duplication detection)

Over sights/Short comings:

The paper imposes a common ‘inter-network header’ on all its packets. Though this simplifies the protocol to a great extent, it also implies that all nodes on all inter-connected networks need to have a common addressing scheme with the nodes on one network aware of the addresses of nodes on another network.. This also implies that, if a preexisting network needs to be connected to this inter-connection of networks, all its host nodes might need to modify their TCP layers to form packets with headers in the ‘inter-network header’ format.

In the protocol proposed, packets could get fragmented so that some of the packets have no checksums. It is possible that at the next gateway, these packets might enter a network that supports larger packet size. At the gateway to such a network, these fragmented packets may need to be recombined. When the gateway to such a network, combines fragment packets to form a larger packet, it is possible that 2 or more packets with no checksum in them get combined. This would lead to large packets being formed without a checksum which in turn would reduce the error detection capability of the protocol and the network.

Future Work:

Support for inter-connected networks that do not require their packets to have a common internetwork header. This way, additional networks could be added to the existing interconnected system of networks with minimum effort.

The paper also assumes that the candidate networks provide for certain features such as acknowledgments and a common re-transmission policy. It would help if an additional abstraction layer could be provided that didn’t impose specific policies on the individual networks and allowed them to continue with the policies defined by their protocol.

A Protocol for Packet Network Interconnection April 7, 2009

The paper describes the details of the different layers in the TCP/IP protocol and presents one of the most seminal ideas in the internet communication. The paper describes the design of communication protocols between hosts which are located on different networks and may use their specific protocols. For these they have proposed the use of GATEWAYs that will act as bridge between two or more different networks and appropriately convert packets to the respective format while passing from one network to another. The differences in the networking protocols can be different packet sizes, headers etc. The GATEWAY will take the responsibility of fragmenting the data if necessary thus adjusting to the specific protocol and parameter limits of the network. They have also described the TCP or transport layer protocol in detail that is responsible for preparing the data and delivering it to the right process in the host. For this, the notion of a port is introduced which uniquely identifies a buffer area on a host. Thus the TCP layer handles all the multiplexing and de-multiplexing of data into the ports by port number. It also handles the error correction and control at this layer, thus re-transmitting lost packets or removing duplicates. It uses a sequence number for each fragment of a message to correctly reconstruct the original one. It also handles flow control by using a sliding window protocol where the overflow can be managed by changing the size of the advertised  window to the sender.

The basic problem that has been addressed in the paper is packet switching in the internet and deal with the potential failures and pitfalls. When messages and transmitted in forms of packets, many failures like loss of packets, out of order arrival, buffer overflow etc. can occur. The TCP and the IP layer together cope with such problems thus making the transmission reliable. Each TCP packet carries a sequence number to rearrange out of order packets at the destination TCP layer. Also flow control is another problem that the destination host must deal with due to limited buffer. For these a window based protocol is designed which only accepts and acknowledges packets in a limited window and slides it only after all packets within the window has been received. The receiver can also inform the sender to reduce the window by sending it back in the acknowledgement to avoid buffer overflow. The paper also addresses the problem of setting up of connection between the source and the destination before data communication. Though there is no notion of a connection as such, the set up allows the two communicating hosts to know each others addresses, starting sequence numbers and port numbers, etc. needed for further transmission of packets.

The ideas presented can be further explored and refined to distribute the functionalities in the different layers more efficiently. Supports for debugging the network protocol can be provided in the layers that will be able to efficiently track failures. Also the performance of such protocol should be taken into account while designing it, instead of merely the correctness. Finally as mentioned in the paper, more detailed specifications should be laid out to actually implement and test the protocol. That may uncover many more pitfalls than initially apprehended and provide more insight into the actual feasibility of the protocol. The paper in fact laid the foundation of the future networking protocols which is widely accepted as the standard of internet communication today.

A Protocol for Packet Network Intercommunication April 7, 2009

The paper presents a protocol to connect networks with different packet switching implementations. According to the paper networks primarily differ in addressing, packet size, status information, routing etc. The paper thus proposes a protocol to interface these different networks through Gateways which would play the central role in internetwork communication and hide the complications inside individual implementations. A Gateway is a mechanism by which two networks communicate. Maximum packet sizes of the networks on either side of Gateway can be variable and this variability is handled by fragmentation. The job of the Gateway hence is to break the arriving packet into fragments which are then reassembled and reconstructed at the destination. The Gateway reads the internetwork header (appended by the source host) of the packet to determine the address of the destination before forwarding it appropriately.

The paper then presents a model of communication between various host processes and proposes a Transmission Control Program (TCP) associated with each host which does the job of multiplexing packets from different source processes and de-multiplexing incoming packets from packet switches (precursor to the TCP of present day!). TCP makes use of the process header to identify the destination of an arriving packet and this header is augmented to each packet segment. A uniform address space format understood by both TCP and Gateway is proposed with 8 bits to identify a network and 16 bits to designate a TCP (equivalently a ‘host’). A packet upon reaching an intended destination port (equivalent to a buffer region) is then subject to reassembly using the byte relative sequence number and the message byte count information present in the packet. Additionally the ES (end of segment) and EM (end of message) flags are attached by the Gateway when it splits a message into several internetwork packets. Since sequencing numbers are finite, transmission duplicates are a potential problem and they need to be recognized and eliminated by the receiver. This is done by employing a sliding window type of technique where no more ‘w’ (window size) packets are transmitted before receiving a valid ACK. The windowing mechanism allows for additional flow control by leveraging on variable window size and provides synchronization by window edge alignment.

The paper requires input and output buffering at each process to store and forward the packets (i.e. handle I/O). Additionally each process has to also setup and initialize receive and transmit control buffers to store control information attached to a reception or transmission. The authors of the paper present a set of association semantics for the network connections given a finite number of ports. They introduce the concept of SYN, REL, Listen functions without delving into their details.

The paper concludes by calling for a detailed specification of the protocol presented. Hence a take off point from the paper could be to leverage the TCP that incorporates connection-oriented links and datagram services between hosts and build a detailed protocol specification that implements internetworking and connection controls. Today’s TCP/IP stack, the internet protocol suite emerged out of Cerf and Kahn’s seminal work on inernetworks presented in this paper.

A Protocol for Packet Network Intercommunication April 7, 2009

“A Protocol for Packet Network Intercommunication” by Vinton G.Cerf and Robert E. Kahn is a research paper that describes a protocol to support sharing of resources on different packet switching networks. The paper introduces some important concepts that eventually evolve into IP and TCP.

The paper introduces the concept of a gateway. A gateway is the interface between networks. It is important to note that the gateways route the data using a store and forward method. Using the gateway to reformat packets of data so that the network it represents can read it properly makes sense. Another important point brought up by the authors were routing using a universal source and destination address. Since every gateway needs to be able to read these addresses they must be global. It is also possible for the local network to understand the addressing scheme to bypass the gateway for routing. This is an early influence on IP.

The other concepts that the authors introduce make up TCP. They describe how to handle flow control, time-outs and demultiplexing of messages to different hosts. The key ideas here are the sequence numbers for each packet, the acknowledgements of packets when they are received, time-outs and the sliding window for flow control.

The last big concept the authors address is the notion of a connection. Since there is evidence, from ARPANET, that showed that message based connection free protocols can be constructed they approach the idea of connection carefully. They use the term associates instead, and they show that two associates do not need to know that they are connected until they need to transmit data to one another. This is done by trying to send data from associate A to associate B and waiting for the ack.

Some major problems with the paper are: they use 8 bits for the network address, stating that it will be well then enough when we know now that it is not, the time-out retransmission do not work for all cases which can be a problem from “End-to-End Arguments in System Design” and the idea of routing and transmission should be separated as it is today.

This paper has future implications as a guideline for future protocol designs. This is because this paper lays out their design choices, assumptions and justifications very well.

A Protocol for Packet Network Intercommunication April 7, 2009

(i) the three most important things the paper says

This paper presents TCP, a communication protocol abstraction on top of the data link layer. There are many concepts from this TCP paper. TCP provides end-to-end reliability where the ends are processes on hosts. Packet sequencing and window based flow control is introduced to TCP. TCP introduces ports multiplexing/demultiplexing to identify connections between processes. Different source/dest port connections result in separate connections and are sent in different TCP messages. TCP protocol and gateways are introduced and designed to abstract away data link addressing differences, MTU differences with fragmentation, and data link protocol differences.

(ii) the most glaring problem with the paper

The paper provides ideas and concepts but no test implementation. Congestion avoidance at gateways has practical problems. TCP’s addressing scheme is not extensible and talks with regards to accounting, for example, was done in a few sentences without detail.

(iii) the future research directions of the work.

The important concepts from this paper provide grounds for future research on next generation transport layer protocols, addressing, congestion avoidance and routing algorithms.

A Protocol for Packet Network Interconnection April 7, 2009

(i)  The three most important things the paper says:

1. It is most efficient for each packet should contain a process header. Even though this costs a bit of space at the beginning of each packet it makes all of bookkeeping and message transmitting much easier since all of the message info is in each packet. It means that there will be no confusion even if packets from different processes are delivered intermixed.

2. The paper describes a mechanism to divide up packets so they can fit under any gateways limit but then still be reconstructed by host. This allows you to send packets based on one networks size specifications and be guaranteed delivery of the entire text even though you are passing packets though other networks that can have smaller size limitations. It also instructs that packets should only be recombined by the host since it very well may need to be divided again later.

3. The sender is allowed to send as many bites as he wants and the ack will contain a new position specifying how much the network has sent. This allows the sender to try to send as much as he wants without worrying that it is over the limitation which can be quite an optimization. If it is he will just get an ack stating that only so much was sent then can resubmit the rest.

(ii)  The most glaring problem with the paper:

The paper describes that the address space is only for 256 separate networks seems too low, this may have seemed quite big at the time but now seems very small. This should be an easy fix in the protocol by just extending the number of bits representing the network address.

(iii)  The future research directions of the work:

It seems that error acknowledgments could definitely improve efficiency in some situations. If a sender commits an error he currently has no way of knowing if the packet was not received or there was an error.  He therefore will probably retry a few times before giving up with no feed back. This paper also does not contain any experimentation with the proposed protocol. It is necessary to begin experimentation to verify the theory of this paper.

A Protocol for Packet Network Intercommunication April 7, 2009

(i) the three most important things the paper says:

1. The paper describes a protocol for sharing resources among different packet switching networks. It provides some mechanisms and makes a number of design decisions in order to accommodate the differences inherent in the different packet switching networks and so that packets may be sent across networks. Some of these ideas touch on address and packet formatting, packet splitting and reassembly, and retransmission and duplicate detection.
2. The paper introduces the notion of a gateway, which acts as an interface between networks and handles inter-network packets using a standard format. The gateway between two networks (say networks A and B) consists of two halves. Each half acts as a translator for the the network it is associated with, and formats packets from its local half to meet the requirements of the network on the destination half. An internetwork header is required for the gateway to obtain the addresses of the source and destination hosts. Gateways may be required to fragment one packet into multiple smaller packets if its associated networks handle differing packet sizes.
3. The paper describes the sliding window strategy for retransmissions. The sender only transmits bytes from a certain “window” of sequence numbers. The window slides when the receiver sends acknowledgments of received bytes. Bytes that have not been acknowledged are re-sent after some timeout period.

(ii) the most glaring problem with the paper:

Scalability is a large problem facing networks and inter-network communication. A number of issues arise as the number of hosts (and processes per host) increase. One particular example is the number of bits used in the network field of the TCP address. The name space for network identifiers is 256 (8 bits), which is clearly insufficient for current standards. Compounding the problem is that the protocol standards need to be fairly static, as it is exceptionally difficult to propagate protocol changes in the internet (since the internet is enormous in scope but everyone needs to use the same standard to communicate).

(iii) the future research directions of the work:

The ideas outlined in the paper are fairly general, and certain details need to be worked out in order for the protocol to be fully functional (for example, the “suggested” field lengths actually need to be made concrete so that they can be implemented by the TCPs).

Another research direction is in finding network optimizations – for example, where best to place network gateways to best balance traffic and optimize the path that the packets need to take. A third research direction is to deal with the issues raised by the scalability of the internet (for example in the problem mentioned in section (ii) on the number of network identifiers, how to introduce more networks with little or no change to the protocol).

A Protocol For Packet Network Intercommunication April 7, 2009

Title: A Protocol For Packet Network Intercommunication

(i) The three most important things the paper says:

1) Problems with individual packet switching networks are compounded when dissimilar networks are interconnected. This was the key point of the paper, as Cerf and Kahn saw that the future of computing would involve connecting dissimilar networks. In addition to pointing out the problem, they also provide a rudimentary system for how the common problems can be handled (e.g. flow control, retransmission, addressing).

2) Interface between networks should be abstracted into a gateway. Instead of proposing a system in which all processes share a protocol, they pushed the idea of abstraction. By using gateways, they allow different systems to continue and use the internal network protocol that was most efficient for them, and rely on the gateway to pass packets to other network seamlessly. This is a practical approach to allow their proposal to be adopted quickly by the community, since it doesn’t require current network systems to be completely rewritten.

3) The idea of TCP which handles the transmission and acceptance of messages on the behalf of process. The paper discusses in great length the problems with communication between internetworks and how the TCP can solve these problems. Their discussion in detail of the TCP was the starting point of our current TCP/IP protocol which obviously was a huge success. Their ideas of sequencing and using windows to detect retransmission and ACKs was revolutionary at the time.

(ii) The most glaring problem with the paper:

This paper gives discusses in length a “hypothetical” approach to solve this problem. However there were no experiments that was performed to prove that their solutions for the common problems (e.g. out of sequence) are solved by using their strategy. Unless concrete proof is provided they can not be sure that the major problems associated with internetwork communications are addressed by their proposal. For instance, just off the top of my head, I can see how their system wouldn’t be able to recover from a faulty gateway performing incorrect translations.

(iii) The future research directions of the work:

The future direction of their work would definitely involve how this system could be extended for a larger user base such as the current internet. For example, their system of addressing is obviously not sufficient to handle the many computers on the internet today. Also other problems that are associated with a larger user base that should be considered are security (e.g. man in middle attacks) and time out issues with packets traveling longer distances.