Conclusion

Au cours de ce chapitre ont été présentées les interrogations qui ont mené à la réalisation du banc

d’essai sur lequel la quasi-totalité des expériences a été effectuée.

S’il reste difficile de pouvoir proposer des tests suffisamment exhaustifs, le choix de conditions réelles,

dans des environnements suffisamment variés permet d’atteindre de bons niveaux de certitude dans

les résultats, et de pouvoir comparer un grand nombre de solutions différentes.

Ainsi, les seuls inconvénients des solutions basées sur des machines réelles sont le coût financier, la

quantité de travail, et la reproductibilité des expériences. Toutefois, nous avons pu voir qu’avec des

moyens limités (et accessibles à un grand nombre de laboratoires d’informatiques), il était possible de

réduire leur importance notamment au travers d’une solution “clé en main” qui permet de répliquer

l’expérience avec un minimum de configuration.

L’étape suivante vise à la mise en place d’images directement déployables, ainsi qu’une configuration

réseau automatique. Ce faisant, les expériences pourront être reproduites avec une simplicité se

rapprochant des simulateurs.

Chapitre 4

Dynamiques de connexions TCP

antiparallèles sur un lien asymétrique

People assume that time is a strict progression of cause to effect, but *actually* from a non-linear, non-subjective viewpoint - it’s more like a big ball of wibbly wobbly... time-y wimey... stuff.

The Doctor – Doctor Who

Introduction

Lorsque deux connexions TCP antiparallèles — deux connexions qui émettent des données dans

des directions opposées en partageant les mêmes goulots d’étranglement dans chaque direction —

partagent un goulot d’étranglement asymétrique (lien ADSL, 3/4G, etc.), leurs dynamiques sont

profondément changées par rapport au cas de connexions symétriques. En effet, sur un lien chargé

ainsi dans les deux sens, on observe des oscillations parfois brutales de l’occupation des files d’attente

à chacune de ses extrémités. Ces variations ne peuvent s’expliquer uniquement par les pertes par

débordement et la diminution des fenêtres de congestion.

De plus, les deux tampons (montant et descendant) du goulot d’étranglement sont très rarement

occupés simultanément. Les paquets de données et les accusés de réception oscillent donc entre les

deux tampons, les remplissant alternativement, de manière similaire à un balancier. Ce phénomène

est appelébalancier de données, et le déversement des données d’un tampon à l’autrebascule.

Plusieurs auteurs ont étudié les effets du trafic sur la voie de retour d’un lien asymétrique sur les

performances de TCP et de nombreuses solutions ont été proposées, en cœur de réseau comme de

bout-en-bout [83, 84, 85]. Toutefois, les phénomènes observés sont habituellement expliqués par la

compression des ACKs (ACK compression) [86, 87]. D’autres études [88] évoquent le principe de

bascule de manière incomplète.

Ce chapitre se focalise sur les causes de ces baisses de performances, et présente un modèle de

l’occupation des files au cours du temps qui clarifie les interactions entre upload et download. Ce

modèle procure une explication des phénomènes observés plus convaincante que la compression des

accusés de réception. De plus, l’analyse apporte de nouveaux éléments aux études précédentes [88]

qui affirment que la congestion reste du même côté du lien jusqu’au débordement du tampon, ce qui

n’est pas toujours le cas, en particulier dans les réseaux asymétriques. Enfin, l’application du modèle

permet de prédire avec une bonne précision les débits relatifs de l’upload et dudownload dans une

configuration donnée.

Les trois contributions suivantes apparaissent dans ce chapitre :

Tout d’abord, ce chapitre raffine le modèle de Heusse et al, en élucidant pour la première fois ce

qui gouverne de quel côté la file d’attente se remplit. Cette formule permet en outre de prédire avec

exactitude les bascules indépendantes d’une perte.

Le résultat de ces analyses est ensuite injecté dans un modèle complet des dynamiques de flux TCP.

Celui-ci capture le comportement de deux connexions à l’échelle du flux de données afin d’attester

de l’impact du balancier sur les performances. L’étude des résultats remet notamment en cause

l’influence de la compression des ACKs, qui était jusque-là soit négligée [89], soit considérée comme

responsable des débits réduits observés pour le téléchargement.

Enfin, les files en cœur de réseau sont souvent dimensionnées en paquets et non en octets, ce qui

diminue en partie l’effet nocif du balancier. La dernière section de ce chapitre traite des modifications

à appliquer au modèle afin de pouvoir s’adapter à ce type de scénarios, plus proche de situations

réelles.

4.1 De quel côté la file d’attente se remplit-elle ?

Table 4.1: Notations

qx Données dans la file (octets) Qx Taille de la file (octets)

Cx Capacité du lien au niveau TCP (octets/s) Xx Débit (octets/s)

wx Fenêtre de congestion (octets)

w?

x Quantité de données non acquittées en attente dans les files du réseau. (octets) τx Temps d’aller-retour lorsque les tampons sont vides (s)

RTT^? Partie du délai due aux données dans les tampons, hors temps de propagation (s)

Lorsqu’une file commence à se construire d’un côté d’un lien asymétrique, le temps d’aller-retour

augmente, ce qui affecte les flux de données dans les deux sens.

La file se remplit du côté de la connexion la plus exigeante en ressources. Par exemple, à la suite

d’une perte sur le lien descendant, l’upload a une fenêtre de congestion plus grande que ledownload,

et le tampon montant commence à se remplir. Le système reste dans cet état jusqu’à ce que le

tampon déborde et qu’éventuellement la situation s’inverse.

Pour occuper un tampon en permanence, une connexion TCP doit atteindre une fenêtre de congestion

w

_x

supérieure àC

_x

×τ

_x

, le produit délai bande passante du réseau entre l’émetteur et le récepteur.

La part dew

_x

qui excède ce produit occupe inévitablement le tampon du goulot d’étranglement à

moins que l’occupation de la file du chemin de retour n’augmente le RTT (et donc le produit délai

bande passante effectif du système).

Soitw

?

la quantité de données sur le réseau qui n’est pas en train de se propager sur les liens pour

une connexion données (cf.notations en Table 4.1 – quantités en octets et capacités en octets/s) :

w

^?_x

=w

x

−C

x

×τ

x

,

oùxcorrespond soit audownloadou à l’upload, etτ

x

est le temps d’aller-retour lorsque les files sont

vides.w

^?_x

représente donc la quantité de donnée stockée dans les tampons montant et descendant du

lien. Ainsi, si la file du lien descendant n’est pas vide, elle retarde les ACKs de l’upload d’une durée

q

_d

C

d

qui représente ^q

^d

C

d

C

u

octets en vol. Inversement, si la file du lien montant se remplit, les ACKs

dudownload sont retardés de ^q

^u

C

_u

^{, soit}

q

u

C

_u

^C

^d

^{octets en vol.}

w

^?_u

=q

_u

+ ^q

^d

C

d

C

_u

. (4.1)

De même :

w

^?_d

=q

d

+ ^q

^u

C

u

C

d

. (4.2)

Enfin, la portion du RTT due au temps passé dans les files est égale à :

RTT

^?

= ^q

^u

C

_u

⁺

q

d

C

_d

^(4.3)

Cette équation combinée aux équations 4.1 et 4.2 montre que soit :

1. Les deux files sont occupées et

w

^?_u

C

u

=^w

? d

C

d

; (4.4)

2. q

_d

= 0, donc l’équation 4.2 n’est plus vérifiée car le téléchargement ne sature plus le lien. En

conséquence,w

?

u

=q

_u

;

3. de même,q

_u

= 0, doncw

?

d

=q

_d

.

En conclusion, un seul tampon peut être occupé pour une durée significative, sauf lorsque l’équation

4.4 est vérifiée. Ceci ne peut arriver que pour une durée limitée, ou dans le cas d’un lien parfaitement

symétrique (ce qui est souvent la configuration par défaut des simulateurs). Dans d’autres cas —

scénarios plus réalistes —dès que l’équation 4.4 est vraie, les données en vol commencent à

basculer d’un tampon à un autre. De plus, lorsque ^w

?

u

C

_u

^<

w

?

d

C

_d

^{, le tampon descendant se remplit}

et vice versa (Notons que cette condition diffère de celle donnée dans l’article de Collange [88] qui

n’est valide que pour un lien symétrique)

Dans le document TCP sur lien asymétrique : analyse des phénomènes et étude de solutions de faible empreinte mémoire ou de bout-en-bout (Page 52-57)