dans le r´eseau ne doit pas d´epasser la taille de la fenˆetre CWND. A la d´etection d’un rejet par d´etection rapide ou timeout, la fenˆetre est r´eduite suivant un facteur ; plus ce facteur est proche de 1, plus le protocole est aggressif. En absence de perte, la fenˆetre CWND croˆıt lin´eairement selon un certain taux. Encore, plus ce taux est grand, plus le protocole est aggressif.
3.2 M´ecanismes pour op´erateurs
En plus de l’ordonnancement “fair queuing”, nous envisageons un m´ecanisme pr´eventif de rejet d’Interest. L’op´erateur devrait ´egalement exploiter les sources multiples de certaines donn´ees en appliquant une strat´egie d’acheminement adapt´ee.
3.2.1 Motivation ´economique
Il est important de mettre en place une motivation ´economique pour encourager l’op´erateur `a d´eployer cette nouvelle architecture. Il est ´egalement important que le fournisseur de r´eseau soit r´emun´er´e pour le trafic qu’il ´ecoule.
On consid`ere que le fournisseur devrait ˆetre pay´e pour les data envoy´es ; par exemple, dans la figure 3.1, l’utilisateur U1 paye le fournisseur P1 pour les data qu’il fournit, et P1 paye P2 pour les data re¸cus. Cette approche fournit bien la motivation n´ecessaire pour d´eployer un r´eseau CCN muni de caches, car le fournisseur, en utilisant des caches, ne serait pas amen´e `a acheter le mˆeme contenu plusieurs fois.
Les frais devraient couvrir les coˆuts d’infrastructure (bande passante et caches), et leur nature exacte pourrait prendre de nombreuses formes, y compris les tarifs forfaitaires et des accords de peering.
3.2.2 Interest Discard
L’utilisateur ne paye le fournisseur que s’il re¸coit effectivement la donn´ee. Le four-nisseur doit donc assurer un contrˆole de congestion afin d’´eviter la perte des donn´ees transmises `a ses clients. Il a int´erˆet `a rejeter les Interests en exc`es pour ´eviter de rache-ter des donn´ees qui ne peuvent pas ˆetre revendues `a cause d’une congestion ´eventuelle. Afin d’´eviter un tel probl`eme, nous proposons un m´ecanisme compl´ementaire pour prot´eger le fournisseur.
Supposons le lien AB dans la figure 3.1 congestionn´e ; B va limiter le d´ebit des Interests envoy´es vers le fournisseur P2 pour ´eviter d’acheter des donn´ees qui ne seront pas revendues `a l’utilisateur final U1 puisqu’elles seront perdues `a cause de la congestion. Nous appelons ce m´ecanisme “Interest Discard”.
On consid`ere le lien AB de la figure 3.1. A re¸coit les paquets Interest de U1 et renvoie ces paquets vers B. B re¸coit dans l’autre sens les paquets de donn´ees r´ecup´er´es du fournisseur P2 et applique le Deficit Round Robin sur les paquets Data envoy´es vers A.
CHAPITRE 3. M ´ECANISMES POUR CCN 29 Ub Aout Bin Bout Ain Interests Data Interests Data Sb Ua Sa
Figure 3.1 – Les cartes r´eseaux des routeurs A et B travers´ees par des paquets Interest et
Data
B calcule en effet un d´ebit d’´equit´e correspondant `a l’inverse du temp de cycle moyen de DRR. Le d´ebit des Interest est limit´e par des rejets forc´es en utilisant un sceau `
a jetons. Le d´ebit des Interests est limit´e au d´ebit correspondant au d´ebit ´equitable r´ealis´e actuellement par le DRR (tenant compte de la taille diff´erente des paquets
Interest et Data). Le sceau `a jetons est donc aliment´e au rythme de l’ordonnancement.
Notons que le DRR et le sceau `a jetons seront r´ealis´es dans la mˆeme carte r´eseau
facilitant ainsi leur couplage. Nous pr´esentons le pseudocode interest Discard, cet algorithme doit ˆetre utilis´e au niveau de chaque interface r´eseau. Il est ex´ecut´e `a l’arriv´ee d’un interest `a l’interface, et `a chaque cycle Round Robin incr´ementer tous les compteurs de l’interface. Nous r´esumons ci-dessous l’algorithme ex´ecut´e au niveau de l’interface r´eseau.
Algorithm 1 A l’arriv´ee d’un paquet interest `a l’interface r´eseau R´ecup´erer le nom d’objet du paquet name
Calculer le hash du nom d’objet hash if f ile[hash]∄ then
Cr´eer la file ayant comme ID hash
Attribuer un compteur count[hash] au flux Initialiser le compteur count[hash] = b end if if count(hash)==0 then rejeter l’interest i else count(hash)- - ; end if
Nous adoptons le DRR comme algorithme fair queuing, il utilise un nombre fixe de files. On note M le nombre maximal de files Round Robin
30 3.2. M ´ECANISMES POUR OP ´ERATEURS
Algorithm 2 A la sortie de l’interface r´eseau i = 0
while i < M do if f ile[i]∃ then
Servir le premier paquet de f ile[i] end if
if f ile[i] = ∅ et count[i] = b then Supprimer la file physique f ile[i] end if
for i = 0 to M − 1 do count[i] = count[i] + 1 end for
Chapitre
4
Strat ´egies d’acheminement
L’architecture CCN offre de nouvelles possibilit´es d’acheminement. Il est en particu-lier possible d’utiliser plusieurs sources pour un mˆeme objet. Nous avons fait quelques ´etudes sur l’acheminement multi-sources. On d´emontre que les m´ecanismes de ges-tion du trafic foncges-tionnent bien dans ce contexte. Cependant, avant de poursuivre la recherche dans ce domaine, il est essentiel de comprendre les possibilit´es r´eelles qu’offrirait un r´eseau CCN en fonction de sa politique de stockage. Nos ´etudes dans cette direction sont d´ecrites dans les deux parties suivantes de ce rapport.
4.1 Multicast
Sur la figure 3.1 les utilisateurs Ua et Ub demandent le mˆeme objet stock´e au niveau
du fournisseur S1. Si les demandes se passent en mˆeme temps, une seule demande sera
enregistr´ee au niveau du routeur B et donc le flot correspondant `a l’objet demand´e
aura le mˆeme d´ebit des flots unicast dans le lien BS1. Il n’y a donc pas lieu de
distinguer ces flots dans l’ordonnanceur DRR.
Si les demandes sont d´ecal´ees dans le temps et que l’utilisateur Ua commence le
t´el´echargement des paquets avant l’utilisateur Ub, il est possible que le d´ebit accord´e
au flot soit divis´e par deux au niveau du lien BS1. Mais puisque le routeur B est
dot´e d’une m´emoire cache, il est tr`es probable que l’utilisateur Ub trouve les paquets
pr´ec´edemment t´el´echarg´es par Ua au niveau du cache B, et donc seuls les paquets
non t´el´echarg´es par U1 seront demand´es et traverseront le lien S1B. Le d´ebit des
flots multicast est donc ´egal au d´ebit des flots unicast sur toutes les branches du r´eseau. Il suffit que le temps de t´el´echargement d’un objet soit inf´erieur au temps de stockage de l’objet dans un cache. Encore, il n’y a pas lieu de distinguer ces flots dans l’ordonnanceur DRR.