Graduate Networks, UCSD

CSE222 – Spring 2009

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.

 

ROFL: Routing on Flat Labels May 4, 2009

Filed under: Extra Papers — giledelman @ 12:32 am
Tags: , ,

Three Important Things:

  • The motivation behind flat routing is the desire to separate location from identity. Having labels be flat implies that no location information is stored in a host identifier. This fundamental change brings numerous advantages for individual hosts such as mobility, multihoming, and stable identity. These are the benefits of location/identity separation. Removing location altogether brings further benefits; The paper proposes to reuse DNS infrastructure to provide naming, which would leverage existing resources. Allocation must only satisfy uniqueness and does not need to confirm to the physical characterisitics of the network.
  • Intradomain routing is a basic building block for the flat label scheme. A new arriving host is assigned to a first-hop router which is responsible for determining its “successor” and “predecessor,” effectively inserting it into a ring topolgy. In addition, the host is assigned an “external successor” for forwarding packets outside of the local domain. Packets are forwarded along the ring in a greedy fashion towards the destination host. The first-hop router can cache the path . Interdomain routing follows in similar syle, with the additional border router complexity for enforcing ISP policies. One can imagine each internal domain as a small ring, with the border routers for each domain forming their own large interdomain ring.
  • In order to ground their claims of viability, the authors gathered traces from 4 moderate sized (200-600 internal routers) ISPs and performed several simulations. Standout results were 1MB of path caching on a typical router, 40ms host setup latency, and 45 control messages generated per host per join request. These numbers were for intradomain routing, and were used to extrapolate information about Internet scale networks. The authors felt they could do this because of the similarities between interdomain and intradomain routing.

Glaring Problem:

Though several interesting and exciting potential benefits of ROFL were presented, not all of them were explored in depth in the discussion that followed. Possible security applications were only briefly mentioned, and the adaptation of DNS to work with ROFL was not discussed. Host mobility was implied (through a rejoining operation) but not explicitly described.

Future Work:

Given that the performance simulation results for flat routing were largely unspectacular, it would be interesting to explore a hybrid flat approach. In such a scheme a small (possible fixed) number of hierarchical naming levels would exist. The requirement that location be separate from identity would thus be relaxed a little, and so perhaps desirable properties like mobility would be possible not everywhere but within a large geographic area. This would perhaps allow better scalability and performance, making ROFL a viable candidate for deployment.

 

A Layered Naming Architecture for the Internet April 13, 2009

Filed under: Extra Papers — siva @ 12:44 pm
Tags:

The paper proposes a new naming scheme for the Internet that attempts to fix several architectural problems with today’s Internet. The paper borrows heavily from several earlier attempts at solving the problems and is a great ensemble of these earlier ideas. Today’s Internet has just two global name spaces – DNS names and IP addresses based on administrative domains and network topology respectively. Some of the challenges with today’s Internet include:

  • Hosts are closed interlinked with IP addresses which are location identifiers as well. So this affects mobility and multihoming.
  • Services and data are closely tied to hosts through the DNS resolution to IP addresses. However services might be replicated, or migrated to different hosts etc. Moreover the application is only interested in receiving the service, not on the actual end host servicing the request or the location of the end host.
  • Packets might have to be sent to intermediate nodes like NATs on their way to the actual destination. But with the current Internet, the source or the destination does not actually select these intermediate nodes for forwarding dynamically based on requirements.

The authors propose 4 design principles for naming which attempt to fix the above limitations of the Internet:

Principle 1: What to name:

Names should bind protocols only to the relevant aspects of the underlying structure; binding protocols to irrelevant details unnecessarily limits flexibility and functionality.

The authors propose a layered naming scheme for different ‘objects’ that can provide additional levels of indirection and name each ‘object’ uniquely based on just the requirements of the particular layer. They propose naming services and data directly so that they can be considered as first class Internet objects with unique names. They introduce Service identifiers (SIDs) which are host independent data names, End-point identifiers (EIDs) which are location independent host names. These are in addition to User level descriptors (which are converted into SIDs through search engines etc.) and IP addresses.

Principle 2: What should the names be:

Names, if they are to be persistent, should not impose arbitrary restrictions on the elements to which they refer.

The authors propose using flat name spaces for SIDs and EIDs since they do no impose any restrictions. They describe the use of Distributed Hash Tables (DHTs) to allow scalable resolution while using the flat nameĀ  space.

Principle 3: What should the names resolve to (Giving control to recipients):

A network entity should be able to direct resolutions of its name not only to its own location, but also to the locations or names of chosen delegates.

The authors propose that recipients or the destination should be able to direct the connection to a chosen delegate. This allows incorporation of intermediaries into the architecture.

Principle 4: What should the names resolve to (Giving control to sources):

Destinations, as specified by sources and also by the resolution of SIDs and EIDs, should be generalizable to sequences of destinations.

The authors propose that the source application can specify a series of intermediate points (like source routing). Through principles 3 and 4, both senders and receivers can indicate the path of packets through the network.

Their primary contribution include identifying several features/design principles:

  • DHTs make the use of flat name spaces plausible.
  • 4 layered naming scheme allows separation of concerns between the layers.
  • Delegation is a powerful and useful feature which should be integrated into the architecture of the Internet.

The main challenge to their proposals (indicated repeatedly in the paper as well), is that applications and host protocols would have to be changed to use the framework. The resolution of these flat name spaces requires the setup of a new trusted infrastructure of DHTs. Also, the paper does not describe any performance degradation due to introduction of additional layers or the resolution of names through the DHTs.

Future directions for research include studying the impact of using flat name spaces, and how services and data can be used as first class Internet objects. IP will likely remain as the bottom layer since it requires a lot of router infrastructure changes to replace it.