Académique Documents
Professionnel Documents
Culture Documents
_
congestion
= f
_
LLA
CLA
_
(8.5)
et :
_
CLA
+
CLA
_
congestion
= g
_
CLA
LLA
_
(8.6)
avec :
:le temps discrtis la frquence de dtection des congestions,
f,g : des fonctions monotones croissantes positives.
Dautres propositions sont galement envisageables et permettraient
une convergence vers dautres critres dquit. Cependant, nous mon-
trerons par la suite quun certain nombre de contraintes seront
respecter notamment sur les fonctions drives an de ne pas rendre
le systme instable.
8.5 critre de stabilit du systme
Nous avons vu prcdemment que le systme va rduire ses limites
daccs lors dune congestion jusqu la suppression de celle-ci. Une
fois la congestion termine, le systme va pouvoir de nouveau largir
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
44 formalisation du systme tdcn-ecn
ses limites. Si la caractristique des ux na pas volu entre temps,
la congestion rapparatra. Cela signie que, dans le cas de prols de
ux entranant une priode de congestion longue, le systme oscillera
entre congestion et non congestion au niveau du coeur de rseau. Il
convient donc pour que lamplitude doscillation du systme soit faible
de respecter la rgle :
Rgle TDCN 7 La loi dvolution doit respecter linquation suivante :
lim
t
congestion
0
CLA
+
CLA
< (8.7)
avec : : terme en octets sufsament petit face au dbit des liaisons.
8.6 dtection de bande libre optimise
Lun des possibles effets sous optimal du systme repose sur son
temps de raction qui peut tre relativement lent notamment lors-
quun prol de dbit anciennement agressif devient passif. Lexemple
classique est un transfert fort dbit nissant pour un client qui pos-
sde un fort LLA. Le transfert une fois termin libre une part non
ngligeable de la bande passante de la liaison; les autres clients ne
peuvent alors lutiliser du fait des limitations dautorisations prsentes
sur leurs accs.
An dattnuer le phnomne, il convient dacclrer cette libration.
Une longue priode de non congestion devra se traduire par une sup-
pression des anciennes limites en accs. Pour tre efcace, le systme
devra respecter la proposition suivante :
Proposition TDCN 8 Pour tre efcace, le systme devra respecter :
lim
t
congestion
+
CLA
+
CLA
= + (8.8)
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
8.7 rsum du systme 45
8.7 rsum du systme
Tunnels LSP
Notications de congestion sur
le tunnel
Rgulateur dynamique d'acces
Rseau des oprateurs virtuels
S
e
n
s
d
e
l
a
c
o
n
g
e
s
t
i
o
n
Figure 14: Principe du TDCN
Finalement, le systme propos repose sur lassociation dune signa-
lisation de coeur et dune rgulation daccs (gure 14). La complexit
du systme est principalement situe dans les mcanismes du DAR
et dans leurs interactions. Jusqu prsent un certain nombre de cri-
tres ont t retenus en premire approche mais non-dmontrs. Dans
le chapitre suivant nous nous focaliserons sur le fonctionnement du
systme et nous dmontrerons lintrt de celui-ci.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
Quatrime partie
ETUDE THORI QUE DES PERFORMANCES
DU SYSTME TDCN
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
9
MODLI SATI ON DU SYSTME TDCN
Le chapitre prcdent nous a permis de dnir une proposition
de mcanisme de rgulation. Nous allons maintenant nous attacher
raliser une modlisation de ce systme. Dans un premier temps
nous dtaillerons le fonctionnement dun rgulateur et nous propose-
rons une modlisation. Puis nous focaliserons notre attention sur les
interactions entre rgulateurs.
9.1 le rgulateur fractionnel
Ce rgulateur repose sur les principes dactions proportionnelles.
Cest dire que laction du rgulateur est dpendante des deux para-
mtres CLA et LLA. Par rapport TCP, la variation TDCN est une
chelle temporelle suprieure ( ?50 ms pour TCP, ?1sec pour TDCN)
et ainsi intervient en complment de celui-ci. Son action, dpendante
de la valeur des contrats, va progressivement permettre dtablir une
quit qui ne pourrait exister avec TCP seul. Lors dune phase de
congestion un rgulateur modulera son action proportionnellement
sa CLA courante, mais galement de manire inversement propor-
tionnelle sa LLA contractualise pour avantager ainsi les contrats les
plus forts.
Lors dune phase de non congestion le raisonnement inverse est
appliqu.
Dans la pratique, le dcrment en congestion est proportionnel au
rapport
CLA
LLA
et lincrment en non-congestion est proportionnel au
rapport
LLA
CLA
.
9.1.1 Evolution du rgulateur en congestion
En congestion, la valeur D du dcrment sera calcule grce la
formule D = A
CLA
LLA
o A est une constante exprime en bits par
secondes.
Pour le moment la valeur de la constante A est attribue arbitraire-
ment. Nous verrons par la suite que la valeur de cette constante peut
tre optimise. La gure 15 reprsente lvolution de la valeur de ce
49
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
50 modlisation du systme tdcn
CLA (Mb/s)
LLA (Mb/s)
Dcrment (b/s)
1000
0
500
80
20
10
40
Figure 15: Valeur du dcrement (A :15b/s)
dcrment en fonction des CLA et LLA. On observe ainsi dans le dia-
gramme en 3D qu CLA constant le plus faible contrats dcrmentera
plus vite et que pour un mme contrat le rgulateur la limite la plus
forte dcrmentera plus rapidement.
Durant une priode de congestion, on pourra dterminer lvolution
dun rgulateur grce la rgle rcursive suivante, comme le montre
la gure 16 :
CLA
+
= CLA
CLA
LLA
A (9.1)
9.1.2 Evolution du rgulateur en non-congestion
En non-congestion, la valeur I de lincrment sera calcule avec
la formule I = B
LLA
CLA
o B est une constante exprime en bits par
seconde. L encore, nous tudierons plus tard loptimisation de cette
constante. La gure 17 reprsente la valeur de cette incrment en
fonction du CLA et du LLA.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
9.1 le rgulateur fractionnel 51
Figure 16: Evolution au cours du temps de la CLA en congestion(A=100)
CLA (Mb/s)
LLA (Mb/s)
Incrment (b/s)
400
0
200
80
20
10
40
Figure 17: Valeur de lincrment (A :15b/s)
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
52 modlisation du systme tdcn
Durant cette priode, on pourra galement dterminer lvolution
du rgulateur grce la formule suivante, comme le montre la gure
18 :
CLA
+
= CLA
+
LLA
CLA
B (9.2)
Figure 18: Evolution au cours du temps du CLA en non-congestion (B=400)
9.2 mise en quations
9.2.1 Modlisation dun DAR
Lors dune priode de congestion un rgulateur agit comme une
suite. En effet, son fonctionnement rcursif justie ce type de modlisa-
tion. Le rgulateur rpond lquation 9.3 en congestion et lquation
9.4 en non-congestion.
CLA(t +1) = max(CLA(t) f(CLA(t)), LLA) (9.3)
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
9.2 mise en quations 53
CLA(t +1) = min(CLA(t) +g(CLA(t)) , HLA) (9.4)
En temps normal la somme des CLA peut dpasser la capacit des
liaisons. En effet, la CLA reprsente la limite du dbit dun client mais
nest pas forcment atteinte.
Lorsquune liaison est congestionne, la somme des dbits clients
sera gale la capacit de la liaison. Le systme TDCN diminuera
lensemble des CLA, jusqu lobtention dune limitation des dbits.
On obtient alors une valeur E gale la somme des CLA.
Dans ces conditions, la congestion de coeur va perdurer tant que la
somme des CLA des tunnels est suprieure la valeur E. Ds quelle
passera en dessous, les ux ne pourront plus maintenir la congestion.
On remarquera toutefois que la valeur E peut tre gale la bande
passante dans le cas particulier o tous les clients utilisent des ux
lastiques susceptibles de prendre toute la bande passante.
Par consquent, pour une liaison de Dbit E compose de n tunnels,
on aura une congestion lorsque lquation 9.5 est respecte et une
non-congestion lorsque lquation 9.6 est respecte.
n
k=0
CLA
k
> E (9.5)
n
k=0
CLA
k
< E (9.6)
Lensemble des observations prcdentes repose sur un certain
nombre dhypothses :
le temps de transport de linformation de congestion est ngli-
geable face au dlai entre deux dcrments,
les rgulateurs agissent tous au mme rythme et leffet de leurs
dsynchronisations est ngligeable,
les ux lastiques agrgs occupent instantanment la bande pas-
sante disponible.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
54 modlisation du systme tdcn
On peut ainsi poser le systme suivant driv des conclusions de la
section :
CLA
k
t+1
= max
_
CLA
k
t
+f(CLA
k
t
, LLA
k
, HLA
k
), LLA
k
_
k et si :
m
k=0
CLA
k
t
E
CLA
k
t+1
= min
_
CLA
k
t
+g(CLA
k
t
, LLA
k
, HLA
k
), HLA
k
_
k et si :
m
k=0
CLA
k
t
> E
(9.7)
9.3 etude dun systme dar fractionnel
A partir du modle propos prcdemment, nous allons effectuer
une simulation mettant en vidence les diffrentes phases dune
congestion TDCN.
Nous considrons une liaison congestionne regroupant 3 tunnels
MPLS manags avec notre nouveau systme TDCN. La liaison possde
une capacit de 1 Gb/s. Les congurations TDCN sont identiques
pour chacun des tunnels (HLA=1 Gb/s LLA= 100 Mb/s). Grce la
modlisation que nous venons de raliser, nous pouvons prdire le
fonctionnement du systme lorsque lensemble des clients va essayer
de consommer les 1 Gb/s de donnes de la HLA.
La gure 19 est un exemple de lvolution de la CLA suite lappa-
rition de cette congestion. Chaque systme dispose de courbes propres
en fonction dune part du paramtrage des rgulateurs mais galement
en fonction des conditions initiales. Nous tudierons leurs impacts
respectifs dans un chapitre ultrieure. Cependant, dune manire g-
nrale, on retrouve trois phases distinctes suite lapparition dune
congestion dans un systme TDCN :
La zone de congestion : Cette zone apparat au dbut de la conges-
tion de coeur. Pendant cette priode, tous les rgulateurs dur-
cissent pas pas leurs politiques daccs an de supprimer cette
congestion. Une fois la congestion stoppe, le systme rentre dans
son deuxime tat.
La zone dquilibrage : Pendant cette priode, le systme oscille
entre un tat de congestion et un tat de non congestion. A lissue
de la phase prcdente, la CLA des rgulateurs sest positionne
dans un tat intermdiaire dpendant des congurations mais
galement des conditions initiales. Par la suite les rgulateurs
vont modier leur CLA en faisant varier leurs incrments et dcr-
ments pour nalement atteindre un tat stable indpendant des
conditions initiales.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
9.3 etude dun systme dar fractionnel 55
Z
o
n
e
d
e
C
o
n
g
e
s
t
i
o
n
Z
o
n
e
d
'
q
u
i
l
i
b
r
a
g
e
Z
o
n
e
d
'
q
u
i
t
n
i=0
CLA
i
= Bp
n
i=0
LLA
i
D
A
= Bp
n
i=0
LLA
i
B
I
= Bp
D
A
=
Bp
n
i=0
LLA
i
B
I
=
Bp
n
i=0
LLA
i
(9.9)
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
58 modlisation du systme tdcn
On a alors pour chaque rgulateur le respect de lquation suivante :
CLA
i
= Bp
LLA
i
n
i=0
LLA
i
(9.10)
On peut en conclure que le partage en mode congestionn de la bande
passante est un partage barycentrique o la LLA fait ofce de poids.
La modlisation ralise dans ce chapitre, nous a permis de prdire
le fonctionnement du systme lors de lapparition dune congestion.
Jusqu prsent celle-ci nous a servi identier les trois phases symp-
tomatiques du systme.
Par la suite, nous utiliserons cette modlisation et les rsultats obte-
nus pour tablir et tester un systme exploitable dans un cas rel.
9.4 etude dune application base sur le tdcn
Le framework TDCN a de multiples faons dtre utilis et congur.
Le choix retenu dpendra notamment du modle commercial mais
galement des choix industriels et des paramtres que lon souhaitera
optimiser.
Dans ce chapitre, nous allons proposer une manire spcique de
congurer ce framework et nous montrerons toutes les garanties qui
en dcoulent.
9.4.1 Lapproche par mtaux prcieux
An de simplier les possibilits, nous proposerons dans ce chapitre
trois types de contrats standards proposs par les oprateurs : Gold,
Silver et Bronze. Contrairement aux offres actuelles, nous verrons que
les garanties fournies ne reposent pas sur des approches statistiques
mais sont bases sur le fonctionnement intrinsque du systme.
Exemple illustratif
An dillustrer ce cas pratique, nous allons nous focaliser sur une
liaison 1 Gb/s dans laquelle on situe :
10 contrats gold 10Mb/s,
60 contrats silver 10Mb/s,
100 contrats bronze 10Mb/s,
1 contrat gold 100Mb/s,
1 contrat silver 100Mb/s,
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
9.4 etude dune application base sur le tdcn 59
1 contrat gold 100Mb/s.
Le dbit des contrats se traduit directement dans le systme par la
valeur HLA des rgulateurs. On remarquera dans le cas prsent que la
somme des HLA est suprieure la capacit de la liaison. On a donc
un taux dunder-provisioning de 2. Dans cette situation, on considre
que nos clients nutilisent pas simultanment lensemble de leur bande
passante. Le contrat ne garantit de toute manire quune partie de
cette bande passante.
9.4.2 La conguration du systme TDCN
Conguration du LLA
Pour raliser la diffrentiation entre les diffrents types de contrats,
nous fournissons un LLA au prorata (not ) du contrat HLA. Ainsi,
les clients Gold auront 70% de leur trac garanti, les Silver 50 % et les
Bronze 20%.
Ainsi dans notre exemple illustratif, lensemble du dbit garanti
slve 710Mb/s. Ce qui correspond une liaison disposant pour le
trac garanti un taux dover-provisioning de 40%. On aura donc ici la
certitude de pouvoir fournir les dbits contractuels.
Dans cette approche, on dmontre dune part que mme le contrat
le plus bas dispose dune garantie, et dautre part que la valeur du
contrat reste modulable en fonction des besoins de chaque client.
Congurations des paramtres A et B
An de choisir la mthode de conguration des paramtres A et B,
nous tudions lvolution des CLA lors de lapparition dune conges-
tion dans notre exemple illustratif (section 9.4.1) avec des valeurs de
A et B gales 100 (g. 21). La gure 21 met en vidence que chaque
type de contrat dispose dune bande passante au prorata de sa HLA
et ce quelque soit la valeur de la HLA. Par contre, nous pouvons
observer que lquit est plus longue obtenir pour les contrats de
100Mb/s. An de palier cela, nous proposerons une valeur de A et B
au prorata (not ) du contrat HLA. Ainsi, une conguration de A et
B au 1/100 de la HLA donne le fonctionnement suivant (g. 22). Cette
modication permet lensemble des comportements des rgulateurs
dagir proportionnellement leurs propres HLA.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
60 modlisation du systme tdcn
Figure 21: Evolution de la CLA dun systme descente constante(en % de la HLA)
Figure 22: Evolution de la CLA dun systme descente variable(en % de la HLA)
9.5 conclusion du chapitre
Les travaux effectus sur un cas pratique, nous ont permis de mettre
en vidence un certain nombre davantages du systme. Cependant,
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
9.5 conclusion du chapitre 61
cette tude temporelle ne permet pas dacter les choix optimaux des
constantes ou de certier son bon fonctionnement systmique.
Nous pouvons observer que le systme fournit tout moment un
CLA suprieur au contrat minimum mme lors de la phase de conges-
tion.
Dans le chapitre suivant, nous proposerons une tude par dia-
gramme de phase. Celle-ci nous permettra de proposer et valider
des mthodes de choix pour les diverses constantes du systme.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
10
ETUDE PAR DI AGRAMME DE PHASE DE LI AI SON
TDCN EN CONGESTI ON
Ltude temporelle du systme nous a permis prcdemment diden-
tier diffrentes phases de fonctionnement. Dans ce chapitre, nous
allons approfondir ltude de lvolution de ltat du systme en g-
nrant des indicateurs. Ceux-ci serviront par la suite de base de com-
paraison pour tudier limpact de paramtres tels que ltablissement
des constantes, les conditions initiales, le nombre de rgulateurs, la
varit des contrats,...
10.1 etude dun systme simple deux rgulateurs
10.1.1 Dnition du systme
Dans un premier temps, nous considrons un systme ne compre-
nant que deux rgulateurs. Nous gnraliserons ensuite la mthode
pour des systmes comprenant plus de rgulateurs. Ltude que nous
nous proposons de faire se base sur la cration de diagramme de phase.
Dans un premier temps nous dnissons le vecteur dtat. Celui-ci sera
logiquement le vecteur de dimension 2 compos des valeurs des deux
CLA de chaque rgulateur. On notera de faon gnrale le vecteur
dtat
C. Nous tendrons, par la suite, la notation vectorielle en notant
le vecteur
L le vecteur des LLAs et les vecteurs
A et
B seront les para-
mtres des rgulateurs (nous considrons les rgulateurs fractionnels
dcrits dans le chapitre 9.1). On a donc :
C
_
CLA
0
CLA
1
_
,
L
_
LLA
0
LLA
1
_
,
A
_
A
0
A
1
_
,
B
_
B
0
B
1
_
(10.1)
10.1.2 Diagramme de phase
A laide de la modlisation ralise dans le chapitre prcdent, on
peut raliser le diagramme de phase du systme. La gure 23 est un
exemple de ces diagrammes.
Lvolution du systme met en vidence les trois phases observes
lors de ltude temporelle savoir :
63
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
64 etude par diagramme de phase de liaison tdcn en congestion
CLA2 en Kb/s
C
L
A
1
e
n
K
b
/
s
C0 =
60 Mb s
60 Mb s
, L =
10 Mb s
20 Mb s
, A =
100Kb s
100Kb s
, B =
1Mb s
1Mb s
, D= 80Mb/ s
Figure 23: Diagrammes de phases dun systme 2 rgulateurs
La premire phase (appele prcdemment phase de congestion)
caractrise par une chute de lensemble des valeurs des CLAs,
une seconde phase (dit dquilibrage) o les valeurs CLA varient
fortement mais o la somme des CLA oscille autour dune valeur
E (Valeur de coupure de la congestion cf. 9.2.1) ,
une dernire phase (dite quilibre) o lensemble des CLA converge
autour dun point xe. Celui tant dtermin en fonction du vec-
teur
L et de la valeur E (Dmontr dans 9.3.3 ).
10.1.3 Test dindpendance aux conditions initiales
La reprsentation en diagramme de phase nous a permis dobserver
les trois phases de la convergence. Cependant, celui-ci a t ralis pour
une condition initiale particulire. On peut dor et dj sinterroger sur
limpact de ces conditions.
An de contrler le fonctionnement du systme, nous ralisons
le diagramme de phase de systmes identiques mais possdant des
conditions initiales sur le CLA diffrentes.
Le rsultat de ce test (Figure 24) met en vidence dune part que
le point dquilibre est invariant et dautre part on remarque que la
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
10.2 gnralisation aux systmes n rgulateurs 65
CLA2 (Kb/s)
C
L
A
1
(
K
b
/
s
)
Figure 24: Diagrammes de phases dun systme 2 rgulateurs diffrentes condi-
tion initial
phase dquilibrage de tous les systmes se trouve tre une oscillation
autour dune droite unique ayant pour quation 10.2 :
C(0) +C(1) = E (10.2)
10.2 gnralisation aux systmes n rgulateurs
10.2.1 Cas du systme 3 rgulateurs
An dtendre les observations effectues dans le systme deux
rgulateurs, nous allons poursuivre ltude par un systme de degr
trois. Celui-ci est dni par les vecteurs de lquation 10.3 :
C
_
_
_
CLA
0
CLA
1
CLA
2
_
_
_
,
L
_
_
_
LLA
0
LLA
1
LLA
2
_
_
_
,
A
_
_
_
A
0
A
1
A
2
_
_
_
,
B
_
_
_
B
0
B
1
B
2
_
_
_
(10.3)
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
66 etude par diagramme de phase de liaison tdcn en congestion
C
1
C
2
C
3
C
i = D
Figure 25: Diagramme de phase de systmes 3 rgulateurs avec diffrentes condi-
tions initiales
Dans ce cas de gure (gure 25), on peut encore observer les trois
phases. De plus, on peut gnraliser lquation prcdente (equa. 10.2) :
n
i=0
CLA
i
= E
De la mme faon on peut vrier une nouvelle fois la vracit du
partage barycentrique ltat dquilibre.
10.2.2 Observation sur les systmes de dimension suprieure
Etude de la Notion de "distance"
Lobservation des diagrammes de phase ne peut tre effectue sur
les systmes de degrs suprieurs. Cependant, si nous connaissons la
valeur E, nous pouvons pr-calculer le point de convergence grce
lquation 9.10. A partir de l, nous pouvons dnir une fonction de
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
10.2 gnralisation aux systmes n rgulateurs 67
C
0
100Mb/ s
100Mb/ s
100Mb/ s
, L
10Mb/ s
20Mb/ s
30Mb/ s
, A
100b/ s
100b/ s
100b/ s
, B
100b/ s
100b/ s
100b/ s
, D= 80Mb/ s
Temps en secondes
D
i
s
t
a
n
c
e
e
n
K
b
/
s
Figure 26: Evolution de la distance de convergence dun systme
"distance" entre le point de fonctionnement observ au temps t et le
point de convergence. Cette fonction est dnie par lquation 10.4.
Distance(t) =
_
n
i=1
(C(t)
i
C
conv
i
)
2
(10.4)
Distance(t) =
_
n
i=1
(C
i
(t) E
LLA
i
n
i=1
LLA
i
)
2
(10.5)
Lintrt de cette fonction repose sur la possibilit de raliser un
graphique dvolution au cours du temps de tout systme quelque soit
sa dimension. Pour une reprsentation plus visuelle, nous effectuerons
un afchage logarithmique plus propice mettre en vidence les trois
phases du systme (gure 26).
traitement numrique et diagramme de synthse
An de faciliter les traitements numriques et la comprhension du
fonctionnement du systme tudi, nous effectuerons un lissage de la
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
68 etude par diagramme de phase de liaison tdcn en congestion
Dlai de convergence
Erreur de convergence
C
0
100Mb/ s
100Mb/ s
100Mb/ s
, L
10Mb/ s
20Mb/ s
30Mb/ s
, A
100b/ s
100b/ s
100b/ s
, B
100b/ s
100b/ s
100b/ s
, D= 80Mb/ s
Temps en seconde
D
i
s
t
a
n
c
e
e
n
k
b
/
s
Figure 27: Evolution de la distance fentre dun systme
courbe en ralisant une moyenne mobile. La courbe obtenue est alors
reprsentative dun systme dni par les paramtres L,A et B face
lvnement apparition dune congestion ayant pour dbit dquilibre
E avec comme condition initiale le vecteur tat instantan C
0
. Cette
courbe (gure 27) possde nalement deux caractristiques essentielles
pour notre systme :
Lerreur de convergence : reprsente par la distance entre laxe
et le minimum de la courbe.
Dlai de convergence : reprsent par le temps que le systme a
mis pour arriver 10% de son erreur de convergence minimale.
Par la suite, nous utiliserons ces indicateurs pour comparer lefca-
cit sur des systmes congurs diffremment.
10.3 analyse de liaison sur les systmes tdcn
10.3.1 Etude des effets des paramtres A et B
Lors de ltablissement dexemples, nous avons jusqu prsent
choisi les paramtres A et B de manire empirique. Grce aux rsultats
du chapitre prcdent, nous pouvons comparer lefcacit sur des
systmes congurs diffremment.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
10.3 analyse de liaison sur les systmes tdcn 69
A=100
A=500
A=1000
B=5
B=500
B=25
B=2500
B=50
B=5000
T
e
m
p
s
d
e
c
o
n
v
e
r
g
e
n
c
e
e
n
s
e
c
o
n
d
e
s
!
C
0
100Mb/ s
100Mb/ s
100Mb/ s
"
#
$
$
$
%
&
'
'
'
, L
10Mb/ s
20Mb/ s
30Mb/ s
"
#
$
$
$
%
&
'
'
'
, BW = 80Mb/ s
Figure 28: Evolution du systme en fonction des paramtres A et B
La gure 28 reprsente un systme identique avec des valeurs A et
B variantes. On peut constater que la prcision de la convergence est
directement corrle avec ces valeurs. Ainsi, plus A et B possdent
des valeur levs, plus le systme converge rapidement par contre
lerreur de convergence va galement crotre. On a donc un compromis
trouver pour la valeur du couple de paramtres A et B an dobtenir
une convergence satisfaisante dans un temps raisonnable.
10.3.2 Effet du nombre de rgulateurs
Un des questionnements que peut susciter notre systme est la
possibilit que possde une liaison de supporter un nombre variable
de rgulateurs. An dvaluer cette capacit, nous allons effectuer une
comparaison entre des liaisons de mme dbit mais possdant un
nombre N diffrent de rgulateurs. Pour pouvoir les comparer, nous
poserons les hypothses suivantes :
Dans un systme, tous les rgulateurs sont identiques (mme LLA,
mme HLA),
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
70 etude par diagramme de phase de liaison tdcn en congestion
Erreur
en Kb/s
Dlai
en sec
Degr du systme
Figure 29: Comparaison de systme quivalent de degr N
chaque systme dbutera la congestion avec son CLA gal son
HLA,
an de pouvoir comparer les systmes, la distance initiale entre le
point de convergence et le point de fonctionnement sera la mme
pour tous les systmes,
la somme des LLA sera la mme quelque soit le systme,
les valeurs de A et B seront proportionnelles au LLA,
la liaison considre aura un dbit identique quelque soit le sys-
tme.
De ces conditions on en dduit facilement les valeurs LLA, A, B en
fonction du nombre de rgulateurs N :
LLA
i
=
N
i=1
LLA
i
N
A
i
=
A
0
N
B
i
=
B
0
N
La valeur du CLA initiale peut galement tre dduite en fonction
de la distance initiale D
0
, de la bande passante W et de N :
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
10.4 conclusion du chapitre 71
D
2
0
=
N
_
CLAW
LLA
N
LLA
_
2
D
2
0
= N
_
CLA
W
N
_
2
CLA =
W
N
+
D
0
N
On peut alors comparer les performances de systmes degrs
diffrents. La gure 29 montre un exemple de la variation du nombre
de rgulateur sur une liaison de 1Gb/s avec une somme de LLA
500Mb/s et un facteur dunder-provisioning 1,1. On peut observer
que ce systme est capable de sadapter avec des performances compa-
rables indpendamment du nombre de rgulateurs (de 11 contrats
100Mb/s 550 contrats 2Mb/s).
10.3.3 Etude de la dispersion des CLAs
Lors de ltablissement des contrats, il est possible de provision-
ner une partie plus ou moins garantie de LLA. On peut se poser la
question limpact dune forte disparit entre les diffrents contrats.
An dvaluer les effets, une simulation est effectue sur une liaison
1Gb/s disposant de 50 contrats avec un taux dunder-provisioning
de 50% pour le non-garanti (2Gb/s non-garanti) et un facteur Over-
provisioning de 2 galement pour le garanti (500Mb/s garanti). An
de les comparer, nous tablissons laide dun gnrateur gaussien
diffrents CLA avec un cart-type dni. Nous avons simul ainsi
la congestion an dobserver le dlai de convergence. Nous avons
rpliqu ce test 50 fois an dobtenir le dlai moyen de convergence
en fonction de lcart-type. La gure 30 reprsente lvolution du dlai
de convergence en fonction de lcart-type des CLA des tunnels.
On remarque que plus il y a une dispersion importante du CLA plus
le systme met du temps converger. Cette observation nous conforte
dans le fait dutiliser des rapports HLA/LLA xe (chapitre 9.4.2).
10.4 conclusion du chapitre
Ce chapitre nous a permis de valider ltendu des systmes pos-
sibles. Nous avons pu montrer que pour un systme donn, les perfor-
mances attendues sont prdictibles et optimisables travers le choix
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
72 etude par diagramme de phase de liaison tdcn en congestion
Ecart-Type en b/s
D
l
a
i
e
n
s
e
c
o
n
d
e
s
Figure 30: Effet de la dispersion des CLA
des constantes. Les rsultats obtenus pourront tre utiliss pour dnir
des garanties contractuelles ainsi que des rgles de provisioning et de
topologies.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
Cinquime partie
ETUDE EXPRI MENTALE DU SYSTME
TDCN
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
11
PRSENTATI ON DE LA PLATE- FORME DE TESTS
Ltude thorique prcdente a mis en vidence de multiples intrts
mettre en oeuvre notre systme. Cependant, lensemble des rsultats
obtenus repose sur une modlisation thorique. Lors de ltablissement
du modle, nous avons d poser des hypothses et effectuer des
simplications. Dans le cadre de la validation du modle, nous avons
ralis une maquette an de vrier la pertinence des hypothses
prises. Dautre part son second objectif est dapporter des informations
sur la qualit de service qui na pas t modlise.
11.1 la plate-forme de tests
Gnrateurs de connexions TCP/
UDP
Client A Client B
Systme de Mtrologie/Asservissement
Rgulateurs
d'accs
Client C
Rgulateurs
d'accs
Figure 31: Schma du testbed
Lobjectif de la plate-forme est de retrouver lensemble minimal des
composants permettant la mise en oeuvre du systme TDCN. Lenvi-
ronnement dun WAN est mul an de retrouver les comportements
TDCN identique celui que lon aurait dans le cadre dun dploiement
de la technologie. On retrouvera galement les gnrateurs ncessaires
75
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
76 prsentation de la plate-forme de tests
ltablissement des ux reprsentatifs des agrgats rels. Enn la
maquette reposera galement sur la mise en place dun systme de
mtrologie le plus complet possible.
An dobserver le systme en phase de congestion, la maquette se
compose de trois routeurs : un point de congestion est alors cr sur
le routeur central an de simuler une saturation de coeur de rseau.
An de raliser cette congestion, nous effectuons une limitation du
dbit dmission sur linterface de sortie du routeur de coeur (limite
80Mb/s).
11.2 cration de lenvironnement de tests
11.2.1 le gnrateur dagrgats
Figure 32: Gnrateur de session NetworkTester
Le systme TDCN est conu pour tre dploy dans un rseau de
transport mutualis. An de retrouver les comportements de ux
clients et plus particulirement les proprits dlasticit des ux, nous
utilisons un gnrateur industriel de sessions TCP.
Lquipement utilis est un gnrateur NetworkTester de la socit
Agilent. Celui-ci permet dmuler des applications bases entre autre
sur TCP. Nous avons plus particulirement utilis ses capacits
muler des sessions clients/serveurs FTP. Notre but tait uniquement
de proter des capacits TCP et de contrler le nombre de connexions
TCP simultanes. Ce nombre de session tant lun des principaux
paramtres inuenant le partage de la bande passante, nous pouvons
ainsi tudier le comportement du systme TDCN dans diffrentes
conditions de rgimes.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
11.3 implmentation du systme tdcn 77
11.2.2 Lmulateur WAN
Lenvironnement dun rseau transport mutualis est bien diffrent
de celui retrouv dans un laboratoire. An de reproduire les effets
de cet environnement, nous utilisons un mulateur. Celui-ci a pour
principal objectif de recrer une latence dans le rseau an que les
comportements des sessions TCP soient plus reprsentatifs de la ralit.
Nous avons donc utilis un serveur Windows ddi disposant du
programme NetDisturb edit par Omnicor an de rhausser la latence
du rseau. Nos tests ont t effectus avec un dlai rseau de 20ms.
11.3 implmentation du systme tdcn
11.3.1 Les routeurs
Figure 33: Routeur 7450 ESS1
La ralisation de notre maquette a t effectue avec des routeurs de
coeurs Alcatel-Lucent. Le choix sest port sur lutilisation de routeurs
industriel dont nous connaissions parfaitement le dimensionnement
de la capacit de commutation ainsi que celle de ses diffrentes cartes
porteuses. Ces routeurs disposent galement dune stack MPLS com-
plte incluant la gestion des VPN. Ils possdent galement la capacit
pour les ports daccs au VPN de grer prs de 16000 les dattentes
diffrentes et autant de QoS daccs. Ce qui le rend particulirement
intressant pour notre systme qui prvoit lutilisation de rgulateur
ddi chaque tunnel.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
78 prsentation de la plate-forme de tests
11.3.2 Description de larchitecture VPN
PPVPN
P
O
R
T
S
D
P
PPVPN
D
e
M
u
x
D
e
M
u
x
S
D
P
S
A
P
P
O
R
T
S
A
P
Police d'accs
Police d'accs
Figure 34: Architecture Gnrique dun VPN
Dans le cadre de leur utilisation normale, les routeurs cloisonnent
leur clients dans des services VPN diffrents. Chaque service VPN (g.
34) de ces routeurs est compos de plusieurs lments :
Service Access Point (SAP) : Entit rattache un port ou un
VLAN daccs. On peut lui appliquer une politique particulire
de qualit de service.
Service Distribution Point (SDP) :Entre du tunnel MPLS . Il a
pour charge dmettre les paquets dans le rseau. Il peut possder
des rgles de ltrage spcique en fonction de la nature des ux.
Demux : Il rcupre les paquets des tunnels MPLS. Traite les
informations MPLS et les retourne dans le service PPVPN en
correspondance.
Sap-ingress policy : Police daccs des SAP. Rserve un espace
mmoire pour le SAP. Gre la colorie par le biais dun TRTCM
[17]. Le mme mcanisme existe galement en sortie de SAP (Sap-
egress policy).
Notre Systme TDCN utilisera cette architecture, un service TDCN
sera un VPN point point disposant de polices daccs spciques.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
11.3 implmentation du systme tdcn 79
11.3.3 Lemulateur TDCN
Etant donn que les routeurs ne supportent pas nativement notre
nouveau systme exprimental, nous avons t contraint dexternaliser
sur un serveur Linux les briques ncessaires la mise en oeuvre de
notre systme TDCN. Trois composants sont ajouts :
Des contrleurs de congestion dans les routeurs de coeur chargs
de dtecter une ventuelle congestion.
Un protocole de signalisation des congestions.
Des rgulateurs daccs dynamiques prenant en compte les infor-
mations transmises par le protocole de signalisation.
Pour ce faire, nous avons utilis des automates logiciels qui inter-
rogent et contrlent les routeurs sur un rseau de management ddi.
Ceux-ci rcuprent les informations et modient le comportement du
routeur par le biais du protocole SNMP. Ce fonctionnement entrane
toutefois une moins grande ractivit. Nous verrons par la suite quelle
peut tre limpact de cette mthode sur les rsultats.
Les contrleurs de congestion
Le contrleur de congestion est situ au niveau de chaque port
de coeur de rseau. Il contrle en permanence ltat des buffeurs. Il
retransmet ensuite linformation de cet tat toutes les secondes au
protocole de transport dinformation.
En thorie, il faut contrler ltat des buffeurs Egress de linterface
qui se rempliront dans le cadre de la congestion de la liaison mais
galement les buffeurs Ingress des interfaces qui eux se rempliront
lorsquune congestion du coeur de commutation apparat. Dans la
pratique, la capacit de commutation maximum de nos routeurs nest
pas sous dimensionne, et cette congestion ne peut pas apparatre.
Implmentation des DAR
An de raliser les DARs, nous avons utilis des TRTCMs [17] inclus
au niveau des Sap Ingress policy des routeurs. Nous avons ensuite
pilot via le protocole SNMP la valeur du PIR de celui-ci. Ainsi, le CLA
de notre systme correspond la valeur courante du PIR du TRTCM.
Le LLA est lui reprsent par le CIR du rgulateur.
En thorie, ces TRTCM devraient tre appliques au niveau de policy
appliqus sur les SDP. Cependant, cette conguration nest pas faisable
matriellement do sa mise en oeuvre sur le SAP. Cette modication
nentrane aucune consquence dans le cadre dun VPN point point.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
80 prsentation de la plate-forme de tests
Par contre, elle empcherait lutilisation de VPN multipoints. Dans le
cadre de lindustrialisation du procd, il conviendrait de disposer les
mcanismes sur le SDP.
Le protocole de transport dinformation
Lajout ou la modication dun protocole au niveau des routeurs
implique ncessairement un recodage de celui-ci. Aussi nous avons
choisi dmuler le comportement du protocole. Nous avons co-localis
les programmes des contrleurs de congestion et des DARs sur le
serveur GNU/Linux avec une transmission dinformations par le biais
de variables partages. Pour autant, les divers codes sont dsynchroni-
ss tout comme ils le seraient si leurs codes taient inclus dans leurs
routeurs respectifs.
11.3.4 Dfaut de lexternalisation du code
Figure 35: Variation du temps entre les passes algorithmiques
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
11.4 mtrologie de la plate-forme de tests 81
Du fait de lutilisation dun OS non temps rel et galement
cause des dlais sur le rseau de management, les DAR nagissent pas
toutes les secondes prcisment. La gure 35 montrent un exemple de
variation de dlai entre 2 passes de lalgorithme. Ces courbes devraient
en thorie tre des droites constantes 1 seconde. Cette variation serait
largement attnue si le code tait inclu directement dans les routeurs.
11.4 mtrologie de la plate-forme de tests
11.4.1 Mtrique du routeur
Le routeur dispose pour chacun des ports des informations sui-
vantes : compteurs doctets, de paquets et de drops. Ces compteurs
sont rafrachis toutes les secondes. Mais, il est galement possible de
connatre ltat des buffeurs des ports daccs et de coeurs (g. 36)
pour chaque le dattente.
Port de coeur de rseau
Etat du buffeur egress de la
classe de service BE
Figure 36: Commande show pool sur un routeur ESS1
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
82 prsentation de la plate-forme de tests
An de suivre lvolution de ces informations, des automates dinter-
rogations ont t raliss pour nous permettre de mesurer lvolution
de ces valeurs. Contrairement aux autres compteurs, linterrogation de
ltat des buffers prend entre 400 et 600ms et donne une information
sur un tat instantan.
La gure 37 est un exemple dvolution dun buffeur suite lappa-
rition dune congestion de coeur.
Figure 37: Evolution dun buffeur egress sur un port en coeur dun routeur dispo-
sant dune liaison congestionne
11.4.2 Le gnrateur de dbit
An de mesurer les performances des systmes mis en place, nous
avons utilis un gnrateur de trac N2X de la marque Agilent. Cet
quipement gnre des paquets IP auxquels il ajoute un timestamps
dhorloge dans la payload. A laide dun second port, il rcupre ces
paquets et peut ainsi mesurer la latence, la gigue, le taux de pertes, les
dsordonnancements, le tout avec une prcision de 7 picosecondes.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
11.4 mtrologie de la plate-forme de tests 83
Figure 38: Gnrateur de dbit N2X
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
12
TESTBED DU SYSTME TDCN
Le chapitre prcdent nous a permis dexposer le fonctionnement
de la plate-forme de test mettant en oeuvre lapproche TDCN. Dans
ce chapitre nous allons utiliser cette plate-forme pour valider la mo-
dlisation effectue et mesurer les performances rseaux du nouveau
systme.
12.1 comparaison entre les rsultats de la maquette et
de la modlisation
Courbes thoriques Courbes pratiques
Figure 39: Comparaison entre les rsultats sur la maquette et dans la modlisation
Ltablissement de la modlisation des chapitres prcdents a t
ralise sur la base des principes thoriques issue des mcanismes
mis en oeuvre. La complexit des ux rels et les simplications que
85
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
86 testbed du systme tdcn
nous avons d oprer pour tablir le modle, nous amnent vrier
ladquation entre notre approche thorique et une mise en oeuvre
pratique.
Pour ce faire, nous avons tudi lvolution des CLA des rgula-
teurs du systme TDCN dans le cadre de notre plate-forme de test ;
puis nous allons comparer ces rsultats face lestimation de cette
volution via la modlisation. Dans une premire approche, nous ne
nous focaliserons pas sur les dbits rels prsents dans chaque VPN
mais uniquement sur lvolution des rgulateurs. Nous positionnerons
simplement sufsamment de connexions TCP en concurrence pour
initier une congestion.
La gure 39 compare les rsultats thoriques et pratiques dans le
cadre de deux systmes paramtrs diffremment. On constate sur le
graphique que les rsultats de la modlisation, bien que plus lisss
que ceux mesurs en pratique, donnent une bonne estimation de
lvolution relle des CLA.
Ce lissage sexplique facilement par le fait que la modlisation
considre tort une action simultane de tous les rgulateurs. Leffet
de la dsynchronisation se traduit par une variation plus importante
des CLA. Par contre, le dlai dquilibrage est lgrement survalu
dans le cadre de la modlisation.
12.2 tude des flux
12.2.1 Fonctionnement en rgime tabli
Nous avons prcdemment valid le bon comportement des rgu-
lateurs. Nous allons maintenant nous attacher vrier lvolution
des ux rels inclus dans ces tunnels. Nous utiliserons pour ce faire le
systme de mtrologie dni dans le chapitre prcdent pour tudier
lvolution des dbits clients.
Lexemple prsent dans la gure 40 a t ralis sur la base de trois
tunnels TDCN dans lesquels chaque client utilise des connexions TCP
simultanes. Dans lexemple retenu, le premier client a t congur
pour excuter 30 connexions TCP simultanes. Les deux autres clients
ont t congurs pour excuter chacun cinq connexions TCP.
Dans une premire tape, Nous avons mesur lutilisation de la
bande passante pour chaque client dans un rseau classique Best-effort
sans mis en place de notre systme. Dans un second temps, nous avons
ritr les mmes mesures avec notre rseau TDCN.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
12.2 tude des flux 87
Client LLA: 8Mb/s
and 30 TCP connections
Client LLA: 16Mb/s
and 5 TCP connections
Client LLA: 8Mb/s
and 5 TCP connections
Best-effort Network TDCN Network
Figure 40: Evolution du trac client dans un rseau BE et TDCN
On peut remarquer que dans le rseau classique le partage est
effectu au prorata du nombre de connexions TCP. De nombreuses
tudes donnent aussi le mme type de rsultat [24], et dcrivent les
mcanismes de partage du rseau. Ils soulignent en particulier la
dpendance entre la notion de partage et la quantit de connexions
TCP.
Cette situation est particulirement gnante pour un oprateur,
puisque des clients disposant de contrats identiques ne pourront pas
revendiquer la mme bande passante. Un client dit "non-citoyen" pour-
rait dans certains cas de gure tre tent daugmenter virtuellement
son nombre de connexions TCP an de rcuprer plus de bande pas-
sante au dtriment des autres clients.
Le systme TDCN a justement t conu pour empcher la nature
des ux dinuer sur le partage de la bande passante. La gure 40 met
bien en vidence cette nouvelle indpendance aux ux. En outre, la
bande passante est partage proportionnellement au paramtrage des
LLA des rgulateurs. La gure 41 montre que tous les clients ont des
taux de LLA CLA identiques, ce qui signie que la bande passante
supplmentaire a t quitablement rpartie entre les diffrents clients,
indpendamment du nombre de connexions TCP.
Dans la pratique, les ux clients sont contraints individuellement
par les limitations donnes par les rgulateurs DAR. Il nexiste alors
aucune possibilit pour les clients de se substituer cette limite.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
88 testbed du systme tdcn
Client LLA:8Mb/s TCP : 30 connexions
Client LLA: 8Mb/s TCP : 5 connexions
Client LLA: 16Mb/s TCP : 5 connexions
Figure 41: Evolution du rapport LLA/CLA des rgulateurs dans le rseau TDCN
12.2.2 Etude en phase dquilibrage
Nous avons vu prcdemment par le biais de la modlisation que
notre systme possde une phase transitoire au niveau des rgulateurs.
Dans cette partie, nous focaliserons notre attention sur lvolution des
tracs clients durant cette priode. An de contrler lvolution lors de
cette phase, nous allons initier une congestion dans le coeur de rseau
en tablissant simultanment les tracs clients. La conguration mise
en oeuvre est reprise du test effectu dans le chapitre prcdent. Au
cours de lessai, nous avons tudi le dbit utilis pour chaque client
(gure 42). Dans le mme temps, lvolution des valeurs CLA a t
enregistre pour chaque rgulateur. (Figure 43).
A linitialisation de la congestion, nous observons que tous les
tracs se partagent la bande passante de la liaison. Ce partage de
bande passante est similaire celui qui aurait eu lieu dans un rseau
classique best-effort(voir gure 40).
Par la suite les rgulateurs vont agir face cette congestion en
durcissant leur politique daccs. Le trac, prcdemment le plus
favoris par le partage best-effort, sera le premier impact et devra
rduire son utilisation de la bande passante. Dans le mme temps,
la bande passante libre sera ralloue entre les autres clients qui
navaient pas atteint leurs limites.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
12.2 tude des flux 89
Client with 30 TCP connections
and LLA: 8Mb/s
Client with 5 TCP connections
and LLA: 16Mb/s
Client with 5 TCP connections
and LLA: 8Mb/s
Figure 42: Evolution du trac client en phase transitoire
Regulator with LLA: 16Mb/s
Regulator with LLA: 8Mb/s
Regulator with LLA: 8Mb/s
Figure 43: Evolution du CLA des clients en phase transitoire
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
90 testbed du systme tdcn
On constate galement que les ux TCP subissant le durcissement de
politique des DAR ne rompent pas leurs connexions et suivent la pente
donne par le rgulateur. Ce comportement est rendu possible car
lchelle de temps de la variation des rgulateurs est signicativement
suprieure celle des connexions TCP (facteur 100).
12.3 tude des performances globales
12.3.1 Evaluation des performances par client
Les rsultats prcdents ont mis en vidence la capacit de notre sys-
tme fournir une quit contractuelle lors dune priode de conges-
tion aprs une phase transitoire. Dans cette partie nous allons tudier
les performances qui dcoulent de ce fonctionnement dans un cas
extrme ou la garantie contractuelle est inversement proportionnelle
au nombre de connexions des ux clients.
Lexprimentation suivante se compose de sept tunnels TDCN mis
en concurrence, chaque client disposant dun nombre diffrent de
connexions TCP. Chaque connexion TCP effectue le tlchargement
dun chier de 5 Mo, une fois la connexion termine une nouvelle
connexion est rtablie (18 fois pour chaque connexion).
Nous mesurons le temps pour naliser lensemble des tlchar-
gements pour chaque client et nous calculons ainsi le dbit moyen
obtenu en pratique par client. Nous effectuons lexprience dans le
cadre dun rseau classique BE puis dans le cadre de notre proposition
darchitecture.
Les rsultats obtenus sont synthtiss dans le tableau 1. Ce test dure
quelques minutes. An dtudier lvolution plus long terme de
la performance, un deuxime test a t ralis, fond sur le mme
paramtrage except pour le nombre de tlchargements quon ritre
200 fois. Lexprience dure alors plus dune heure.
Nous pouvons observer dans le tableau 1, que tous les clients ne sont
pas en mesure de respecter le contrat minimum LLA. Ce phnomne
sexplique par le fait que pendant la phase de transition, le partage
de la bande-passante est effectu au pro-rata des connexions TCP. Il
sagit donc dun partage diamtralement oppos celui souhait dans
ce cas particulier. Toutefois, mme dans ce cas exagrment ngatif,
les rsultats sont bien meilleurs que pour le rseau Best-effort (le
client dispose dun dbit trois fois suprieur celui quil aurait eu en
Best-effort).
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
12.3 tude des performances globales 91
Table 1: Performance par client pour 18 tlchargements successifs
Customers LLA Concurrent
TCP
connec-
tions
Duration
TDCN
Average
TDCN
rate
Average
BE rate
1 14Mb/s 1 101 s 7,1Mb/s 2,4Mb/s
2 12Mb/s 2 132 s 10,9Mb/s 4,7Mb/s
3 10Mb/s 3 170 s 12,7Mb/s 7,1Mb/s
4 8Mb/s 4 210 s 13,7Mb/s 9,4Mb/s
5 6Mb/s 5 250 s 14,4Mb/s 11,8Mb/s
6 4Mb/s 6 280 s 15,4Mb/s 14,2Mb/s
7 2Mb/s 7 345 s 14,6Mb/s 16,5Mb/s
Table 2: Performance par client pour 200 tlchargements successifs
Customers LLA Concurrent
TCP
connec-
tions
Duration
TDCN
Average
TDCN
rate
Average
BE rate
1 14Mb/s 1 555 s 14,4Mb/s 2,4Mb/s
2 12Mb/s 2 1025 s 15,6Mb/s 4,8Mb/s
3 10Mb/s 3 1485 s 16,2Mb/s 7,2Mb/s
4 8Mb/s 4 2005 s 16,0Mb/s 9,4Mb/s
5 6Mb/s 5 2480 s 16,1Mb/s 12,1Mb/s
6 4Mb/s 6 3185 s 15,1Mb/s 14,5Mb/s
7 2Mb/s 7 3485 s 16,1Mb/s 16,9Mb/s
On peut remarquer galement que, mme sans tenir compte des
contraintes lie au LLA, six des sept clients ont un dbit moyen su-
prieur celui quils auraient obtenu dans un rseau Best Effort. Ce
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
92 testbed du systme tdcn
phnomne sexplique par le fait quune fois le tlchargement dun
client termin, la bande passante libre est redistribue aux clients
qui nont pas encore ni leurs tlchargements. Ainsi on peut consi-
drer que, si les demandes de bande passante dun client sont en
quantit nie, le systme nobre pas le rendement du rseau. Son
fonctionnement se traduit par un rordonnancement dans le temps
des demandes clientes.
Ce test met en avant un certain nombre davantages de notre sys-
tme :
Tout dabord, mme dans le cas le plus ngatif o le nombre de
connexions TCP est inversement proportionnel aux contrats du
client, le partage reste extrmement avantageux pour les contrats
les plus importants.
Si on considre que les demandes des clients ne sont pas innies,
les contrats les plus bas ne sont pas trop impacts.
12.3.2 Mesures des performances globales du systme
Nous allons utilis les rsultats des tests prcdents an dvaluer la
performance globale de notre rseau. En fait, un rseau parfait devrait
tre en mesure de transporter tous les tracs la bande passante du
goulot dtranglement. Le dlai le plus court pour effectuer lensemble
des tlchargements pourrait tre dtermin par la formule suivante :
Time
Perfect
=
18 (5MB/s 8) 28Connections
76Mb/s
= 265s (12.1)
Ainsi la performance globale du systme peut tre mesure par le
rapport entre le dlai pour terminer lensemble des tlchargements et
le dlai du systme parfait :
R
system
=
Time
Measure
Time
Perfect
(12.2)
Nous observons que le nouveau systme est moins efcace quun
rseau Best-effort principalement pour le premier jeu de donnes. La
cause principale de cette perte defcacit repose sur le dlai ncessaire
pour redistribuer la bande passante libre par un client. Le premier
test met en exergue ce phnomne. Nous pouvons voir un exemple
pratique de cet vnement sur la gure 44.
Dans cette exemple, les clients librent soudainement lensemble
de leur trac entranant ainsi une phase temporaire o lensemble
de la bande passante nest pas utilise dans le coeur du rseau. Ce
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
12.4 etude de la qualit de service 93
Bandwidth not use
Bandwidth use by clients
Global Bandwidth Use
Figure 44: Exemple de dlai pour rallouer la bande passante
phnomne dans le cas de ux agrgs na que trs peu de chance de
ce produire. Notre systme est donc mieux conu dans le cadre de
partage entre ux agrgs.
12.4 etude de la qualit de service
Nos tudes ont mis en vidence les capacits en terme de gestion
de la bande passante du systme. Cependant il reste analyser les
Table 3: Estimation de la performance global du systme
System Productivity
Best-Effort rst set 87%
TDCN rst set 77%
Best-Effort second set 89%
TDCN second set 85%
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
94 testbed du systme tdcn
Figure 45: Evolution du buffer dun rseau Best-effort en congestion
performances qualitatives des ux transports, plus particulirement
pendant la phase de congestion. Ces performances sont alors directe-
ment lies lvolution des buffers des routeurs.
12.4.1 tude de lvolution des buffers
Dans un rseau Best Effort standard, la priode de congestion en-
trane une bufferisation au niveau du goulot dtranglement (gure
45). Le niveau dencombrement du buffer dpend alors de diffrents
paramtres dont le prol des ux clients (nombres de connexions TCP,
dbit UDP,...), mais galement de certains paramtres des routeurs par
exemple le mcanisme RED [4],[25].
Dans notre rseau TDCN on peut noter que le prol de bufferisation
(gure 46)est trs diffrent. Dans la phase transitoire, on retrouve un
prol analogue celui quon observerait sur un rseau Best Effort avec
toutefois une diffrence notoire : les ux les plus agressifs subissent
une deuxime bufferisation (moins importante) dans le buffer daccs
du rgulateur. Cette seconde bufferisation est une consquence directe
du durcissement de la limite CLA.
Par contre, une fois la priode dquilibrage atteinte, le prol de
bufferisation change compltement. Vu du ux TCP, la bufferisation
bascule constamment entre une prsence en coeur de rseau et une
prsence au niveau du rgulateur du routeur daccs. Il sagit dun
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
12.4 etude de la qualit de service 95
Figure 46: Evolution of buffers in TDCN network
attribut trs intressant parce que la congestion prsente au niveau
du buffer daccs est bien moins consquente quen coeur. En fait, la
congestion prsente en coeur est due laggressivit de lensemble des
ux TCP passant sur le lien en congestion, par contre en accs seules
les connexions TCP du client participent lvolution du buffer. Ce
phnomne se traduit directement sur la latence des ux clients qui
est infrieure celle quelle aurait eu dans un rseau Best-effort. Notre
systme transforme ainsi une congestion de K clients en K congestions
rparties sur lensemble du rseau.
12.4.2 Effet du systme sur les tracs UDP
Jusqu prsent nos tudes se sont focalises sur des ux TCP. Dans
cette partie, nous contrlerons limpact sur les tracs UDP. Lvolution
de la charge des buffers dans le cadre de notre systme, entrane
diffrents effets sur le trac UDP.
Nous avons ralis un test en injectant un trac UDP instrument
avec le gnrateur N2X. Ce test a t effectu avec un trac UDP en
Constante Bite Rate (3750 fps avec des paquets de 100 octets) inject
dans chaque tunnel client. La gure 47 montre lvolution de la latence
et des pertes de paquets de ces tracs. Le systme est compos de trois
clients :
le premier dispose de 30 connexions TCP,
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
96 testbed du systme tdcn
les deux autres disposent de 5 connexions chacun.
C
o
n
g
e
s
t
i
o
n
p
e
r
i
o
d
S
t
a
b
i
l
i
z
a
t
i
o
n
p
e
r
i
o
d
C
A
B
Figure 47: Evolution de la latence et des pertes de paquets des ux UDP dans un
rseau TDCN
Nous observons sur la gure 47 trois phnomnes remarquables :
point A : Pendant la phase transitoire du systme, la latence des
ux UDP est la mme que celle qui aurait t obtenue dans un
rseau Best Effort. Dans notre exemple, cette latence est de 120
ms.
point B : Dans le mme temps, on observe des pertes sur les
paquets UDP. Ces pertes sont dues dune part au mcanisme
RED mis en place dans le coeur de rseau et dautre part au
durcissement de la politique daccs des rgulateurs DAR. A noter
que seuls les ux les plus agressifs subissent cette deuxime cause
(ici le client qui dispose de 30 connexions TCP).
point C : Durant la phase de stabilisation, du fait du passage tem-
poraire en congestion de coeur, la latence des ux UDP augmente
temporairement. On peut remarquer que cette augmentation de
latence se produit priodiquement et reste infrieure une buffe-
risation observe en congestion classique de coeur (25ms contre
120ms). Hors de cette priode, la latence est similaire celle dun
rseau non-congestionn.
Finalement, une fois la priode de stabilisation atteinte, notre sys-
tme dispose dune distribution de latence atypique car base sur deux
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
12.5 conclusion du chapitre 97
Figure 48: Distribution de la latence pour les ux UDP dans un rseau TDCN
bufferisations successives. En effet, loscillation entre la congestion de
coeur et daccs entrane une variation de la latence des paquets. La
gure 48 montre cette distribution de la latence. On peut noter que
cette gigue nentrane aucun dsordonnancement des paquets. Il est
par ailleurs possible de modier cette distribution en jouant sur les
paramtres de monte et de descente des rgulateurs. Par exemple, si
le paramtre de monte est beaucoup plus lent que celui de descente,
le systme restera en congestion daccs plus longtemps quen conges-
tion de coeur et donc nous aurons une latence globale plus faible. et
en tout cas infrieur celle une congestion de coeur.
12.5 conclusion du chapitre
La plate-forme de test nous a permis de confronter les rsultats
thoriques avec les mesures pratiques. Les doutes sur dventuelles
interactions entre la rgulation effectue par TCP et la sur-rgulation
TDCN ont ainsi pu tre levs. De plus, nous avons mis en vidence
de nouvelles proprits intressantes de notre systme comme par
exemple, le nouvel tat de quasi-congestion cr par le mcanisme
TDCN qui apporte une utilisation presque maximale de la bande
passante tout en conservant une latence trs faible.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
Sixime partie
CONCLUSI ON
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
13
CONCLUSI ON
Dans ce mmoire de thse, nous avons prsents nos travaux orients
sur la problmatique de mutualisation de ressources dans le cadre
de rseau doprateurs de transport mutualis. Cette problmatique
rsulte dune volont antagoniste de fournir dune part un maximum
de bande passante chaque client et dautre part de disposer dune
qualit et dune disponibilit maximales sur lensemble du rseau.
En effet, la demande de bande passante est en constante augmen-
tation. De plus lavnement des accs FTTH (Fiber To The Home)
pour lInternet, la 3G pour la tlphonie mobile, et de la vido haute
dnition entrane une pression supplmentaire sur les cots. Les
oprateurs cherchent alors en limiter les rpercutions sur les utili-
sateurs en optimisant leurs infrastructures. Les travaux de recherche
se focalisent alors sur loptimisation des coeurs de rseaux an den
limiter le surdimensionnement habituel.
Dans le cadre dune recherche de rponse cette problmatique,
nous avons tout dabord montr les possibilits offertes par les m-
thodes de provisioning. Celles-ci sattachent modier les chemins
des ux pour maximiser lutilisation du coeur de rseau. Malgr tout
ces approches reposent sur une vision macroscopique des ux. Dans
un second temps, nous avons tudi les approches historiques grant
le partage de la bande passante entre les session TCP. Celles-ci se
focalisent sur lobtention dune quit protocolaire entre les diverses
sessions. On peut parler dune vision microscopique des ux.
A partir de ces tudes, nous avons mis en vidence la ncessit de
transmettre la gestion de lquit des protocoles internes loprateur
de linfrastructure pour permettre une gestion plus approfondie du
provisioning rseau.
Nous avons ainsi tabli une nouvelle approche appele TDCN qui
permet de relier ces deux approches. Notre proposition a pour ob-
jectif de transmettre le partage de la bande passante au niveau des
paramtres des tunnels donnant ainsi le contrle de la congestion
loprateur de linfrastructure. Le design modulaire du systme per-
met de nombreux paramtrages en fonction de la politique de chaque
oprateur.
101
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
102 conclusion
Par le biais dune modlisation, nous avons dmontr le fonction-
nement du systme. Nous avons propos galement une mthode
permettant dvaluer lefcacit du mcanisme en fonction du para-
mtrage du systme. Nous avons tabli ainsi un sous-systme bas
sur la terminologie des contrats actuels doprateurs permettant une
industrialisation.
Une plate-forme de test a permis de valider notre modle en dmon-
trant le bon fonctionnement du systme propos dans un cadre rel
et en mettant en vidence les intrts majeurs en terme de qualit de
service.
Le systme a t tudi pour fournir une garantie de dbit pour un
service transitant au niveau dun AS. Des perspectives de recherche
apparaissent alors : il serait intressant dtudier la possibilit de four-
nir une qualit de service de bout en bout en protant des garanties
locales, limage des travaux qui furent raliss pour pouvoir fournir
une qualit Intserv en traversant des domaines Diffserv ([26]).
Dautre part, ltude par diagrammes dtats a mis en vidence une
phase dquilibrage caractristique. Il serait alors possible dacclrer
grandement celle-ci par le biais dune prdiction du point dquilibre.
On pourrait ainsi rajouter des informations de feed-back au niveau
protocolaire pour ainsi calculer une estimation de la prdiction du
point dquilibre.
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
Septime partie
ANNEXE
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
105
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
106 annexe
A
ANNEXE
a.1 code scilab de la modlisation tdcn
Listing A.1: Modelisation Scilab
function [CLA2]=tdcn(CLA,LLA,A,B,BW)
if sum(CLA)>=BW then
CLA2=CLA-A.
*
(CLA./LLA)
else
CLA2=CLA+B.
*
(LLA./CLA)
end
endfunction
function [POINT]=Calc
_
Convergence(LLA,D)
POINT=LLA/sum(LLA).
*
D;
endfunction
function [DIST]=distance(MATRICE,POINT)
Size=size(MATRICE);
MPTS=ones(Size(1),1)
*
POINT;
CARRE=(MATRICE-MPTS).^2;
DIST=sqrt(sum(CARRE, c ));
endfunction
function create
_
Trace(FILE
_
TRACE,M,N)
unix("rm "+ FILE
_
TRACE)
u=file( open,FILE
_
TRACE);
if M==0 then
write(u,CLA);
end
for i =1:N,
CLA=tdcn(CLA,LLA,A,B,BW);
if i>=M then
write(u,CLA);
end
end
file( close ,u);
endfunction
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
A.1 code scilab de la modlisation tdcn 107
Listing A.2: Fonction dafchage graphique
function Graph
_
Dist(MATRICE,DEBUT,POINT,COLOR)
xtitle("Distances au point de convergence a partir de t="+
string(DEBUT),"temps en seconde","Distance(en Kb/s ) ");
SIZE=size(MATRICE);
DISTANCES=distance(MATRICE(DEBUT:SIZE(1),:),POINT);
X=size(DISTANCES);
X=1:1:X(1);
plot2d (X,DISTANCES,style=COLOR);
endfunction
function Graph
_
Dist
_
log(MATRICE,DEBUT,POINT,COLOR)
SIZE=size(MATRICE)
DISTANCES=distance(MATRICE(DEBUT:SIZE(1),:),POINT);
X=size(DISTANCES);
X=1:1:X(1);
plot2d(X,DISTANCES,style=COLOR,logflag=" nl ");
endfunction
function [R]=fenetre(M,F);
Size=size(M);
for i =1:Size(1),
if i<F then
R(i)=sum(M(1:i))/i;
else
R(i)=sum(M((i-F+1):i))/F;
end
end
endfunction
function Graph
_
Dist
_
Moy
_
log(MATRICE,DEBUT,POINT,FEN,COLOR)
SIZE=size(MATRICE);
DISTANCES=distance(MATRICE(DEBUT:SIZE(1),:),POINT);
DIST
_
F=fenetre(DISTANCES,FEN);
X=size(DISTANCES);
X=1:1:X(1);
plot2d(X,DIST
_
F,style=COLOR,logflag=" nl ");
endfunction
function [REP]= normal
_
inv(DER,SUM,DEG)
MOY=SUM/DEG;
REP=grand(1,DEG-1, nor ,MOY,DER);
REP=[REP SUM-sum(REP)];
endfunction
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
108 annexe
Listing A.3: Fonction sur les diagrammes de phase
function Graph
_
phase(MATRICE,DEBUT,COLOR)
xtitle("Diagramme de phase a partir de t="+string(DEBUT),"CLA2
(en Kb/s ) ","CLA1(en Kb/s ) ");
plot2d(MATRICE(:,1),MATRICE(:,2),style=COLOR);
endfunction
function [R]=Espace
_
phase
_
G2(MATRICE,P,taille)
D=distance(MATRICE,P);
DF=fenetre(D,taille);
ERR=min(DF);
R=1.1
*
ERR;
i=1;
while DF(i)>R do i=i+1; end
TPS=i;
R =[ERR TPS];
endfunction
function [R]=Espace
_
phase
_
G(MATRICE,P)
D=distance(MATRICE,P);
ERR=min(D);
i=1;
while D(i)>ERR do i=i+1; end
TPS=i;
R =[ERR TPS];
endfunction
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
A.1 code scilab de la modlisation tdcn 109
Listing A.4: Diagramme de distance simple
CLA=[100000 100000 100000];
LLA=[30000 20000 10000];
A=[100 100 100];
B=[100 100 100];
BW=80000;
xbasc();
xtitle("Diagramme de Distance","Temps en sec","Distance en kb/s");
k=10;
n=1;
color=2;
WIN=20;
create
_
Trace( theorique . dat ,n,2500);
M=read( theorique . dat ,-1,3);
P=Calc
_
Convergence(LLA,BW);
Graph
_
Dist
_
log(M,n,P,color);
Graph
_
Dist
_
Moy
_
log(M,n,P,WIN,color+1);
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
110 annexe
Listing A.5: Etat du TDCN en fonction de A et B
CLA=[100000 100000 100000];
LLA=[10000 20000 30000];
BW=80000;
xbasc();
xtitle("Diagramme","Erreur de convergence en Kb/s","Delai de convergence
en seconde");
n=2;
Duree=2000;
for i = list(100,500,1000,2000),
m=1;
for j=i/20:i/10:5
*
i,
A=ones(1,3)
*
j;
B=ones(1,3)
*
i;
create
_
Trace( theorique . dat ,n,Duree);
M=read( theorique . dat ,-1,3);
P=Calc
_
Convergence(LLA,BW);
D=Espace
_
phase
_
G2(M,P,100);
if D(2)< (Duree-200) then
if D(1)<4000 then
if m>2 then
C=[C;D];
else
C=D;
m=m+1;
end
end
end
end
plot2d(C(:,1),C(:,2),style=n)
n=n+1;
clear C;
end
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
A.1 code scilab de la modlisation tdcn 111
Listing A.6: Etat du TDCN en fonction du degr
D0=100000;
C0=100000;
L0=500000;
A0=10000;
B0=10000;
BW=1000000;
xbasc();
n=1;
m=1;
h=1;
Duree=1100;
for i = 10:50:610,
m=m+1;
CLA=ones(1,i)
*
D0/sqrt(i)+BW/i;
LLA=ones(1,i)
*
L0/i;
A=ones(1,i)
*
A0/i;
B=ones(1,i)
*
B0/i;
create
_
Trace( theorique . dat ,n,Duree);
M=read( theorique . dat ,-1,i);
P=Calc
_
Convergence(LLA,BW);
D=Espace
_
phase
_
G2(M,P,300);
if D(1)<4000 then
if h>1 then
C=[C;i,D];
else
C=[i,D];
h=h+1;
end
end
end
xtitle("Erreur de convergence en fonction du degre ","degre du systeme",
"Delai de convergence en seconde");
plot2d(C(:,1),C(:,2),style=3);
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
112 annexe
Listing A.7: Etat du TDCN en fonction de la dispersion des
CLA
degre=50;
BW=1000000;
somhla=2000000;
somlla=500000;
LLA=ones(1,degre)
*
somlla/degre;
m=1;
h=2;
xbasc();
xtitle("Delai en fonction de l ecarttype","Ecarttype des CLAs en Kb/
s","Delai de convergenceen seconde");
for ecart =2000:1000:15000,
m=m+1;
clear D;
nb=1;
for rep =1:1:20,
CLA=normal
_
inv(ecart,somhla-somlla,degre)+LLA;
A=ones(1,degre)
*
somlla/degre/100;
B=ones(1,degre)
*
somlla/degre/100;
create
_
Trace( theorique . dat ,1,3000);
M=read( theorique . dat ,-1,degre);
P=Calc
_
Convergence(LLA,BW);
if isdef( D) then
E=Espace
_
phase
_
G2(M,P,100);
if E(1)<10000 then
D=(D.
*
nb+E)./(nb+1);
nb=nb+1;
end
else
E=Espace
_
phase
_
G2(M,P,100);
if E(1)<10000 then
D=E;
end
end
end
if h>2 then
C=[C;ecart,D];
else
C=[ecart,D];
h=h+1;
end
plot2d(C(:,1),C(:,3),style=3);
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
PUBLI CATI ONS
Les travaux raliss pendant ma thse ont donn lieu aux publica-
tions suivantes :
olivier ferveur. procd de gestion dun rseau de transmission de
type mpls. brevet franais dpos linpi le 28 avril 2008 sous
le n08 02392.
olivier ferveur, e. gnaedinger, f. lepage and r. kopp. proposi-
tion dune nouvelle rgulation daccs au coeur de rseau des oprateurs
dinfrastructure de communication. 5me confrence internationale
francophone dautomatique, cifa2008, roumanie (2008)
olivier ferveur, e. gnaedinger, f. lepage and r. kopp. new sha-
ring access regulation for cores network. 11th ieee singapore inter-
national conference on communication systems, iccs 2008, guangz-
hou (2008).
olivier ferveur, e. gnaedinger, f. lepage and r. kopp. new qua-
lity of service policy for wholesale approach. in process. ieee/acm tran-
sactions on networking.
113
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
BI BLI OGRAPHI E
[1] Network Working Group Praveen Muley Internet Draft Mustapha Ais-
saoui Expires : August 2008 Matthew Bocci Pranjal Kumar Dutta,
2009. (Cited on page 13.)
[2] Network Working Group Y. Kamite, Ed. Internet-Draft Y. Wada Ex-
pires : September 7, 2006 NTT Communications Y. Serbest AT&T,
2009. (Cited on page 14.)
[3] L. Andersson and T. Madsen. Provider Provisioned Virtual Private
Network (VPN) Terminology. RFC 4026 (Informational), March
2005. URL http://www.ietf.org/rfc/rfc4026.txt. (Cited on
page 14.)
[4] Guido Appenzeller, Isaac Keslassy, and Nick McKeown. Sizing
router buffers. SIGCOMM Comput. Commun. Rev., 34(4) :281292,
2004. (Cited on pages 40 and 94.)
[5] Ron Banner and Ariel Orda. Multipath routing algorithms for
congestion minimization. IEEE/ACM Trans. Netw., 15(2) :413424,
2007. ISSN 1063-6692. doi : http://dx.doi.org/10.1109/TNET.
2007.892850. (Cited on page 27.)
[6] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss.
An Architecture for Differentiated Service. RFC 2475 (Informatio-
nal), December 1998. URL http://www.ietf.org/rfc/rfc2475.
txt. Updated by RFC 3260. (Cited on page 30.)
[7] M. Bocci, I. Cowburn, and J. Guillet. Network high availability
for ethernet services using IP/MPLS networks. Communications
Magazine, IEEE, 46(3) :9096, 2008. (Cited on page 13.)
[8] A. Bosco, R. Mameli, E. Manconi, and F. Ubaldi. Edge distributed
admission control in MPLS networks. Communications Letters,
IEEE, 7(2) :8890, 2003. (Cited on page 27.)
[9] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Es-
trin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson,
115
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
116 bibliographie
K. Ramakrishnan, S. Shenker, J. Wroclawski, and L. Zhang. Re-
commendations on Queue Management and Congestion Avoi-
dance in the Internet. RFC 2309 (Informational), April 1998. URL
http://www.ietf.org/rfc/rfc2309.txt. (Cited on page 29.)
[10] B. Briscoe. Flow rate fairness : dismantling a religion. ACM
SIGCOMM Computer Communication Review, 37(2) :6374, 2007.
(Cited on page 34.)
[11] K. Chan, R. Sahita, S. Hahn, and K. McCloghrie. Differentiated
Services Quality of Service Policy Information Base. RFC 3317
(Informational), March 2003. URL http://www.ietf.org/rfc/
rfc3317.txt. (Cited on page 39.)
[12] C.N. Chuah. A Scalable Framework for IP-network Resource Pro-
visioning Through Aggregation and Hierarchical Control. Compu-
ter Science Division, University of California, 2001. (Cited on
page 25.)
[13] Clark D. and Wroclawski J. An Approach to Service Allocation in the
Internet. IETF Draft Report, Massachusetts Institute of Technology,
July 1997. (Cited on page 30.)
[14] J. de Rezende. Assured service evaluation. In IEEE Globecomm99,
Rio de Janeiro, Brazil, December 1999. URL citeseer.ist.psu.
edu/derezende99assured.html. (Cited on page 31.)
[15] C. Fraleigh, F. Tobagi, and C. Diot. Provisioning IP backbone
networks to support latency sensitive trafc. In INFOCOM 2003.
Twenty-Second Annual Joint Conference of the IEEE Computer and
Communications Societies. IEEE, volume 1, 2003. (Cited on page 26.)
[16] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, and A. Malis. A
Framework for IP Based Virtual Private Networks. RFC 2764
(Informational), February 2000. URL http://www.ietf.org/rfc/
rfc2764.txt. (Cited on page 14.)
[17] J. Heinanen and R. Guerin. A Two Rate Three Color Marker. RFC
2698 (Informational), September 1999. URL http://www.ietf.
org/rfc/rfc2698.txt. (Cited on pages 78 and 79.)
[18] T. Ikeda, S. Sampei, and N. Morinaga. TDMA-based adaptive
modulation with dynamic channel assignment forhigh-capacity
communication systems. Vehicular Technology, IEEE Transactions
on, 49(2) :404412, 2000. (Cited on pages 17 and 28.)
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
bibliographie 117
[19] Dina Katabi, Mark Handley, and Charlie Rohrs. Internet conges-
tion control for future high bandwidth-delay product environ-
ments. In SIGCOMM 02 : Proceedings of the 2002 conference on Ap-
plications, technologies, architectures, and protocols for computer com-
munications, pages 89102, New York, NY, USA, 2002. ACM. ISBN
1-58113-570-X. (Cited on page 32.)
[20] M. Kodialam and TV Lakshman. Dynamic routing of resto-
rable bandwidth-guaranteed tunnels using aggregated network
resource usage information. IEEE/ACM Transactions on Networ-
king (TON), 11(3) :399410, 2003. (Cited on page 27.)
[21] S. Khler and A. Binzenhfer. MPLS trafc engineering in OSPF
networks-a combined approach. In Proceedings of ITC, volume 18,
2003. (Cited on page 27.)
[22] K. Kompella and J. Lang. Procedures for Modifying the Resource
reSerVation Protocol (RSVP). RFC 3936 (Best Current Practice), Oc-
tober 2004. URL http://www.ietf.org/rfc/rfc3936.txt. (Cited
on page 40.)
[23] M. Lasserre and V. Kompella. Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP) Signaling. RFC 4762
(Proposed Standard), January 2007. URL http://www.ietf.org/
rfc/rfc4762.txt. (Cited on page 14.)
[24] Wei Lin, Rong Zheng, and Jennifer C. Hou. How to make as-
sured service more assured. In ICNP 99 : Proceedings of the Se-
venth Annual International Conference on Network Protocols, page
182, Washington, DC, USA, 1999. IEEE Computer Society. ISBN
0-7695-0412-4. (Cited on page 87.)
[25] Liu Zhen Malouch Naceur. Rr-4469 - performance evaluation of
rio routers. Technical report, INRIA, Juin 2002. (Cited on pages 31
and 94.)
[26] Zoubir Mammeri. Framework for parameter mapping to
provide end-to-end qos guarantees in intserv/diffserv ar-
chitectures. Computer Communications, 28(9) :1074 1092,
2005. ISSN 0140-3664. doi : DOI:10.1016/j.comcom.2005.01.
008. URL http://www.sciencedirect.com/science/article/
B6TYP-4FC8SSS-1/2/f444e082b7a1cf66757715f9988fc099. (Ci-
ted on page 102.)
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
118 bibliographie
[27] P. Marbach. Priority service and max-min fairness. In INFOCOM
2002. Twenty-First Annual Joint Conference of the IEEE Computer and
Communications Societies. Proceedings. IEEE, volume 1, 2002. (Cited
on page 30.)
[28] A. Markopoulou, G. Iannaccone, S. Bhattacharyya, C. Chuah, and
C Diot. Characterization of failures in an ip backbone. IEEE
INFOCOM, 2004. (Cited on page 27.)
[29] Petter Mosebekk. A linux implementation and analysis of the eXplicit
Control Protocol (XCP). PhD thesis, University of Oslo, May 2005.
(Cited on page 34.)
[30] K. Papagiannaki, R. Cruz, and C. Diot. Network performance
monitoring at small time scales. In Proceedings of the 3rd ACM SIG-
COMM conference on Internet measurement, pages 295300. ACM
New York, NY, USA, 2003. (Cited on page 26.)
[31] P. Pongpaibool. Characteristics of Internet Trafc in Thai-
land, 2006. URL http://internet.nectec.or.th/document/pdf/
20060329ECTI2006
_
panita.pdf. (Cited on page 26.)
[32] K. Ramakrishnan, S. Floyd, and D. Black. The Addition of Explicit
Congestion Notication (ECN) to IP. RFC 3168 (Proposed Stan-
dard), September 2001. URL http://www.ietf.org/rfc/rfc3168.
txt. (Cited on page 31.)
[33] N. Seddigh, B. Nandy, and P. Pieda. Bandwidth Assurance Issues
for TCP Flows in a Differentiated Services Network. IEEE Globe-
comm99, Rio de Janeiro, Brazil, 1999. URL citeseer.ist.psu.
edu/seddigh99bandwidth.html. (Cited on page 31.)
[34] P. Sousa, M. Rocha, M. Rio, and P. Cortez. Au-
tomatic provisioning of QoS aware OSPF congurations,
2007. URL http://repositorium.sdum.uminho.pt/dspace/
bitstream/1822/6619/1/jnw02020110
_
pns.pdf. (Cited on
page 26.)
[35] P. Tinnakornsrisuphap and AM Makowski. Limit behavior of
ECN/RED gateways under a large number of TCP ows. In
INFOCOM 2003. Twenty-Second Annual Joint Conference of the IEEE
Computer and Communications Societies. IEEE, volume 2. (Cited on
page 31.)
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9
bibliographie 119
[36] P. Trimintzios, I. Andrikopoulos, G. Pavlou, C. Cavalcanti, D. Go-
deris, Y. TJoens, P. Georgatsos, L. Georgiadis, D. Grifn, C. Jac-
quenet, et al. An Architectural Framework for Providing QoS in
IP Differentiated Services Networks. In 7th IFIP/IEEE Internatio-
nal Symposium on Integrated Network Management (IM 2001), 2001.
(Cited on page 25.)
[37] Christo Wilson, Chris Coakley, and Ben Y. Zhao. Fairness attacks
in the explicit control protocol. Quality of Service, 2007 Fifteenth
IEEE International Workshop on, pages 2128, June 2007. ISSN
1548-615X. (Cited on page 34.)
[38] O. Younis and S. Fahmy. Constraint-Based Routing in the Inter-
net : Basic Principles and Recent Research. IEEE Communications
Surveys and Tutorials, 5(1) :213, 2003. (Cited on page 27.)
t
e
l
-
0
0
4
1
8
0
2
6
,
v
e
r
s
i
o
n
1
-
1
7
S
e
p
2
0
0
9