Incentive-Compatible Interdomain Routing - PowerPoint PPT Presentation

About This Presentation
Title:

Incentive-Compatible Interdomain Routing

Description:

Currently done with the Border Gateway Protocol ... Is there a realistic and useful class of routing policies ... Incentive-Compatible Inter-Domain Routing Author: – PowerPoint PPT presentation

Number of Views:56
Avg rating:3.0/5.0
Slides: 25
Provided by: Vijay81
Category:

less

Transcript and Presenter's Notes

Title: Incentive-Compatible Interdomain Routing


1
Incentive-CompatibleInterdomain Routing
Joan FeigenbaumYale UniversityVijay
RamachandranStevens Institute of
TechnologyMichael SchapiraThe Hebrew University
2
Interdomain Routing
  • Establish routes between autonomous systems
    (ASes).
  • Currently done with the Border Gateway Protocol
    (BGP).

3
Why is Interdomain Routing Hard?
  • Route choices are based on local policies.
  • Autonomy Policies are uncoordinated.
  • Expressiveness Policies are complex.

Always chooseshortest paths.
Load-balance myoutgoing traffic.
Verizon
ATT
Comcast
Qwest
Avoid routes through ATT ifat all possible.
My link to UUNET is forbackup purposes only.
4
Welfare-Maximizing Routing
Private informationRoute valuations
Strategies
Mechanism
a1
v1(.)
p1
AS 1
RoutesR1,,Rn
an
vn(.)
pn
AS n
  • For each destination (independently / in
    parallel), compute
  • A confluent routing tree that maximizes the sum
    of nodes valuations for that destination,
    i.e., ?i vi(Ri) and
  • VCG payments (nodes are paid for their
    contribution to the routing tree)
  • using a BGP-compatible (distributed) algorithm.

5
VCG Payments
Td is the optimal routing tree to destination
d. Td-k is the optimal tree to d if node k is
removed.
  • The VCG payment to node k is of the form
  • pk ?i ? k vi(Td) hk()
  • where hk is a function that does not depend on
    ks valuation.
  • If hk(vi) ?i ? k vi(Td-k),
  • then the payment to each node is
  • pk(Td) ?i ? k vi(Td) vi(Td-k).

6
Payment Components
  • The total payment to node k can be broken down
    into payment components pk(Td) ?i ? k
    pki(Td).
  • Each payment component depends only on the
    valuations at some node i pki(Td) vi(Td)
    vi(Td-k).
  • Compute these in a distributed manner.
  • Problem We dont want to run an algorithm for
    every Td-k (not efficient).

7
Routing-Protocol Desiderata
  • Does not assume a priori knowledge of the network
    topology
  • Distributed
  • Autonomy-preserving
  • Dynamic (responds to network changes)
  • Space- and communication-efficient
  • Complies with Internet next-hop forwarding

8
BGP Route Processing
  • The computation of a single node repeats the
    following

ChooseBestRoute
UpdateRouting Table
Receive routes from neighbors
Send updatesto neighbors
  • Paths go through neighbors choices, which
    enforces consistency.
  • Decisions are made locally, which preserves
    autonomy.
  • Uncoordinated policies can induce protocol
    oscillations. (Much recent work addresses BGP
    convergence.)
  • Recently, private information, optimization,
    and incentive-compatibility have also been
    studied.

9
Known Results Welfare Maximizationand
Interdomain Routing
Routing-Policy Class Good CentralizedAlgorithm? Good DistributedAlgorithm?
LCP ? ?
General Policy ?(and hard to approximate) ?(and hard to approximate)
Next Hop ? ?
Subjective Cost ?(incl. some special cases) ?(approx. is easy if gt1 tree)
Forbidden Set ? ?
10
Question
  • These are mostly negative results.
  • Is there a realistic and useful class of routing
    policies (i.e., something broaderthan LCPs) for
    which we can get anincentive-compatible,
    BGP-compatible algorithm to compute routes and
    payments?

11
Gao-Rexford Framework (1)
  • Neighboring pairs of ASes have one of
  • a customer-provider relationship(One node is
    purchasing connectivity fromthe other node.)
  • a peering relationship(Nodes have offered to
    carry each otherstransit traffic, often to
    shortcut a longer route.)

peer
providers
peer
customers
12
Gao-Rexford Framework (2)
  • Global constraint no customer-provider cycles
  • Local preference and scoping constraints, which
    are consistent with Internet economics
  • Gao-Rexford conditions gt BGP always converges
    GR01

Preference Constraints
Scoping Constraints
. . . .
R1
j
k1
provider
. . . . . .
. . . .
d
. . . .
i
peer
d
i
R2
. . . . . .
m
k2
k
customer
  • If k1 and k2 are both customers, peers, or
    providers of i, then either ik1R1 or ik2R2 can
    be more valued at i.
  • If one is a customer, prefer the route through
    it. If not, prefer the peer route.
  • Export customer routes to all neighbors and
    export all routes to customers.
  • Export peer and provider routes to all
    customers only.

13
Efficient Payment Computation
  • Next-hop valuations The valuation of a route
    depends only on its next hop.
  • Theorem If Gao-Rexford conditions hold and ASes
    have next-hop policies, then routes and payments
    can be computed with good space efficiency.
  • (We only run BGP once.)

14
Next-Hop Payment Computation
  • Send augmented BGP update message whenever best
    route or availability of ak-avoiding route
    changes
  • When an update message is received
  • Store path and bits in routing table.
  • Scan bits to update best k-avoiding next hop.

AS k1 AS k2 AS ki
Y/N Y/N Y/N
AS Path
ki-avoiding path known?
15
Next-Hop Routing Table
  • Store usable routes, availability of k-avoiding
    routes from neighbors (for all stored routes),
    and best k-avoiding next hops (for current most
    preferred route).
  • Payment components are derived from next hops
    pki(Td) vi(Td) vi(Td-k) for transit k
    0 otherwise.

AS 1
AS 2
AS 2
Best k-avoiding next hops
Destination
AS 4
AS 5
Optimal AS path
AS 2
d
Y
Y
Bit vector from update
AS 1
AS 3
AS 5
Alternate AS path
d
Y
Y
Bit vector from update
16
Towards a General Theory
  • Gao-Rexford Next-Hop valuations are a special
    case.
  • We identify a broad sufficient condition for
    valuations that permit BGP-compatible,
    incentive-compatible computation of routes and
    VCG payments.

17
Dispute Cycles
Relation 1 Subpath
Relation 2 Preference
R1
Q1
vi(Q1) gt vi(Q2)
. . .
. . .
d
i
i
d
. . .
R2
Q2
R1 R2
Q1 Q2
  • Valuations do not induce a dispute cycle iff
    there is no cycle formed by the above relations
    on all permitted paths in the network.
  • No dispute cycle gt robust BGP convergence
    GSW02, GJR03

18
Example of a Dispute Cycle
v(12d) 10 v(1d) 5
v(23d) 10 v(2d) 5
1
2
1d
2d
3d
d
31d
12d
23d
3
v(31d) 10 v(3d) 5
Dispute Cycle
Subpath Preference
19
Policy Consistency
Valuations are policy consistentiff, for all
routes R1 and R2(whose extensions arenot
rejected),
R1
. . . .
k
i
d
. . .
THEN vi((i,k)R1) gt vi((i,k)R2)
R2
IF vk(R1) gt vk(R2)
(analogous toisotonicity Sob.03)
20
Optimality
  • Theorem If the valuation functions are policy
    consistent and do not induce a dispute cycle,
    then BGP converges to theglobally optimal
    routing tree.

21
Efficiently Computing Payments
  • Local optimality In a globally optimal routing
    tree, every node gets its most valued route.
  • Theorem A No dispute cycle policy consistency
    gt local optimality.
  • Theorem B Local optimality gt If k is not on
    the path from i to d, then payment component pki
    (Td) 0.

22
Conclusions
  • Gao-Rexford Next-Hop valuations are a
    reasonable class of policies that admit
    incentive-compatible, BGP-compatible computation
    of routes and VCG payments.
  • Only a constant-factor increase in BGP
    routing-table size is required.
  • Dispute-cycle-free and policy-consistent
    valuations generalize this result.

23
Future Work
  • Approximability of the interdomain-routing
    problem?
  • Without restrictions on policies, no good
    approximation ratio is achievable FSS04.
  • Remove bank?
  • Optimal communication complexity?

24
Technical Report
  • Full version of this paper is available asYale
    University Technical ReportYALEU/DCS/TR-1342
  • http//www.cs.yale.edu/publications/techreports/
    tr1342.pdf
Write a Comment
User Comments (0)
About PowerShow.com