Paper Link
Research Question: What are the challenges to “evolving” (incrementally deploying improvements to) internet routing protocol(s) like BGP, and how can those challenges be overcome?
(Meta-Question: What lessons can be learned by taking this paper as an exemplar of a well-stated intro/background/motivation?)
Key Contributions:
- Provide a well-motivated and reasoned statement of the requirements on any possible solution to the problem of inter-domain routing evolvability
- Distill these requirements into a minimal feature set
- Present Darwin’s BGP (D-BGP), a protocol that builds on BGP and embodies these features
- Evaluation of D-BGP:
- cheapness of implementation
- simulation showing better adoption rate for D-BGP
This paper states the following problems with BGP (reasons why you’d want to evolve):
- Domains have no strong mechanism to limit their traffic load
- Single best-effort path selection is mandated, leaving performance on the table (alternates might be preferred by some domaisn)
- Easy to attack:
- Prefix hijacking
- Traffic interception (black-holing, interdiction)
- “Architectural Rigidity”
- Neighbors are required to use the same protocol, which precludes the possibility of some defecting by choosing a different/better protocol
- (Bug or Feature?) “[BGP] has depressed ISP’s ability to sell value-added services, such as differentiated QoS or alternate paths, to combat their ever-increasing commoditization.” Commentary: Isn’t this just net-neutrality? Whic is a “good thing?” Is commoditization (i.e., competition-driven downward price pressure) good for consumers, if not producers?
Key Insight: Solving any or even all of these problems with a new protocol, without addressing the root causes of lack-of-evolvability, will simply result in a new protocol that frustrates future efforts to evolve/improve. I.e., Evolvability is actually the meta-feature to improve!
Motivtion (2) structure:
- Narrative describing the structure of the present/future state
- Introduces terminology: Islands, Gulfs, Mulit-Network-Protocol-Headers, Baseline Protocol, Routing Compliance (gets its own section?)
- States the basis for generalization:
- 14 (!) recently-proposed protocol improvements designed to mitigate specific problems
- These will be sorted into “evolvability scenarios”
- Each evolvability scenario produces a few requirements
- The requirements are further affinitized into features
- “use cases” -> generalized scenarios -> requirements -> features
- specificity -> generality -> specificity -> generality
- The scenarios:
- baseline -> baseline w./critical fix
Requires:
- (CF-R1) Disseminate critical fixes’ control information across gulfs
- (CF-R2) Disseminate critical fixes’ control information in-band of baseline’s advertisements
- baseline -> baseline (in parallel with) custom protocol
Requires:
- (CP-R3) Facilitate across-gulf discovery of islands running custom protocols and how to negotiate use of their services
- baseline -> replacement protocol
Requires:
- (G-R4) Inform islands and gulf ASes of what protocols are used on routing paths
- (G-R5) Avoid loops across all protocols used on routing paths
- The features:
- Pass-through support: (CF-R1)
- Multi-protocol data structure: (G-R4, CP-R3, CF-R2, G-R5)
Questions for Discussion:
- How might the addition of new use cases (14+n) change the scenarios, requirements, and features?
- How universal is the 4-step progression followed in this paper’s motivation? How might it apply to a problem you’re working on?
Presenter: Tony Astolfi