The Teacher

Courses

Strategic Choices in Designing the Internet

Notes for planning the course

These are notes that I'm writing while planning the course. Not all of the ideas in these notes will appear in the course. Everything will be reorganized and rewritten.

Design Principles

1. End-to-end principle.
   
   
2. Design infrastructure bottom-up; design applications top-down.
   
   
3. To maximize total value of a resource (with sufficient demand), emphasize throughput.
   
   
4. Distinguish inherent costs from avoidable costs, and only work on the latter. (E.g., tolerate dropped packets due to exceeding capacity; avoid letting congestion decrease capacity.)
   
   
5. For flexibility, provide clean simple modules instead of large bundles of functions. Particularly avoid bundling a cheap service with a much more expensive service. Particularly avoid bundling functions that can change independently, e.g. data manipulation with user interface.
   
   
6. For performance, improving the best case and reducing the occurrence of the worst case are often better than improving the worst case. Particularly avoid improving an unusual worst case at the cost of degrading a common best case. In distributed design, this principle is even stronger due to positive feedback through other parts of the design. A common application of this principle is optimistic processing with detection of failure and recovery.
   
   
7. In distributed systems, match authority to incentive as much as possible.
   
   
8. In large, adaptive, collaborative design, the order of introducing constraints is crucial. Start with the minimal constraints that allow for effective adaptation and collaboration in the future. Avoid constraining decisions whose consequences are not known, or which depend on conditions that are likely to change.
   
   
9. In a distributed system of information, reliable information must always be communicated positively by a detectible event. The absence of an event may always be due to a local failure.
   
   
10. When choosing between a more general less efficient service A, and a less general more efficient service B, try to choose both: provide the functionality of A, with optimizations that use the form of B when possible. E.g., tail recursion may compile as iteration (need a network example).
    
    

Conceptual cautions

1. The distinction between "reliable" and "unreliable" is usually misleading. Every system has a statistical profile of failure. The granularity of failure is just as important as the probability of failure.
   
   
2. Reliability at one level often means tolerating failure at another level.
   
   
3. A change to one quality of a component often changes a totally different quality of the system. E.g., improving the security of a link may improve performance, but not security, of an encrypted communication path. Most link qualities are seen as performance by paths using that link.
   
   
4. Dramatic reduction in the cost of a service often enables new and surprising uses for the service (this is an example of feedback in distributed design). The most important uses of a service are usually the ones that haven't been invented yet.
   
   
5. Relaxing one constraint often causes a different constraint to be the limiting factor.
   
   
6. In computing/communications, expect everything to virtualize.
   
   
7. Lots of analysis determines and/or optimizes steady-state behavior of a system. Many computing/communication systems never reach steady-state, and the dynamic transient behavior is the only important one. One of the most important drivers of transient behavior is the rapid change in electronic/optical technology.
   
   

Perspectives

1. Internet as bit-delivery service.
   
   
2. Internet as support for applications.
   
   
3. Internet as a social medium.
   
   
4. Scalability/adaptability to new demands.
   
   
5. Co-ordination of distributed authority.
   
   
6. Virtualization, phenomenological evolution (e.g., definitions of host, address).
   
   

Layers of design

• Addressing (IP, UDP)
  
  
  • Delivery/forwarding (IP)
    
    
    • Address management (DHCP)
      
      
    • Routing (ARP, ICMP, RIP, OSPF, CIDR, IGP, BGP)
      
      
    • Capacity management (TCP)
      
      
  • Naming, relocation (DNS)
    
    

Desirable robustness

1. scaling to more hosts
   
   
2. relocatable sender
   
   
3. relocatable receiver
   
   

Design choices

1. forwarding: datagram (stateless router) vs. connection (stateful router)
   
   
2. switching: stateless packet vs. state in packet (NAT)
   
   
3. reliability: end-to-end vs. link-by-link
   
   
4. addressing: global vs. routed
   
   
5. service level: best-effort vs. reserved; egalitarian vs. differentiated
   
   
6. congestion control: end-to-end vs. intermediate
   
   

Categories for criticizing decisions

Strategic decisions taken in designing something as complex and distributed as the global Internet cannot be determined clearly to be correct or incorrect. Here are some interesting types of evaluations of design decisions. We may evaluate a single decision in more than one way.

• Successful in producing a particular desired result. E.g., the decision to forward packets in a manner that does not require global knowledge at any single host was successful in allowing the Internet to scale.
  
  
• Unsuccessful in producing a particular desired result.
  
  
• Accidentally productive of an undesired result.
  
  
• Adherent to good design principles.
  
  
• In violation of good design principles.
  
  
• Irrelevant with respect to a particular result.
  
  
• Not really a decision, since it did not constrain further decisions. E.g., the decision that each IP number is the address of a particular network interface on a particular host is violated by NAT and other local variations, and overall network operations cannot detect it.
  
  

Miscellaneous ideas

Here are some ideas that I don't want to forget, but I'm not sure where they fit.

• If B can be implemented easily from A, but not vice versa, prefer A in the infrastructure.
  
  
• If B requires A, but not vice versa, prefer A in the infrastructure. E.g, setup for virtual circuits and source routing require datagram service, so implement datagrams first.
  
  
• "Scalability" really means that it is easy to co-ordinate the bundle of resources that must be added to achieve an incremental expansion. So, all of those resources should be bundled into the smallest possible number of packages, and as many as possible should be deployable locally (in the administrative sense, not always the geographical sense).
  
  
• Design bottlenecks (mandatory protocols, not network bottlenecks) have a dual nature: they restrict the interaction between different parts of a design, while they allow greater flexibility in the operations on either side of the protocol.
  
  
• Reassignable resources, such as processor time and storage space resources are not wasted by one action unless another action is disrupted. So conservation is only valuable when a resource is close to its limit. The economics of reassignable resources is totally different from that of permanently consumed resources, such as energy. Alternative view: each time slice of processing and storage is an individual instantly perishable resource---if not used at that instant, it is lost.
  
  

  Types of Resources

  	Durable	Intermediate	Perishable
  Reusable	computation, storage		-
  Consumed	energy		computation, storage

  
  
  Strangely, durable-reusable and perishable-consumed are the same thing, viewed from different perspectives.
  
  

Time scales

• transit (one packet crosses the network)
• route integrity (a route changes)
• address integrity (an address changes)

Course outline

1. Introduction
   
   
   1. Understand Internet design as a logical (vs. historical) sequence of choices.
      
      
   2. Order choices by scope of agreement: the set of agents who must abide by a choice for it to work.
      
      
2. Addressing
   
   
   1. Global vs. routed
      
      
   2. Flat vs. aggregated
      
      
3. Forwarding
   
   
   1. Path state in router?
      
      
   2. Path state in packet?
      
      
4. Intermediate acknowledgment?
   
   
5. Traffic control
   
   
   1. Congestion control: end-to-end vs. router control
      
      
   2. Service level: best-effort vs. reservation
      
      
6. Handles (agent identifiers)
   
   
7. Authentication and identification: hierarchical/authoritarian vs. flat/phenomenological
   
   

Missing information

1. What does "best effort" really mean, as a positive requirement? Is it purely psychosocial, or is there a meaningful technical definition?
   
   

Copyright Michael J. O'Donnell <michael_odonnell@acm.org>. Licensed for free use.
This page is generated from PHP source code, with supporting files.