Presentation de l'article : Taming TCP incast throughput collapse in data center networks - French

1. Analyse de l’article
Taming TCP Incast
Throughput Collapse in
Datacenter Networks
Réalisé par:
Wiem Louhichi
Le 15/12/2016

2. Plan
1. Identification de l’article
2. Introduction
3. Présentation de contexte
4. Etude de l’article
5. Conclusion

3. Plan
1. Identification de l’article
2. Introduction
3. Présentation de contexte
4. Etude de l’article
5. Conclusion

4. 1.Identification de l’article
Il s’agit d’un article scientifique
Les auteurs de cet article sont:
★ Jiao Zhang
★ Fengyuan Ren
★ Li Tang
★ Chuang Lin

5. Plan
1. Identification de l’article
2. Introduction
3. Présentation de contexte
4. Etude de l’article
5. Conclusion

6. 2.Introduction
Problématique:
Problème d'incast TCP: se produit lorsque plusieurs expéditeurs transmettent
de manière synchrone des bandes à un seul récepteur dans des datacenters
avec une bande passante élevée et un faible temps d’aller-retour (RTT).
Objectifs:
Resoudre le probleme d’incast TCP.

7. Plan
1. Identification de l’article
2. Introduction
3. Présentation de contexte
4. Etude de l’article
5. Conclusion

8. 3.Présentation de contexte
Incast est un modèle de communication plusieurs a un qui se trouve
couramment dans les centres de données en nuage mettant en œuvre des
systèmes de stockage et de calculs distribués à échelle réduite tels que
Hadoop, MapReduce, HDFS, Cassandra, etc. - alimentant des applications
telles que la recherche sur le Web, les cartes, les réseaux sociaux, les données
Entreposage et analyse.

9. Plan
1. Identification de l’article
2. Introduction
3. Présentation de contexte
4. Etude de l’article
5. Conclusion

10. 4.Etude de l’article
Les causes de TCP Incast Problem:
En examinant beaucoup de données de simulation et expérimentales, nous
avons révélé que deux catégories principales de TOs conduisent au problème
d'incast TCP:
LAck-TO: est causé par des insuffisants paquets pour la récupération pilotée
par données à la queue des unités de rayures.
FLoss-TO: est induite par la perte de fenêtre complète lorsque l'éclatement
du trafic est trop important au début d'une unité à rayures.

11. 4.Etude de l’article
Solutions existantes:
Essayer avec différentes versions TCP.
Activer la transmission limitée.
Réduire le seuil ACK dupliqué
Disable TCP slow start

12. 4.Etude de l’article
Solutions proposées:
Réduire le RTOmin
ICTCP: qui contrôle le débit par adaptatif en ajustant l'awnd (Advertised
Window) côté récepteur.
D3 et PDQ: fournissent contrôle de la transmission par un contrôle de débit
explicite aux émulant des mécanismes de planification préventive,
respectivement.

13. 4.Etude de l’article
TCP avec GIP:
Surmonter le LAck-TOs:
On doit s'assurer que tous les trois derniers paquets atteignent le récepteur
avant le TOs
Une fois que l'un des trois derniers paquets est abandonné, l'expéditeur doit
entrer dans la période FR / FR (fast retarnsmission/ fast recovery)
Cependant, TCP peut ne pas saisir la période FR / FR sans suffisamment
d'ACK.

14. 4.Etude de l’article
TCP avec GIP:
Surmonter le LAck-TOs:
Un moyen simple consiste à insérer plusieurs paquets à la queue d'une
stripe unit pour générer plus de ACK.
Transmet de manière redondante certains des trois derniers paquets non
quelques soient perdus avant leur TOs.
Cette méthode peut non seulement générer plus d'ACK mais aussi
améliorer la probabilité que les trois derniers paquets
atteint le récepteur avant que LAck-TOs ne se produise

15. 4.Etude de l’article
TCP avec GIP:
Surmonter le FLoss-TOs:
Une méthode simple consiste à réduire le cwnd initial de chaque flux au
début de chaque stripe unit.
La valeur doit être suffisamment petite pour que le Tampon peut accueillir
la plupart des paquets dans le premier période RTT.
La fenêtre de congestion de chaque flux doit être identique que chaque flux
peut partager équitablement la bande passante.
Par conséquent, dans GIP, tous les flux partent de la phase de
démarrage lent au début de chaque stripe unit pour éviter les FLoss-TOs.

16. 4.Etude de l’article
Implementation:
1. Notification les stripe units des limites
La couche application définit le 16ème bit de drapeaux (c'est-à-dire flags =
0x10000) lors de l'appel de send() pour notifier à la couche TCP que le bloc de
données en buf est la queue de l'unité de stripe courante.

17. 4.Etude de l’article
Implementation:
2. Transmissions redondantes à la queue des stripe units
Si le 16 ème bit des indicateurs est 1, la couche TCP sait que le bloc de données fourni par la couche
d'application est la queue de stripe unit courante.
TCP retransmet le dernier paquet une fois s'il reçoit un nouvel ACK qui n'est pas pour le dernier
paquet. Ce processus se répète au maximum 3 fois et mis en œuvre dans la fonction de
Tcp_rcv_established ().
Si conditions de retransmission du dernier paquet satisfaire, TCP appelle tcp_retransmit_skb () pour
transmettre de manière redondante le dernier paquet. Une variable est ajoutée pour contrôler le
nombre de transmissions redondantes.

18. 4.Etude de l’article
Implementation:
3. Réduction de la fenêtre de congestion à la tête des stripe units
Cette partie est mise en œuvre dans la fonction de tcp_sendmsg ().
La tête d'une unité à bandes peut être connue naturellement puisque le 16ème bit des drapeaux est
utilisé pour indiquer le queue de la dernière unité à rayures.
Puisque chaque appel de Tcp_retransmit_skb () augmente tp-> retrans_out par 1, la valeur de
tcp_packets_in_flight () sera supérieure à cwnd après la transmission de plusieurs unités de bandes, qui
empêche TCP d'envoyer des paquets.
Ainsi, nous réinitialisons Tp-> retrans_out à 0 au début de chaque stripe unit.

19. 4.Etude de l’article
Implementation:

20. 4.Etude de l’article
Simulation:
En pratique, la bande passante peut être de 10 Gbit / s ou même supérieure
Et un travail peut impliquer des centaines de serveurs.
Pour évaluer la performance de TCP avec GIP avec capacité goulot
d'étranglement plus élevé ou un plus grand nombre d'expéditeurs, ils ont utilisé
la plate-forme ns-2 et de comparer ses performances avec les deux TCP
NewReno et RTOmin = 2 ms

21. 4.Etude de l’article
Simulation:

22. Plan
1. Identification de l’article
2. Introduction
3. Présentation de contexte
4. Etude de l’article
5. Conclusion

23. 5.Conclusion
Dans cet article, un mécanisme amélioré, GIP, est conçu et mis en œuvre pour
résoudre le problème d'encapsulation TCP.
Les résultats expérimentaux valident que le GIP puisse résoudre
correctement le problème des Coût. De plus, nous réalisons des séries de
simulations sur le ns-2 pour évaluer la performance de la GIP avec une bande
passante du goulot d'étranglement et un plus grand nombre d'expéditeurs.
Les résultats de simulation démontrent qu'il a une bonne évolutivité.