Advanced Computer Networks

1
Advanced Computer Networks

• Protocol Design Folklore
• Lan Wang
• lanwang_at_memphis.edu
• http//www.cs.memphis.edu/lanwang

2
1. Simplicity

• Making the simple complicated is commonplace
  making the complicated simple, awesomely simple,
  thats creativity.
• --- Charles Mingus
• Why make a network protocol simple?
• Easier to implement
• More likely to deploy
• What are protocols so complicated? Many reasons.

3
Things that complicate a protocol

• Design by committee
• Necessary evil due to the need for
  standardization, but
• Every committee member wants to put in his idea
  and they have different interests
• If theres no consensus, put in all options
• Flexibility fit every possible situation
• Exotic features from creative minds of
  researchers who are eager for difficult problems
• Backward compatibility
• Optimality

4
2. Knowing the problem youre trying to solve

• Argument before we design a solution, its often
  useful to define the problem to be solved.
• Counterargument if we design without
  preconception of the problems, there might be
  unexpected applications.
• Have at least one well-defined problem in mind,
  perhaps designing the system so that other
  variants can be supported without making the
  solution too complicated (How?)

5
3. Overhead and Scaling

• We should calculate the overhead of the
  algorithm.
• Make reasonable bounds on the limits.
• Publish them in the specification.
• Sometimes theres no reason to scale beyond a
  certain point.
• E.g. if a network would never have more than 5
  nodes
• Be sure to scale to the low end as well.

6
4. Operation above capacity

• When a protocol is operating above its limit, the
  protocol should be designed to gracefully
  degrade
• Or it should detect that the operating condition
  (e.g. size of the topology) is now illegal and
  complain.
• Example IS-IS has explicit procedures to follow
  in the case of database overload.

7
5. Optimize for the most common or important case

• Example 1 Huffman encoding
• Shorter codes are used to encode more frequently
  occurring symbols.
• Example 2 fast path processing
• A common IP packet (no options) is switched in
  hardware, and others are sent to the central
  processor
• Example 3 encode unusual requests as an option

8
6. Forward compatibility

• Large enough fields
• Independence of layers
• Do not make too many assumptions about the layer
  below.
• Reserved fields
• Version-number field
• Options
• Use a TLV format
• specify what a node should do in the type field

9
7. Migration Routing Algorithms

• How to run two routing protocols at the same
  time?
• use a router that speaks both routing algorithms
• Or treat the network as two separate networks
• How to migrate from one protocol to another?
• Run both at the same time and gradually turn off
  one
• Eg ARPANET
• 1. Distance vector
• 2. DVLS, but route based on DV database
• 3. DVLS, but route based on LS database
• 4. Link state only

10
8. Parameters

• Why do parameters exist?
• Protocol designers cannot figure out reasonable
  values, so they leave it to the user.
• After gaining deployment experience, make the
  parameters constants in later versions of the
  protocol.
• There are reasonable trade-offs and it is
  desirable to allow the user to tune the network.
• The parameter description should explain the
  range and the reason for choosing points in the
  range.

11
Parameters (contd)

• Avoid parameters whenever possible
• Sometimes its possible to pick a value and let
  everyone live with it.
• In other cases the parameter can be figured out
  by the computer.
• Addresses DHCP
• Link costs, etc.
• Legal parameter setting
• Report my values method
• Detect misconfiguration method
• Use my parameters method

12
9. Making multiprotocol operation possible

• Protocol type at layer n-1
• Ethernet different protocol types for IP and ARP
• IP different protocol types for UDP and TCP
• Socket or port at layer n-1
• UDP, TCP port numbers to identify different
  applications
• Protocol type at layer n
• ISO layer 3 protocols share the same layer 2
  protocol type, but have different NLPID to
  distinguish between CLNP, ES-IS, IS-IS, etc.
• Different version number field IPv4, IPv6

13
10. Running over layer 3 vs. layer 2

• Some protocols that work only neighbor-to-neighbor
  are encapsulated in a layer 3 header, e.g. many
  routing protocols run over IP
• Unnecessary to carry the IP header because the
  packets are not forwarded by IP
• But various practical reasons
• API available for running over layer 3, but not
  for layer 2.
• Difficult to obtain a layer 2 protocol type.
• Some layer 3 protocols, e.g. IP, do fragmentation
  so you dont have to.

14
11. Robustness

• Simple robustness node and link failures
• Self-stabilization operation may become
  disrupted, but when the malfunctioning node is
  removed, the network should return to normal
  operation.
• Byzantine robustness the network can continue to
  work properly even in the face of malfunctioning
  nodes.

15
How to make a system robust?

• Every line of code should be exercised
  frequently
• Sometimes its better to crash rather than
  gradually degrade so the problems can be fixed or
  at least diagnosed
• Contain problems
• Certain checksums detect certain error conditions
  better than others
• Every packet should be processed at wire speed

16
12. Determinism vs. Stability

• Determinism the behavior at this point does not
  depend on past events
• Stability minimize the changes
• Example Designated Router (DR) selection
• IS-IS the router with the highest priority will
  be the DR (deterministic)
• OSPF after a node is elected DR it remains DR
  unless it crashes (stable)

17
Assignments

• Reading
• Chap. 18 of Perlman (protocol design folklore)
• Project Presentation Apr. 21 and Apr. 26
• Project Demo Apr. 28
• Final Report May 3