Talk:Sigcomm 2012

In preparation for SIGCOMM 2012, and general directions on broader architectures.

The current content is taken from the group's emails on the topics. Please feel free to change the content or structure. Each revision is logged.

To edit, click the edit button on the top. You can check the instructions for formatting. For most editing tasks, you can simply look at the already formatted text.

Sigcomm Structure

• [John] For Sigcomm we need to focus on layered and networked architecture, but to sharpen what we mean by that it would be helpful to have clear examples of "not layered" and "not networked" that are nevertheless effective architectures. In my PNAS paper I think I made "layered" deliberately too flexible a notion so that it described both garment/fiber and outfit/garment, which I claimed were very different.
  • [Dirk] I understand the 'not layered' aspect but don't get the 'not networked' aspect for a distributed system debate. For 'not layered', work like Haggle here in Cambridge could be interesting. Efficient though? That was the claim but there's little/no evidence.

• [John] For Sloman, the layering of VM apps on a VM platform (e.g. Apps on OS) are also very distinct from the layering of VM on PM (software on/in hardware), and I think this is a huge and important distinction, and I'm still not explaining it well. We so completely understand it that we don't seem to describe it sensibly.
  • [Dirk] Isn't that the very notion of layering itself with different abstractions along these layers while still all following a same 'thread' (it's seems to be something around information in Sloman's thinking, see also the mentioned slide 49 in set 2). To me, VM app -> VM platform -> PM is the particular instantiation in Sloman's architecture.

• [John] (I want to also make an aside that I need to distinguish between foreground reading, what we will directly build on for a Sigcomm paper and can assume reviewers and readers have also read, and Background reading, things that help is find examples and perspectives but we can't use too much because they are unfamiliar. Right now, Davrolis is #1 foreground, with the various Shenker papers. Everything else is background...)

• [John] One issue I'm struggling with is describing the nature of the new "high waist" that separates a VM associated with content (whose subarchitecture is discussed in terms of OS and programming languages) versus a VM associated with resources (OR and control theory) that hides and manages the PM that all run on. It seems that this layering is actually more akin to VM on PM, than VM apps on VM OS. What could I possibly mean? I think Sloman could help with that, but right now I'm not sure how to make any of that clear.
  • [Dirk] See above - I don't think that layering is more akin to VM on PM - it's all layering at different levels of abstractions (which is what layering is all about, isn't it?). See also through some of the more recent cartoons I had added to the overall cartoon slides.

• [John] There is a tension between wanting to be recursive (a la Day) and downplay the VM vs PM distinction, and emphasizing the profound discontinuity that happens at the VM/PM interface, wherever it may occur (mind/brain, digital/analog, active/passive, etc)...
  • [Dirk] Is there a discontinuity? I don't see Sloman implying this. I would argue that he's trying to find the conceptual framework that overcomes the 'seemingly existing' discontinuity. And I would argue that WE are trying to do the same?!

• [John] If I haven't confused things enough already, another person who does stuff I like and has a completely different point of view (Walter has met her), is Carliss Y. Baldwin. The first set of slides on

http://drfd.hbs.edu/fit/public/facultyInfo.do?facInfo=ovr&facId=6417

are just perfect. The Apple vs Android battle now playing out is a great case study only too current for us to use effectively. As Wu emphasizes, it is policy ( courts, markets, etc) that will determine the outcome more than tech.

• • [Dirk] Absolutely, which is why it is important to think about optimization decomposition as much as thinking about tussle spaces (I used the word 'satisficing' in related work in the design for tussle space). Not all is an optimization problem per se but often a weighing off interests with court procedures implementing this process of 'weighing off'. In a system like the Internet, you cannot prevent going into the policy space. The current sigcomm outline has, therefore, allusions to the optimization work as much as to the design for tussle work!

• [John] Our best example of grotesquely bad architecture will almost surely stay medicine up until the mid 1800s, but I'm getting better ideas on how to distill what a "bad architecture" is, and it would help to line up more simple accessible examples so we can maybe show what patterns are. IP is still the essential example, but it is new and a mix of good and bad, so it will help to show more range of pure bad to "pure good"??? (I think the most perfect architecture is the bacterial biosphere, not very helpful for Sigommm, but makes it a priority to explain. The VM vs PM story is great there, so I'm eager to drop everything and write a clear paper on this architecture, but I'll resist...)
  • [Dirk] One thing after another ;-) A 'purely' architectural paper would be lovely - this is unlikely to go anywhere in the nets community. But PNAS could be a good target for that. I believe that our specific SIGCOMM discussions though help for that bigger exercise.

Current Literature

The Evolution of Layered Protocol Stacks Leads to an Hourglass-Shaped Architecture

• [John] It would be helpful it seems to propose an opposite extreme, a minimal model that is all about function and purposeful design, as a contrast.
• [Dirk] It just needs a focus on what matters in a successful architecture: the ability to construct something against some metric of optimum. His paper doesn't give that. It simply says that every house finally converges to four walls with a roof, despite a wide range of inefficiencies in, e.g., insulation.

Architecting for Innovation

• [Dirk] Response to page 26 "Modularity is a basic tenet of system design... architectural modularity requires more than layering: it requires that interfaces be both extensible and abstract. By “extensible” we mean that new functionality can be added to a particular component, and utilized by other components that are aware of this change, without rendering unmodified components obsolete... For instance, interfaces should not pass network addresses or particular byte layouts, but instead should pass names and structured data"

This does point to extensibility but it does not bring home the point fully (and might even carry a dangerous side point): extensibility is important (we're saying the same) but it seems to imply that this should be done through extensible interfaces (option fields, schemed data instead of bytes/bit?) rather than extensible layering. The latter would be our message, wouldn't it? Now, the authors might have this in mind but focus in their paper on what they call the 'network API', so it seems to be all focussed on that. An architectural layering message extends this to an approach of layering/modularizing that is not limited to the 'network API'.

On the positive side, this is something to build upon since WE can bring this point home. It's a direct conclusion from the tussle paper, i.e., modularity matters and this modularity matters at design time, calling for an architectural approach that provides such modularity (here, modularity is a more general form of layering).

Information-Centric Networking: Seeing the Forest for the Trees

• [Dirk] The paper makes a very valid point about caching, something we've said in the PURSUIT project all along: caching through 'storing interest and data requests' is unlikely to be efficient nor sufficient. There is a role for managed caching, while this type of lateral caching is likely to be similarly ineffective as web proxying. That's why we've developed managed caching solutions in PURSUIT (ad were critiqued for it).

• [Dirk] The paper underestimates the challenge in naming. Pointing to their own work, published in the SIGCOMM ICN workshop, they lay to rest the naming discussion, which I believe is utterly wrong. Their workshop contribution (on the separation of real world identities as long-lived identities and shorter lived labels) is only the start of the necessary discussion. If you want to get a hint on the extent of the discussion, you can ask Karen Sollins ;-)

Naming in Content-Oriented Architectures

• Source: http://conferences.sigcomm.org/sigcomm/2011/papers/icn/p1.pdf

Sigcomm Paper Components

and other food for thought...

Examples of Bad Waists

• [John] there are some interest "fish parts" example, one of the most infamous is the giraffe neck and some nerves in it that used to be straight in fish but ended up in a tortured curve in the giraffe:

http://14-billion-years-later.tumblr.com/post/2962924626/the-evidence-for-evolution

• [John] Burning fossil fuels is one. Settling conflicts by warfare is another fundamental one. Monotheism. QWERTY. Irregular verbs... IP is not a particularly bad example. Windows is maybe better?
  • [Dirk] In any sigcomm exercise, it's not only political interesting (necessary?) to point out IP. Many things are right there but, in a subtle way, pointing out the things that (architecturally) have led to problems is important and can provide a way forward. The CCR attempt had many points already that we can built on.

Virtual Machinery (re: Sloman)

See email for source

• [Dirk] The most concrete point is the 'problem-specific' execution in running VMs (see e.g., slide 25 in set 2). And he emphasizes the role of information. The features of machines in Slide 11 (set 2) are good aspects to think about, in particular when he sees the boundary between machine and environment blur, something current systems are very bad at still. But some of his examples, such as memory management, are still too much immersed into today's system (this is where I find Kay's work more interesting since it embeds what Sloman calls NPDs more visibly into the physical structures through the associations being built. He does see memory management as context-dependent but does not seem to elaborate on the complexity of this context beyond remapping continuos memory blocks).

• [Dirk] Another clear and interesting aspect is the runtime execution, something that's very underspecified so far in distributed systems (it's done but without great understanding from the design perspective). We tried to highlight this in the SIGCOMM submission but it's hard to explain and conceptualize well.

• [Dirk] But his remaining hard problems on slide 39 (in set 1) give us the mandate really: role of information and how 'intelligent design' in evolution really looks like. It's a great motivation but it's not yet there for our consolidated view, I feel.

• [Dirk] Slide 49 in set 2 is the closest to our concepts, I believe: it emphasizes the role of information, it introduces mediation (not specifically but still), it highlights the core functions of manipulation (internal and throughout a distributed system) and it highlights that the structural properties of the information is important (I translate this that you will need an approach that can accommodate a variety of app-specific ontologies). All of this coming together in an architecture/design!! Now THAT is what the current exercise is roughly about, isn't it? And these are roughly the concepts that are highlighted in Section 5 of the current draft.

• [Dirk] At least two problems here:
  • We won't have the space to elaborate in such lengthy way how we get to our concepts. The current shortcut is that of IP as a case study. We had/could have a section on other case studies - here is where we could segway Sloman into the picture. But there's always the avenue of other venues with a more bio/human spin, for instance. Not all will/need to fit into a single (SIGCOMM?) submission.

• • Digesting Sloman is inherently difficult and my experience with the Sigcomm audience is not the best one when it comes to (i) understanding Sloman and (ii) wanting to understand Sloman. So there's a danger to loose the audience if Sloman's direction is presented too prominently (maybe not the best example but the basis for my experience was our Sigcomm submission which featured Sloman really prominently albeit likely inadequately presented - it didn't go well).

• [Dirk] P.S.: one sentence I like particularly is "...that discovering what is possible, is a more fundamental function of science than discovering laws and correlations." on slide 15 ;-)

• [John] For Sloman, the layering of VM apps on a VM platform (e.g. Apps on OS) are also very distinct from the layering of VM on PM (software on/in hardware), and I think this is a huge and important distinction, and I'm still not explaining it well. We so completely understand it that we don't seem to describe it sensibly.
  • [Dirk] He's very helpful for the much wider debate. There could still be a place for a discussion outside comms that could shine at important insights for the SIGCOMM exercise, i.e., a small section on insights from Sloman - but one needs to see how it reads in the end.