Network Arcitecture (R02) Papers

This course is mainly based around reading papers and learning how to find the positive and negative (in that order) in those papers.

Here's some jolly good advice on How to read a paper by Keshav from Waterloo, plus how to write a great paper and give a great talk about it by Simon Peyton-Jones, from Microsoft.

We'll go through these topics at roughly one per week. There are also two guest slots from Andrew Moore on what router algorithms can realistically be made to do (linking to his ACS module) and by Cecilia Mascolo (on sensor nets).

One thing I'd like readers to bear in mind is that one can take an evolutionary approach to network architecture change, or one can try to be revolutionary. In discussing a given paper, try to see which approach it is taking and whether this supports or undermines the viability of the proposed idea - this notion originated with Constantine Dovrolis and Jenifer Rexford in this nice counterpoint discussion. An important evolutionary refinement is href=http://en.m.wikipedia.org/wiki/Punctuated_equilibrium>Punctuated Equilibrium: which may be how technology (including networks) evolve really.

A very interesting complex systems/systems bio/eco/evolutionary view on how layered architectures evolve is this paper on Architecture, constraints, and behavior by John C. Doyle & Marie Cseteb.

Discussion for L1 on Oct 7

This paper by Dave Clark of MIT is the startng point for all network architecture papers in form and content: The Design Philosophy of the DARPA Internet Protocols

Forwarding/Addressing & IPv6 for Oct 12th

IPv6 is what is on the table but is it too little too late?

The Simple Internet Protocol (SIP)

Paul's Internet Protocol

IETF history of IPNG for SIP, PIP and IPv6 disaster by committee

For presentation & discussion on Oct 19

To contrast with unified view of network architecture, (which reuse the form, but have very different conclusions from the Clark Internet Architecture paper above), see these two papers

Plutarch for a view of protocol plurality

Haggle to contrast with "always on" view that IP takes.