IP Switching-ATM Under IP April 9, 2009

“IP Switching-ATM Under IP” by Peter Newman, Greg Minshall and Thomas L. Lyon is a paper about running IP over ATM. The internet and private enterprise networks traffic have been growing exponentially. To deal with this the authors suggest running IP over ATM because the ATM switching technology offers higher aggregate bandwidth. This gives the simplicity, scalability, and robustness of IP with the speed, capacity and multiservice traffic capabilities of ATM.

The authors start off the paper describing the need for IP over ATM. They bring up the cost difference for a router with limited throughput compare to a switch with more throughput. After mentioning why it is necessary to use IP over ATM, the authors show why other methods that try IP over ATM are incorrect. This is mainly due to the fact that the approaches hide the underlying network topology from IP so it is just an obscured cloud to IP.

The authors approach starts off by replacing the ATM software with a protocol they created called general switch management protocol. This protocol allowed the IP switch to control the hardware switch in ATM. They used soft states to cache flow information and allowed each switch to locally decide which flow to use as there basis in their design. They determined flows using the IP/TCP/UDP headers classifying the flows into two types, port-pair and host-pair. One important part of the paper is the point-to-point network model rather than a logical shared medium. This works because point-to-point is more natural for ATM and have been proven to scale to very large networks by the Internet. Another important part of the paper is the multicasting using IP over ATM. When an incoming multicast flow comes in, it will branch out to multiple destinations. Each of these branches can be redirected by a downstream neighbor. If the flow happens to be labeled, we can use the hardware multicast capabilities of the ATM switch. The last important part of the paper is the QOS. The authors were able to support both policy-based and contract-based quality of service. They supported contract-based QOS with RSVP to simulate something similar to ATM traffic management.

The paper’s impact on the future of networking can be seen from that fact that they are planning for the future. The future trends show traffic growing at a rate that the technology cannot efficiently handle. What makes this paper interesting in this sense is the fact that they used previous technology to address the problem instead of creating something new. A problem with this paper is their solution cannot detect loops from previous switched flows that differ only in TTL.

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

(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.