note di questa e della lezione precedente

Strumenti della Teoria dei Giochi per l’Informatica
A.A. 2009/10
Lecture 6–7: 25-26 Marzo 2010
Protocollo BGP e Teoria dei Giochi
Docente Paolo Penna
Note redatte da: Filomena Carnevale
Sommario
In questa lezione forniremo una breve introduzione al problema dell’Interdomain Routing
e al protocollo BGP (Border Gateway Protocol). Utilizzando strumenti della teoria dei
giochi (ad esempio equilibri Nash) tenteremo di spiegare il “successo” di tale protocollo su
Internet: (1) perchè il protocollo “funziona” (converge ad uno stato stabile) e (2) perchè
le varie componenti di Internet (Sistemi Autonomi) continuano ad implementarlo (se un
Sistema Autonomo decide di non seguire il protocollo non ne trae alcun vantaggio).
1
Introduzione
Internet è composta da reti di piccole dimensioni dette Sistemi Autonomi (AS). Tali AS sono di
proprietà di soggetti economici, spesso competitivi (come Microsoft, AT&T, etc.). L’interdomain
routing ha il compito di stabilire le rotte tra tali AS. Poiché non tutti gli AS sono direttamente
connessi, i pacchetti spesso devono attraversare diversi AS. Il routing dei pacchetti viene stabilito
attraverso complesse interazioni tra gli AS, che permettono loro di esprimere preferenze sulle
rotte, e sono influenzati dalla natura della rete (ritardo dei pacchetti, malfunzionamenti, etc.). Il
protocollo utilizzato in Internet per l’interdomain routing è il Border Gateway Protocol (BGP).
In questa lezione vedremo l’interdomain routing come un gioco in cui i giocatori sono gli AS e le
loro strategie consistono (essenzialmente) nello scegliere se utilizzare BGP oppure una qualunque
variante del protocollo se questo risulta vantaggioso. Il gioco che vedremo cattura le complesse
relazioni tra gli AS e altri aspetti del problema, come la natura asincrona della rete. La rete
viene modellata come un grafo non diretto G = (N, L), dove l’insieme dei nodi, N , rappresenta
gli AS e consiste di n nodi più un nodo destinazione, d (i vari AS devono decidere che rotta
seguire per inviare i pacchetti a d), e l’insieme degli archi L rappresenta i link fisici tra gli AS
(esiste un link se due computer dei due AS sono collegati fisicamente e quindi possono scambiarsi
i pacchetti). Ciascun nodo ha una propria politica di routing che consiste di due componenti:
una funzione di valutazione, vi , che assegna, ad ogni possibile rotta da i a d un valore non
negativo, e una politica di esportazione, che determina i percorsi che il nodo i è disposto a
mettere a disposizione di ciascun nodo vicino. Assumiamo che i nodi abbiano preferenze strette,
ossia date due rotte Q ed R, vi (R) < vi (Q), oppure vi (Q) < vi (R). Inoltre, indichiamo con
il simbolo ∅ un qualunque cammino non-valido (ossia un insieme di archi che non porta alla
destinazione d, come ad esempio il cammino vuoto). Ogni nodo assegna una valutazione 0 (il
minimo possibile) ad un cammino non-valido (vi (∅) = 0 per ogni nodo i). Se il nodo i non mette
a disposizione del nodo j la rotta R, allora j valuta questa rotta come se si trattasse della rotta
vuota.
1
2
2
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
Gioco One-Round
Cominciamo a vedere una versione semplificata del problema in cui ogni nodo sceglie un arco
tra quelli che connettono lui ad uno dei suoi vicini nel grafo G = (N, L). Intuitivamente, il nodo
i può (solo) decidere il primo arco nel cammino verso la destinazione d (gli altri archi sono decisi
dagli altri nodi).
12d
1d
..
.
∅
1
2
21d
2d
..
.
∅
d
Figura 1: Un esempio a due giocatori
Gli equilibri di Nash puri, nel Gioco One-Round, corrispondono alle soluzioni stabili.
Esempio (due giocatori): Un esempio di Gioco One-Round è quello illustrato nella Figura
1. Ciascun nodo i preferisce passare per l’altro nodo piuttosto che per il cammino diretto (link
id). La matrice dei payoff corrispondente è la seguente:
2
link 2d
link 21
1
2
1
link 1d
1
1
1
link 12
2
0
0
In questo gioco esistono due equilibri di Nash puri (uno dei due giocatori sceglie il cammino non
diretto mentre l’altro il cammino diretto).
Esempio (tre giocatori): Consideriamo adesso un esempio in cui abbiamo tre giocatori e,
come illustrato nella Figura 2, ciascun giocatore continua a preferire il cammino non diretto
(passante per il prossimo nodo in senso orario) rispetto a quello diretto. Supponiamo che esista
un equilibrio Nash puro. Questo significa che almeno uno dei tre nodi deve aver scelto il cammino
diretto (altrimenti le strategie formano un non-cammino e ogni nodo può migliorare la propria
utilità scegliendo il cammino diretto). Supponiamo che il nodo 3 abbia scelto il cammino diretto
nell’equilibrio di Nash puro. Allora, il giocatore 2 preferisce connettersi al nodo 3, scegliendo il
cammino 23d, invece di andare diretto a d. Infine, il giocatore 1, data la non disponibilità del
cammino 2d, sceglie il link 1d e pubblicizza il proprio cammino verso la destinazione. A questo
punto, però, il giocatore 3 potrebbe decidere di cambiare la propria scelta, dato che utilizzando
il link 1d, otterrebbe una maggiore utilità. Di conseguenza, il nodo 2 cambierebbe la sua scelta,
e cosı̀ via, senza mai arrivare ad una soluzione stabile (cioè ad un equilibrio di Nash puro).
Lo stesso discorso lo possiamo applicare ad un grafo con un arbitrario numero di nodi ed una
sequenza arbitraria di archi (un cammino) al posto di ciascun link tra ogni coppia di nodi. In
generale, tale situazione è definita come
3
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
31d
3d
..
.
∅
3
12d
1d
..
.
∅
1
d
2
23d
2d
..
.
∅
Figura 2: Un esempio a tre giocatori
Ruota della Disputa (vedi Figura 3). Una Ruota della Disputa è definita come una tripla
(U, R, Q), dove U = (u0 , u1 , ..., uk−1 ) è una sequenza di k nodi nella rete e R = (R0 , R1 , ..., Rk−1 )
e Q = (Q0 , Q1 , ..., Qk−1 ) sono sequenze di rotte che esistono in G (gli indici per tali nodi e rotte
devono essere considerati modulo k), e tali che valgono le seguenti condizioni:
• ogni rotta Qi inizia in ui e termina nel nodo di destinazione d.
• ogni rotta Ri inizia nel nodo ui e termina nel nodo ui+1 .
• vi (Qi ) < vi (Ri Qi+1 ), dove Ri Qi+1 è la concatenazione delle rotte Ri e Qi+1 .
Rk−1
u0
R0
u1
Q0
uk−1
Qk−1
d
Q1
R1
Q2
Q3
u4
R3
u3
u2
R1
Figura 3: Ruota della disputa: Ciascun nodo ui preferisce la rotta passante per il nodo ui+1
rispetto al cammino Qi
4
3
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
Gioco della Convergenza
Gli equilibri di Nash puri, nel Gioco One-Round, sono definiti, in letteratura, come soluzioni
stabili. Non è difficile verificare che ciascuna di tali soluzioni forma un albero con radice d
(supponiamo che il grafo sia connesso). Un requisito importante per il protocollo BGP consiste
nel fatto che esso converga ad una soluzione stabile. Tuttavia, questo non è garantito in generale
e, sicuramente, non accadrà se non esiste un equilibrio di Nash puro.
Per studiare se BGP converge o meno ad una soluzione stabile, introduciamo il Gioco della
Convergenza. Tale gioco, sequenziale, asincrono e con informazioni private, modella le dinamiche
dell’interdomain routing. Il Gioco della Convergenza è un gioco multi-round con un numero
infinito di round. In ciascun round vengono scelti da un avversario uno o più giocatori (nodi).
L’avversario modella la natura asincrona di Internet, e decide quali giocatori partecipano ad
ogni round. L’avversario, tuttavia, non può negare, indefinitamente, ad un giocatore di prendere
parte al gioco (deve permettere, ad ogni giocatore, di giocare in un numero infinito di round).
In ciascun round del gioco, un giocatore i può eseguire le seguenti azioni:
• Ricevere (leggere) un messaggio di aggiornamento, inviato dai nodi vicini per annunciare
le loro rotte verso la destinazione.
• Scegliere un unico arco uscente che rappresenta la scelta del nodo vicino verso cui inoltrare
il proprio traffico. Tale scelta viene fatta in base alla funzione di preferenza del nodo e
all’insieme delle rotte dei nodi vicini.
• Annunciare la propria rotta a tutti i nodi vicini. L’avversario decide in quali round gli
annunci inviati, relativi alle rotte, debbano raggiungere i nodi vicini. Esso può ritardare,
tali messaggi, in modo arbitrario, ma non può fare in modo che tali messaggi non giungano
mai a destinazione (può solo ritardarli per un tempo finito).
Una strategia di un giocatore, nel Gioco della Convergenza, specifica le sue azioni in ciascun
round in cui può partecipare al gioco. Il protocollo BGP stabilisce che ogni nodo deve eseguire,
ogni volta che viene fatto giocare, le seguenti azioni: riceve gli annunci più recenti relativi alle
rotte dei propri vicini, sceglie il vicino a cui inoltrare il proprio traffico (in accordo alla propria
funzione di preferenza) e annuncia tale rotta a tutti i propri vicini. Se da qualche round in poi
l’assegnamento della rotta del nodo i è costante, allora il payoff del nodo i è la sua valutazione
per tale rotta (nel Gioco della Convergenza un non-cammino ∅ può significare anche il fatto che
la rotta scelta da i cambia continuamente, senza mai stabilizzarsi).
Esempio (shortest-path). Supponiamo di avere la configurazione della rete illustrata nella
Figura 4. Supponiamo che:
• il nodo 1 preferisce la rotta 12d alla rotta 1d, quindi |P1 Q2 | ≤ |Q1 |;
• il nodo 2 preferisce la rotta 23d alla rotta 2d, quindi |P2 Q3 | ≤ |Q2 |;
• il nodo 3 preferisce la rotta 31d alla rotta 3d, quindi |P3 Q1 | ≤ |Q3 |;
Indichiamo con |P | il numero di archi del cammino P . Prima di procedere con la dimostrazione
della non esistenza della Ruota delle Disputa, mostriamo che per ogni i risulta |Qi | < |Pi+2 Qi |,
dove i valori di i vanno considerati modulo k. Supponiamo che |Qi | = |Pi+2 Qi | allora ciò significa
che |Pi+2 | = 0 e, quindi, che il cammino Pi+2 è un cammino vuoto (la stessa osservazione si
5
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
P3 Q1
Q3 3
P3
Q3
1
P1 Q2
Q1
Q1
d
P2
Q2
P1
2
P2 Q3
Q2
Figura 4: Esempio: Shortest-Path Routing
può fare anche per gli altri cammini Pj ), arrivando cosı̀ ad un assurdo in quanto ogni cammino
contiene almento un arco. Da tale risultato e da |P1 Q2 | ≤ |Q1 | ≤ |P3 Q1 | ≤ |Q3 | ≤ |P2 Q3 | ≤
|Q2 |, risulta:
|Q2 | < |P1 Q2 | ≤ |Q2 |
Ciò costituisce un assurdo e conclude la dimostrazione della non esistenza della Ruota della
Disputa nel protocollo di routing Shortest-Path.
Esempio (il protocollo oscilla continuamente). Nell’esempio con due soli giocatori di
Figura 1, entrambi i nodi 1 e 2 preferirebbero inviare il proprio traffico attraverso l’altro nodo,
invece che andare direttamente alla destinazione. Consideriamo l’esecuzione del protocollo BGP
nel caso peggiore (scelto dall’avversario). La computazione inizia quando d annuncia la propria
identità ai propri vicini, i nodi 1 e 2. A questo punto, i path 1d e 2d sono le uniche rotte
disponibili verso d e, quindi, 1 e 2 sceglieranno le rotte 1d e 2d, rispettivamente, e informeranno l’altro nodo, attraverso un update message, della rotta selezionata. Alla ricezione di tali
messaggi di aggiornamento, i nodi 1 e 2 cambieranno la rotta selezionata, scegliendo 12d e 21d,
rispettivamente. Questa situazione, però, porterà i due nodi a tornare nello stato precedente, e
l’oscillazione continuerà all’infinito.
Teorema (non convergenza). Anche se il gioco One-Round ammette un equilibrio Nash,
non è detto che il protocollo BGP converga (ossia BGP può oscillare per sempre).
Dallo stesso esempio potremmo dimostrare anche questo (il nodo 1 mente annunciando al nodo
2 di non avere la disponibilità del cammino diretto):
Teorema (non incentive compatible).
Il Protocollo BGP non è incentive compatible.
Nella prossima sezione vedremo che la “struttura” delle relazioni commerciali (tra AS) su Internet fanno si che il primo dei due problemi di BGP (non convergenza) viene in effetti risolto,
mentre il secondo problema (non incentive compatible) rimane. Nella Sezione 5.1 vedremo come
risolvere anche questo applicando la “verifica dei cammini” insieme alle relazioni commerciali di
Internet.
6
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
4
Internet: relazioni commerciali tra Sistemi Autonomi e preferenze sui cammini
Lo studio di Internet ha suggerito due tipi di relazioni commerciali che caratterizzano le interconnessioni tra AS: due AS adiacenti possono essere legati da una relazione del tipo cliente-provider,
oppure da una relazione del tipo peering. Gli AS clienti pagano i propri provider per poter
usufruire della connettività da essi offerta. Gli AS peer sono AS che trovano reciprocamente
vantaggioso lo scambio di traffico gratuito tra i loro rispettivi clienti. Un Sistema Autonomo
può avere, contemporaneamente, diverse relazioni commerciali con i propri vicini: può essere
un cliente di uno o più AS, un fornitore di altri, ed un peer di altri ancora. Rappresentiamo le
relazioni tra gli AS orientando gli archi (link fisici) nel modo seguente:
peer
peer
cliente
provider
Intuitivamente, possiamo pensare ad un cliente come qualcuno che ci paga e non può rifiutarsi
di fare qualcosa per noi, mentre un nostro peer è qualcuno con cui ci si è messi d’accordo per
inviare una certa quantità di traffico ed è meglio non abusarne troppo. Infine, poichè i nostri
provider li dobbiamo pagare (e più traffico mandiamo più paghiamo) le preferenze sui cammini
rispecchieranno le relazioni commerciali:
1. Relazioni commerciali e preferenze: Ogni nodo classifica i cammini da lui alla destinazione in base alla scelta del vicino (primo link del cammino). Se il link raggiunge un AS
cliente/peer/provider allora diremo che il cammino è un cammino cliente/peer/provider.
Ogni nodo preferisce i cammini cliente ai cammini peer o provider, e i cammini peer a
quelli provider:
cliente
a
iaA
..
.
ibB
..
.
icC
..
.
i
..
.
A
paritario
B
b
d
C
c
provider
2. Non esistenza di cicli cliente-provider: Sia GCP il grafo diretto con lo stesso insieme
di nodi di G e con un arco diretto da ogni cliente al proprio provider diretto, allora non
devono esserci cicli diretti nel grafo GCP . Tale requisito ha una naturale giustificazione
economica in quanto sta a sottolineare il fatto che nessun Sistema Autonomo deve essere
(indirettamente) il fornitore di se stesso.
7
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
3. No transito gratis: Un nodo non sempre trasporta il traffico di transito che ha origine e
terminazione al di fuori del nodo stesso. Gli AS sono obbligati a trasportare il traffico di
transito da e per i loro cliente. Tuttavia, gli AS non trasportano il traffico di transito tra i
loro provider e peer. Pertanto, un AS dovrebbe condividere solo le rotte da/per un cliente
con i propri provider e peer, e dovrebbe condividere tutte le rotte con i propri clienti. Se
un nodo i non pubblicizza (rende disponibile) un cammino ad un suo vicino j, quest’ultimo
non potrà mai sceglierlo.
Se valgono le condizioni viste sopra (“relazioni commerciali e preferenze”, “no cicli clienteprovider”, e “no transito gratis”) riusciamo a risolvere il problema della non-convergenza di
BGP (oscillazione continua):
1. La rete non contiene nessuna ruota della disputa
2. Il protocollo converge sempre
Non dimostreremo questi due fatti, ma possiamo comunque dare un’idea della dimostrazione.
No ruota della disputa (idea della dimostrazione). Se proviamo a costruire una ruota
della disputa con 3 nodi come in Figura 2 dobbiamo trovare un’orientazione degli archi “compatibile” con le condizioni “relazioni commerciali e preferenze”, “no cicli cliente-provider” e “no
transito gratis”. Ad esempio, se questa è l’orientazione (tutti sono paritari):
3
1
d
2
la condizione “no transito gratis” ci dice che nessuno dei tre nodi mette a disposizione il proprio
cammino agli altri. Quindi, il cammino 32d non è mai disponibile per il nodo 3, il cammino 12d
non è disponibile per 1, e il cammino 23d non è disponibile per 2. Se lasciamo gli archi esterni
orientati come sono, quelli interni devono essere messi cosı̀:
3
1
d
2
(È l’unico modo per cui ogni nodo rende disponibile il suo cammino diretto a quello che lo
precede). Ora però le preferenze dei cammini non rispecchiano le relazioni commerciali: il nodo
8
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
3 dovrebbe preferire il cammino cliente 3d al cammino paritario 32d (mentre per ottenere la
ruota della disputa deve succedere esattamente il contrario).
Per dimostrare che non si può avere la ruota della disputa (a tre giocatori) ragioniamo sugli
archi interni e vediamo i due casi possibili:
1. Nessun arco interno diretto verso d: Faremo vedere che la disponibilità dei cammini
(ad esempio 31d disponibile a 3) ci costringe a costruire un ciclo diretto “antiorario” sui
nodi esterni. Infatti, se l’arco tra 1 e d non è diretto verso d, allora d non è un cliente
di 1. L’unico caso in cui 1 rende disponibile il cammino 31d al nodo 3 è che quest’ultimo
sia un cliente di 1: ossia l’arco tra 3 e 1 è diretto verso 3. Le preferenze della ruota della
disputa (3 preferisce 31d a 3d) ci forzano a orientare anche l’arco tra 3 e d verso 3:
3
1
d
2
Ora la storia si ripete uguale con il nodo 3 al posto del nodo 1 e poi col nodo 2, forzandoci a
creare il ciclo esterno “antiorario” di clienti-provider 1 → 3 → 2 → 1. Questo contraddice
“no cicli clienti-provider” e quindi in questo caso la ruota della disputa non può esistere.
2. Almeno un arco interno diretto verso d: Faremo vedere che le preferenze dei nodi
sulla ruota della disputa (ad esempio 3 preferisce 31d rispetto al cammino 3d) ci costringe
a costruire un ciclo diretto “orario” sui nodi esterni. Supponiami che l’arco diretto verso d
sia quello tra 3 e d (altrimenti facciamo lo stesso ragionamento sul nodo dell’arco diretto
verso d). Siccome 3 preferisce 31d a 3d, dobbiamo orientare anche l’aco tra 3 e 1 verso 1:
3
1
d
2
Significa che 1 è un cliente di 3 e l’unico modo per cui 1 renda disponibile il cammino 31d
al suo provider (nodo 3) è che d sia cliente di 1, ossia anche l’arco tra 1 e d è diretto verso
d. Ripetendo lo stesso ragionamento con 1 al posto di 3 e poi con 2 otteniamo il ciclo
esterno “orario” 3 → 1 → 2 → 3. Questo contraddice “no cicli clienti-provider” e quindi
anche in questo caso la ruota della disputa non può esistere.
Abbiamo dimostrato che l’esistenza della ruota della disputa a tre giocatori violerebbe una delle
condizioni viste sopra. In altre parole, se le tre condizioni valgono, questa ruota della disputa
non può esistere.
9
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
BGP converge (idea della prova).
esempio:
Cerchiamo di capire perchè BGP converge tramite un
0d
..
.
10d
..
.
∅
∅
0
21d
..
.
2d
..
.
∅
2
1
d
Ecco cosa succede:
• Prima o poi l’avversario farà giocare 0 che come migliore scelta ha il cammino diretto 0d.
Da questo momento in poi la sua scelta non cambia.
• Prima o poi 1 viene a conoscenza del fatto che 0 ha scelto 0d. Dopo di che, ad un
certo punto, l’avversario dovrà far giocare 1 che quindi avrà a disposizione il suo migliore
cammino (10d) e lo sceglie. Da qui in poi le scelte di 0 e 1 non cambiano.
• Prima o poi anche il nodo 3 verrà informato e fatto giocare dall’avversario. Il nodo 3 farà
la sua migliore scelta e, a nche se non sappiamo quale sia, non cambierà perchè gli altri
due non cambiano più la loro decisione.
Possiamo spiegare la cosa in questo modo:
• Un nodo i0 ha una strategia dominante D0 (questo cammino è il migliore, qualsiasi scelta
facciano gli altri)
• Un nodo i1 ha una strategia dominante D1 nel gioco in cui i0 gioca la sua strategia
dominante D0 (non importa cosa fanno gli altri)
.
• ..
• Un nodo ik ha una strategia dominante per il gioco in cui i nodi tutti i nodi precedenti
i0 , i1 , . . . , ik−1 giocano D0 , D1 , . . . , Dk−1 (non importa cosa fanno gli altri nodi)
.
• ..
fino all’ultimo nodo in . Se vale questa proprietà di “dominanza passo-passo”, possiamo convincerci (ragionando come nell’esempio) che qualsiasi cosa faccia l’avversario, il protocollo BGP si
stabilizzera con i giocatori che giocano le strategie D0 , D1 , . . . , Dn .
Per dimostrare che BGP converge nel caso delle tre condizioni “relazioni commerciali e preferenze”, “no cicli cliente-provider”, e “no transito gratis” si fa vedere che
tre condizioni ⇒ no ruota disputa ⇒ dominanza passo passo ⇒ BGP converge
Noi abbiamo visto solo un’idea della prima e dell’ultima implicazione.
10
5
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
Compatibilità agli incentivi del protocollo BGP
Anche se valgono le relazioni commerciali tra AS, il Protocollo BGP rimane manipolabile (se
un nodo esegue una versione modificata del Protocollo, MBGP, è possibile che la sua utilità
migliori).
Teorema (non incentive compatible – versione Internet). Il Protocollo BGP non è incentive compatible, anche assumendo i vincoli sulle relazioni commerciali e preferenze di Internet
descritte in Sezione 4.
Dimostrazione. Consideriamo la rete nella Figura 5 (sinistra). Osserviamo che le preferenze
sono compatibili con le relazioni commerciali (figura a destra) e che queste soddisfano la condizione non esistenza di cicli cliente-provider. Le prime due rotte preferite da ciascun nodo sono
elencate accanto ad esso, in ordine di preferenza.
m1d
m12d
3
1
12d
1d
m1d
m12d
3
12d
1d
d
d
2
1
2md
2d
2
2md
2d
Figura 5: Rete fisica e preferenze (sinistra) e relazioni commerciali (a destra)
Se supponiamo che i nodi 1, 2 (e d) eseguono il Protocollo BGP (in particolare il vincolo di “no
transito gratis” su quali rotte vengono annunciate), allora il nodo m può ancora guadagnare
mentendo al nodo 2 nel modo seguente: il nodo m annuncia al nodo 2 (continuativamente) che
la propria rotta è md (nota che m sta eseguendo la versione modificata di BGP). Il nodo 2,
che esegue BGP, in base a questa falsa informazione sceglierà di connettersi ad m (pensando di
scegliere il cammino 2md). A questo punto, a seguire, il nodo 1 prima o poi sceglierà la rotta
diretta 1d (la rotta 12d non è disponibile). Questo permette al nodo m di scegliere la sua rotta
preferita m1d. Quindi il nodo m guadagna nell’eseguire questa versione modificata MBGP del
protocollo BGP.
5.1
Verifica dei cammini (e compatibilità agli incentivi)
Il fatto che il Protocollo BGP, cosı̀ come è, non è incentive compatible (è manipolabile), può
essere corretto attraverso l’utilizzo del meccanismo di:
Verifica dei cammini: Ogni nodo può annunciare un cammino solo se questo è
disponibile a lui (ossia gli altri nodi del cammino hanno effetivamente scelto questi
link).
Teorema (incentive compatible con verifica). Se valgono i vincoli sulle relazioni commerciali e preferenze di Internet descritte in Sezione 4 e se viene effettuata la verifica dei cammini,
allora BGP è incentive compatible.
11
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
Dimostrazione (parte vista a lezione)
Sappiamo che
relazioni commerciali =⇒ no routa disputa =⇒ stabile
Facciamo vedere che se BGP è manipolabile (non è incentive compatible) allora esiste una ruota
della disputa (assurdo):
manipolatore =⇒ routa
r0
BGP
stabile T
M
Guardiamo alle due soluzioni e etichettiamo i nodi cosı̀:
6=
se i non sceglie
lo stesso vicino
nelle due soluzioni
i
=
i
se in entrambe
le soluzioni i
ha scelto lo stesso vicino
Ecco come indichiamo i cammini da i alla destinazione:
d
d
Mi
Ti
i
i
T
M
Manipolatore: preferisco M rispetto a T
r0
Mr0
Tr0
Struttura della dimostrazione: costruiamo una sequenza “alternata”
12
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
r0
r1
r2
Mr0
Tr0
Tr1
Mr1
Mr2
Tr2
···
r0
e prima o poi
ripasso per lo
stesso nodo due volte
(ciclo)
ad esempio
u0
r0
Mr0
Tr0
···
u0
u0
u1
u2
u3
Tu0 Mu1 Tu2 MuT 3 Mu0
Mu0 Tu1 Mu2 Tu3 Mu0
Mu0
Tu3
u3
u1
d
Tu1
Mu2
meno preferiti
u2
Per completare la ruota vorrei
u0
Tu0
Mu0
Tu0 è il cammino attraverso u1
u0
u1
d
Mu0
d
u1
Tu0 =“rosso” + Tu1
u0
= Tu0 \ Tu1
Tu1
u1
e cosı̀ via per gli altri “spicchi” della ruota.
Costruiamo la sequenza e verifichiamo che pssiamo mettere i cammini esterni alla ruota:
Mr0
d
r0
Mr0
Tr0
Se tutti i nodi intermedi sono etichettati con “=” allora anche la soluzione T contiene lo stesso
identico sottocammino:
d
r0
Tr0
Ma in T r0 sceglie Tr0 1 . Questo è impossibile perchè in T r0 utilizza BGP e quindi sceglie sempre
il migliore tra i cammini che preferisce (potrebbe scegliere Mr0 ma sceglie Tr0 ). Quindi abbiamo
dimostrato che deve succedere questa cosa:
1
Nota che Mr0 6= Tr0 perchè altrimenti non c’è alcun vantaggio a manipolare il protocollo.
13
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
Mr0
d
r0
Mr0
Tr0
almeno uno etichettato “6=”
Prendiamo quello più vicino a d:
Mr0
r1
6=
r0
d
=
=
il vicino scelto da r1 in T è un altro,
mentre quelli dopo di lui facevano la stessa scelta
Quindi in T :
r1
d
=
=
Tr1
Perchè r1 non ha scelto il cammino di sopra (che è quello in M )? Perchè r1 preferisce Tr1 rispetto
a Mr1 . Quindi abbiamo
r0
r1
Mr0
Tr0
Tr1
Mr1
Mr0
con
r0
r1
Tr1
d
Se facciamo un altro passo ripartendo da r1
Tr1
r1
d
r2
il più a destra etichettato 6=
otteniamo un altro “spicchio” della ruota. Prima o poi ripassiamo per un nodo la seconda
volta. Due casi:
14
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
Caso 1. Il nodo ripetuto non è r0 :
r0 · · ·
u u ···u
u0
| 0 1 {z k−1}
k nodi della ruota
k non può essere dispari:
u0
u1
u2
u0
Tu0
Mu0
Mu1
Tu1
Tu2
Mu2
Mu0
Tu0
contraddizione
k pari =⇒ ho la ruota:
Mu3 \ Mu0
u0
Mu0
Tu3
u3
Tu2 \ Tu3
Tu0 \ Tu1
u1
d
Tu1
Mu2
u2
Mu1 \ Mu2
Caso 2. Il nodo ripetuto è r0 .
Sottocaso k pari. Costruisco la ruota come prima
Sottocaso k dispari. Questo è il caso che non abbiamo visto a lezione e ne diamo solo
l’idea.
A differenza del caso in cui il nodo ripetuto non era r0 , ora è possibile che k sia
dispari, ma solo nel caso r0 mentisse al nodo precedente rk−1 comunicando un falso
cammino Fr0
⇓ verifica dei cammini
Fr0 è effettivamente disponibile
Inoltre le preferenze del manipolatore devono essere fatte cosı̀
r0
Mr0
Tr0
Fr0
con i cammini fatti cosı̀
15
Lecture 6–7: Protocollo BGP e Teoria dei Giochi
r0
Fr0
Mr2 \ Fr0
Mr0 \ Mr1
Tr0
d
Tr2
r1
Mr1
Tr1 \ Tr2
rr2
e togliendo “Tr0 ” ottengo la ruota (per la verifica dei cammini, Fr0 è un cammino
effettivamente disponibile).
Chi è stato (molto) attento avrà notato che ogni volta che parliamo della soluzione M andiamo
a guardare un certo cammino Mi . Questo cammino esiste solo se la soluzione M è stabile.
La stabilità di T era dovuta al fatto che tutti eseguivano BGP, mentre quando il manipolatore
esegue un altro protocollo (BGP manipolato) non è detto che si arrivi ad una configurazione
stabile. Definendo in modo opportuno i cammini Mi nel caso di oscillazioni continue si può
applicare lo stesso schema della dimostrazione. Per i dettagli [LSZ08] o sulle note informali
disponibili su
http://libeccio.dia.unisa.it/agt/aggiunte-lezione7.pdf
o alla pagina del corso (a.a. 2009–2010).
6
Risultati visti
BGP
Converge
Incentive Compatible
Generale
NO
NO
Internet
SI
NO
Internet + Verifica Cammini
SI
SI
Per chi ne vuole sapere ancora di più: [FSS07, Capitolo 14] e gli articoli citati in [LSZ08].
Riferimenti bibliografici
[FSS07] Joan Feigenbaum, Michael Schapira, and Scott Shenker. Distributed Algorithmic Mechanism Design, chapter 14 of Algorithmic Game Theory. Cambridge University Press,
2007.
[LSZ08] Hagay Levin, Michael Schapira, and Aviv Zohar. Interdomain routing and games. In
Proceedings of the 40th annual ACM symposium on Theory of computing, pages 57–66.
ACM, 2008.