Summary: PLayer

I thought PLayer was an interesting application of the DOA/i3 concept of using indirection to decouple logical and physical paths, in an environment where it could actually be useful.  I never really bought the idea of indirection through NATs and packet filters scattered across the WAN, if only because I believed no one would trust such an infrastructure as they would a physical expression of the same logical path: people like the idea that they are literally "behind" some firewall.  But nobody likes cabling a datacenter and no one is comfortable with the idea that the security of their colo is enforced merely by the physical ordering of cables and switches.  

It's ambitious (and somewhat beyond my understanding) to try to pull this off at level 2, encapsulating ethernet frames in new frames and introducing forwarding cycles at a layer that typically isn't well-equipped to handle them.  I remember that at the RADlab retreat the PLayer presentation got some resistance from the Cisco industry reps; something about this approach breaking the spanning tree protocols.... I forget the details.

Summary: DOT

I'm not sure how I feel about this one.  Certainly the premise is valid: many applications that move bytes have to reimplement the actual byte-moving routines (this is an example of the end2end argument in practice, I suppose), so a clean architectural separation between control and data plane in such applications means not only reuse and economy of mechanism, but a decoupling of the evolutions of the two planes, which may progress at different speeds or change for different reasons.  OK.  

Separation of control and data isn't a novel idea.   Didn't FTP have a control session, and a subsequent data transfer on another port?  Second, I feel like there's an e2e argument latent in this discussion: except for the simplest protocols, most applications (take rsync) have some fairly complex end2end semantics.  Take the gcp protocol that they propose: it does not encrypt the data it sends, which would be a dealbreaker for many, if not most users of SCP.  To encrypt the data and behave more like SCP breaks the clean division of planes: now the data stream needs to flow through both loci of control and data logic.

Summary: DTN

Neat paper.  I think the most meaningful criticism I can make is that the authors are not so much proposing a new technology (certainly they are, but it's fairly simple, and is merely sketched in the paper), but making the controversial observation that in "challenged" networks, it may no longer be reasonable to expect any sort of connection-oriented protocols.  The theme of the postal service appears, in the authors' vision, on both sides of the current internet: that is to say, the internet is modeled after the postal service, and DTN is a postal-like service overlaid on the internet.  Statistical multiplexing is every bit as flexible as the postal model, but higher levels of the communication stack sacrifice this flexibility for stronger guarantees. 

I had never though about the idea of "terrestrial mobile networks."  I don't think the authors have a good solution yet for dealing with capacity issues at DTN gateways and the general logistical issues associated with "shipping": busses carrying bits are likely often full, or underutilized.  Of course, logistics is a well studied area from which we can learn lessons.  

The authors anticipate the criticism that the basic DTN idea could be well approximated by an "everything over email" approach to communication, albeit with weaker semantics.

Summary: XTrace

I have to be careful what I criticize about this paper as I know some of my classmates have worked extensively within the xtrace framework.  My initial reaction to the concept was that it was a great idea that would never work.  The attractiveness of the approach is obvious to anyone who has ever tried to debug a distributed system: without these sort of causal traces, it amounts to (when done properly) a merge-sort over a set of application and network logs, sorted by timestamp, from multiple hosts, unifying by eye the correlated events.  Format differences (imagine lining up tcpdump and apache logs) and clock skew make the inference of causation more or less impossible.  

XTrace to the rescue.  Annotating the actual datapath is in some ways a core-stateless approach that avoids a lot of the Lamportian issues of time and clocks: the lineage of next pointers creates partial orders over the logged events. This makes causal inference straightforward: follow a node along pointers to the sink.  I love the idea.  Somehow, the synchronous action of assigning the next pointers does not significantly slow down the augmented applications.

I guess I won't believe until I've instrumented an application with Xtrace that it's actually easy to do.  Are there already generic implementations of IP,TCP,DNS, and clients that make adoption a possibility?  A good trace will always begin at a client, but that's the last place that we'd expect to see any adoption.  

where is figure 8?

Summary: DOA

Walfish et al. take the i3 ideas of logical indirection and the stacking of identifiers and apply them to a specific domain: finding a way to achieve the functionality provided by NATs and packet filters in a way that is consistent with the tenets of the original internet design.  This is a very interesting discussion: I believe that the idea works but am not convinced that it is well-motivated.  Like i3, a DHT-based rendezvous architecture allows end hosts to explicitly place themselves (logically) "behind" delegates that perform middlebox functions without requiring the topology to reflect the logical structure.  By assigning each host a "true" unique identifier, firewalls and NATs can be rethought as first-class internet citizens rather than as stealth entities that violate layering boundaries or override TCP attributes like outgoing ports.

Are they making the internet architecture safer and more flexible, or are they merely finding a way to show that they've observed the tenets with which the paper begins?  I am not sure.  It is certainly the case that explicit identification could make services like SIP compatible with private address spaces without requiring  difficult, application-specific hacks.

This and the i3 paper are the first pieces we've read this semester that address the issue of security at all.

Summary: i3

It's rather obvious, but I will state nonetheless that the real beauty of i3 is its simplicity.  The idea alone is compelling, and straightforward enough to implement (not necessarily to adopt!) that a proof-of-concept is not really necessary.  It is enough to observe that the current internet conflates the notion of identity (and group membership) and address, while in the real world the two are quite separate: a single person can have multiple homes (mobility), and a single set of christmas cards tend to be sent to a large set of addresses (multicast).  A single level of indirection -- regardless of the implementation choices -- takes care of these issues, allowing rendezvous-based communication that decouples identity from location.   The idea of id stacks is a particularly powerful construct.  A form of logical source routing, it allows the arbitrary composition of services, an idea explored in more detail in the DOA paper.  

Adoption is obviously an issue for systems of this kind.  It is not enough to listen on an address to provide a service: it is now necessary to aggressively re-pin a trigger record in the DHT.  Clients can cache results of lookups, but must refresh them frequently to accommodate server mobility.

Summary: DNS Performance and the Effectiveness of Caching

Jung et al. use an analysis of real DNS traffic (and traffic causally related to DNS) to challenge some of the foundational assumptions of the DNS design: namely, that higher TTLs lead to higher cache hit rates, and that lower TTLs lead to decreased performance.  On the surface these assumptions are perfectly reasonable: higher TTLs keep entries cached for a longer time, so assuming a random temporal distribution of requests, we would expect this to result in a higher likelihood of hits.  Lower TTLs mean more frequent invalidation of cache entries, and hence more load on the servers at the top of the hierarchy: in the DNS design,  reducing load on centralized resources is perhaps a more important application of caching than reducing lookup latency.

The refutation of these assumptions would have been difficult to carry out without real traces, as the relationship between TTL and cache hit ratio is affected unexpectedly by two properties of the distribution of real requests.  First, name requests follow a heavy-tailed distribution, which means that although caching is immensely helpful for the head of the distribution, no amount of increasing resources or cache sharing will do much to reduce misses on the tail.  Second, it turns out that most traffic has such significant temporal locality that high TTLs do little to improve the cache hit ratio: a minute or two will usually do.

[no time to finish this post: this will have to do]

Summar: DNS

I think we often trivialize the DNS, partly because the basic lookup service it provides is so simple, and partly because it has been the subject of so many exploits.  Its weak, time-based consistency semantics make it difficult to reason about the system's behavior: an administrator is supposed to tune the TTL to adjust the tradeoff between stale data and performance, without any clear guidelines for which values to choose.  It is easy to ignore the fact that the DNS was deliberately designed to be a system that can accomodate massive growth while dividing responsibility and accountability evenly among the stakeholders in the namespace, and that it has been tremendously successful in meeting these goals.   The loose structure and variable hierarchy of the zone mechanism gives a level of  extensibility and "responsibility indirection" appropriate to the real internet: organizations can and should host their own name servers, but need not: high-gravity internet entities like ASs can provide this as a service to their customers.  The simplicity of the current protocol is largely the effect of usage and not design: the extensibility features of the DNS type system are mostly unused.

This paper has one my favorite quotes from a CS paper ever: 

"Distributing authority for a database does no distribute a corresponding amount of expertise.  Maintainers fix things until they work, rather than until they work well, and want to use, not understand, the systems they are provided."