Ten Things Lawyers Should Know About the Internet May 25, 2009

Although this paper has ten points which concern laws and the Internet, they can be boiled down to three:

1. The laws relating to copyright, privacy, wiretapping, and common carriage are not relevant to the Internet today. Furthermore, trying to apply them to the Internet has many deleterious effects with no real gains, since the usage model of the Internet differs so much from the services provided at the time when the laws were written.
2. Furthermore, we actually know very little about the Internet from an empirical perspective. This is due to two factors. First, much of the current legislation (see point 1) makes it impossible (or rather, illegal) to gather the very information that would illuminate the usage patterns on the Internet. This hamstrings researchers, who are able to come up with many wonderful theories about current or future traffic patterns, algorithms, etc., but are unable to test or validate them on the Internet at large. Secondly, even when legal, these same efforts are frustrated by the fact that the Internet is composed of many private companies only motivated by relatively short-term financial concerns and unconcerned with the viability of their practices in the mid- to far future.
3. With both the legal and financial restrictions on what can and cannot be implemented, the Internet as it stands today is in a fair amount of risk. The underlying routing and naming services are insecure because they were designed for an Internet that is very different from the one present today. Not only are they insecure, but they are not designed to scale to the size of the modern Internet. Even though these problems are evident from even the limited amount of data available under current laws and from the companies operating the core routers in a secretive manner, the educated people who have exposed these problems are helpless to enact any change at a global level.

The main problem with this paper (and likely this summary) is that it views the current state of the Internet from a very pessimistic perspective. While it may be true that there are many unresolved problems on the Internet, it is risky for the researchers to look down from an ivory tower and proclaim that the Internet is doomed unless we do X, Y, and Z. What does need to happen is that government regulation needs to be designed in such a way as to not stifle the approaches that the market takes to optimizing the Internet for its current and future needs.

Future research needs to look at ways to incentivize the change that researchers think needs to be implemented. Unless they can provide economic incentives for the companies that control the Internet, then the changes will fall on deaf ears.

Internet Congestion Control for High Bandwidth Delay Product Networks May 19, 2009

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

 

1) The concept of decoupling utilization control from fairness control was a novel idea in this paper.  This stemmed some good points, for instance, opening up new avenues for service differentiation.  This was an important point from a business perspective, since ultimately what drives the deployment of new technology will hinge on large corporations adopting it.  Another good point is how this separation simplifies the design and analysis of each controller by reducing the requirements imposed. 

 

 

2) Since congestion is not a binary variable and requires a degree of values to truly measure it, the protocol must reflect this as well.  Because of this, Katabi et al ultimately decided to use a precise congestion signaling where the network tells the sender the state of congestion. From my perspective, this is the cusp of XCP since it allows them to have amazing results such as “rarely loosing packets” and “efficient use of bandwidth in a multitude of conditions”. 

 

3) The method in which they implemented XCP, a protocol based on network control of flows, with little overhead to routers.  By storing feedback information in a header, and making routers “stateless”, they estimated that a XCP router only performed a few additions and 3 multiplication per packet.  This is important as we are demanding faster routers and switches at the edge of our networks, any additional overhead may make a solution no longer viable.

 

(ii) The most glaring problem with the paper:

 

Although the paper considered security aspects and how to detect senders that do not honor XCP, they do not consider the cases of rouge routers.  Since this is a protocol that relies on the network (aka routers) from making the right choices, I believe that router security should be considered more.  Specifically, consideration of methods to avoid paths that routes through a router that you know is making poor or malicious decisions.  This is pivotal before XCP can be deployed in a commercial setting, since a single rouge router can trick the rest or the routers to believe that senders are misbehaving.

 

(iii) The future research directions of the work:

 

They seem to be very proud on the fact that in their tests, XCP rarely loose packets.  I believe this may have been a blind spot in their research.  A good direction for the research would be to analyze more dimensions of tests that involve XCP behavior in low reliability networks.  Since they aim to replace TCP, this is an important facet to cover the flexibility of this protocol.

Ethane: Taking Control of the Enterprise May 5, 2009

Three Important Things:

• The authors gave an outline for what they believed should be the fundamental principles behind any network management solution. Governing policies should deal with high-level names such as users, devices etc. This is opposed to applying filters at lower levels like IP addresses, which are in constant dynamic churn. Policy enforcement entails directing the flow of packets explicitly, and ensuring a strong binding between a packet and its high-level origin. A network control architecture called Ethane is proposed to implement these ideas.
• At the heart of the Ethane solution lies the centralized controller. The idea is that every network transaction is monitored and moderated by the controller. It handles registration and authentication of users and devices. This allows it to assign track the bindings between low-level entities and high-level identifiers. On the basis of these identifiers the controller can perform access control on packet flows, enforce resource limits on users, and program switches to implement multicast and anycast.
• A major concern for a centralized network architecture is scalability, as the controller is involved in the setup of every distinct packet flow in the network.  Experimental results on a small network showed worst case setup times of 1.5ms. Results for a large network trace showed latencies of .6ms for 6,000 setup requests per second and .4ms for 2,000 reqs/sec. This lead the authors to conclude that a single controller could handle up to 20,000 hosts.

Glaring Problem:

There are many enterprise class organizations such as universities, corporations, and governments that might benefit from adopting Ethane. However many of these logically contiguous networks are physically separated across numerous offices scattered around the globe.  The paper claims to present an enterprise solution but makes little or no mention of such a deployment and its associated implementation concerns.

Future Work:

The Ethane project showed that it is possible to administer a fairly large network with numerous users and device classes using a central controller. Having a viable centralized network management solution is a powerful tool, and I would like to see exploration of other possible settings for Ethane deployments. These could include high demand settings like server farms, or high security settings like internal government networks.

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.