1 / 31

DCCP-protocol de control al congestiei TCP cu datagrame

DCCP-protocol de control al congestiei TCP cu datagrame. Introducere DCCP . DCCP este un protocol care își propune a adăuga controlul congestiei la protocolul UDP S-a dorit obținerea unui protocol cu un antet cât mai mic, pentru a nu încărca prea mult rețeaua

matteo
Download Presentation

DCCP-protocol de control al congestiei TCP cu datagrame

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DCCP-protocol de control al congestiei TCP cu datagrame

  2. Introducere DCCP • DCCP este un protocol care își propune a adăuga controlul congestiei la protocolul UDP • S-a dorit obținerea unui protocol cu un antet cât mai mic, pentru a nu încărca prea mult rețeaua • Se dorește o anumită robustețe împotriva atacurilor

  3. Omisiuni • Controlul curgerii de informații : ar fi inutil într-un protocol bazat pe transmisie în timp real să se vorbească de retransmisie • Multicast : nu s-a găsit o metodă care să fie folosită pentru multicast

  4. Conexiunea • Conexiunea este făcută în 3 trepte • În acestă fază se negociază tipul de control al congestiei folosit • Închiderea conexiunii se face tot în 3 trepte

  5. Numere de secvență • Numărul de secvență este dat de numerotarea fiecărei datagrame, nu a fiecărui octet ca în cazul TCP • Din acest motiv e posibil uneori să existe confirmări la confirmări, pentru a se menține o sincronizare între sursă și destinație

  6. Confirmările • În cazul DCCP s-a inventat un nou tip de pachet, DCCP_DataAck, care adaugă la coada unui pachet de date, o confirmare • Acest lucru este posibil mulțumită împărțirii conexiunii clasice TCP în două semiconexiuni, fiecare putând negocia propriile opțiuni • Fiecare pachet DCCP este confirmat

  7. CCID 2 și CCID 3 • Opțiunile care sunt negociate la începutul fiecărei conexiuni sunt CCID (Control Congestion ID) • Acestea presupun tipul de control al congestiei (2 sau 3)

  8. CCID 2 (TCP-Like) • Primul algoritm de control al congestiei este TCP-Like și are la bază TCP SACK • Este conceput pentru schimbări bruște care pot apărea în cazul lățimii de bandă disponibilă • Marea diferență apare deoarece CCID 2 introduce și controlul congestiei aspupra confirmărilor

  9. CCID 3 (TFRC) • Pentru algoritmul TFRC este recomandat să se pornească de la TCP NewReno • CCID 3 este conceput pentru un control mai fin al ratei de transmisie • Algoritmul se bazează pe schimbarea ratei de transmisie, conform unor statistici primite de sursă de la destinație

  10. Obiectiv al lucrării • Ceea ce se dorește de la această lucrare este să se observe diferențele de performanțe între controlul congestiei aplicat de DCCP, cu cele doua CCID-uri ale sale și protocoalele TCP SACK și respectiv TCP NewReno • Programul folosit pentru simulări este Network Simulator 2.34, la care a trebuit să adaug un patch care să conțină protocolul DCCP, pentru că acesta nu este în dotarea standard a simulatorului

  11. Pentru a putea face simulările a trebuit să gândesc un script TCL prin care să pot simula o rețea de comunicații • Din rezultatele acestui script au fost scoase graficele care urmează să fie prezentate • Deoarece Network Simulator este doar un mediu de simulare a rețelelor, a trebuit să fac un script AWK, prin care am extras datele prezentate

  12. Date de intrare ale simulării • Cele 5 link-uri din mijloc au o bandă de 1 Mbit/s, celelalte 10 Mbit/s • Nodul din stânga sus transmite TCP, iar cel din stânga jos transmite DCCP • Nodul din dreapta sus recepționează TCP, cel din dreapta jos recepționează DCCP • Pachetele la intrare au o mărime de 500 biți

  13. Debit Total CCID 2/ TCP NewReno cu întârziere 5 ms • Pachete DCCP trimise :48844 • Pachete DCCP recepționate : 48725 • Pachete DCCP_Data recepționate : 30563 • Pachete DCCP_Ack recepționate : 16314 • Pachete DCCP_DataAck recepționate : 1824 • Pachete DCCP aruncate : 119 • Pachete TCP trimise :113960 • Pachete TCP recepționate : 113914 • Pachete TCP_data recepționate : 56968 • Pachete TCP_Ack recepționate : 56922 • Pachete TCP aruncate : 46

  14. Debit Total CCID 2/ TCP NewReno cu întârziere 10 ms • Pachete DCCP trimise :41360 • Pachete DCCP recepționate : 41236 • Pachete DCCP_Data recepționate : 25726 • Pachete DCCP_Ack recepționate : 13824 • Pachete DCCP_DataAck recepționate : 1662 • Pachete DCCP aruncate : 124 • Pachete TCP trimise :118254 • Pachete TCP recepționate : 118215 • Pachete TCP_data recepționate : 59115 • Pachete TCP_Ack recepționate : 59076 • Pachete TCP aruncate : 39

  15. Debit Total CCID 2/ TCP NewReno cu întârziere 15 ms • Pachete DCCP trimise :42366 • Pachete DCCP recepționate : 42249 • Pachete DCCP_Data recepționate : 26541 • Pachete DCCP_Ack recepționate : 14160 • Pachete DCCP_DataAck recepționate : 1524 • Pachete DCCP aruncate : 117 • Pachete TCP trimise :117094 • Pachete TCP recepționate : 117071 • Pachete TCP_data recepționate : 58535 • Pachete TCP_Ack recepționate : 58512 • Pachete TCP aruncate : 23

  16. După cum se poate se poate vedea din datele experimentale, TCP NewReno este mult mai agresiv decât TCP-Like • În ciuda faptului că lărțimea de bandă este inițial controlată de TCP-Like, acesta este foarte rapid surclasat de TCP NewReno • Se mai poate observa cum odată cu creșterea întârzierii, algoritmul folosit de DCCP este mai ineficient, acest lucru datorându-se proiectării DCCP de a se folosi în timp real

  17. Debit Total CCID 2/ TCP SACK cu întârziere 5 ms • Pachete DCCP trimise :89006 • Pachete DCCP recepționate : 88900 • Pachete DCCP_Data recepționate : 56482 • Pachete DCCP_Ack recepționate : 29616 • Pachete DCCP_DataAck recepționate : 2778 • Pachete DCCP aruncate : 106 • Pachete TCP trimise :155922 • Pachete TCP recepționate : 155868 • Pachete TCP_data recepționate : 77952 • Pachete TCP_Ack recepționate : 77892 • Pachete TCP aruncate : 54

  18. Debit Total CCID 2/ TCP SACK cu întârziere 10 ms • Pachete DCCP trimise :68976 • Pachete DCCP recepționate : 68871 • Pachete DCCP_Data recepționate : 43443 • Pachete DCCP_Ack recepționate : 23028 • Pachete DCCP_DataAck recepționate : 2376 • Pachete DCCP aruncate : 105 • Pachete TCP trimise :180048 • Pachete TCP recepționate : 180009 • Pachete TCP_data recepționate : 90015 • Pachete TCP_Ack recepționate : 89970 • Pachete TCP aruncate : 39

  19. Debit Total CCID 2/ TCP SACK cu întârziere 15 ms • Pachete DCCP trimise :40446 • Pachete DCCP recepționate : 40347 • Pachete DCCP_Data recepționate : 24825 • Pachete DCCP_Ack recepționate : 13692 • Pachete DCCP_DataAck recepționate : 1806 • Pachete DCCP aruncate : 99 • Pachete TCP trimise :215304 • Pachete TCP recepționate : 215289 • Pachete TCP_data recepționate : 107643 • Pachete TCP_Ack recepționate : 107622 • Pachete TCP aruncate : 15

  20. După cum se poate vedea există o asemănare între TCP SACK și TCP-Like, în principal din cauza provenienței celui de-al doilea din primul • Și aici se poate vedea o performanță scăzută a CCID 2 direct proporțional cu creșterea întârzierii

  21. Debit Total CCID 3/ TCP NewReno cu întârziere 5 ms • Pachete DCCP trimise :33618 • Pachete DCCP recepționate : 33597 • Pachete DCCP_Data recepționate : 29685 • Pachete DCCP_Ack recepționate : 1962 • Pachete DCCP_DataAck recepționate : 1926 • Pachete DCCP aruncate : 21 • Pachete TCP trimise :113942 • Pachete TCP recepționate : 113911 • Pachete TCP_data recepționate : 56959 • Pachete TCP_Ack recepționate : 56928 • Pachete TCP aruncate : 31

  22. Debit Total CCID 3/ TCP NewReno cu întârziere 10 ms • Pachete DCCP trimise :29674 • Pachete DCCP recepționate : 29663 • Pachete DCCP_Data recepționate : 26056 • Pachete DCCP_Ack recepționate : 1812 • Pachete DCCP_DataAck recepționate : 1771 • Pachete DCCP aruncate : 11 • Pachete TCP trimise :116826 • Pachete TCP recepționate : 116799 • Pachete TCP_data recepționate : 58401 • Pachete TCP_Ack recepționate : 58374 • Pachete TCP aruncate : 27

  23. Debit Total CCID 3/ TCP NewReno cu întârziere 15 ms • Pachete DCCP trimise :26734 • Pachete DCCP recepționate : 26723 • Pachete DCCP_Data recepționate : 23464 • Pachete DCCP_Ack recepționate : 1638 • Pachete DCCP_DataAck recepționate : 1608 • Pachete DCCP aruncate : 11 • Pachete TCP trimise :119566 • Pachete TCP recepționate : 119543 • Pachete TCP_data recepționate : 59776 • Pachete TCP_Ack recepționate : 59754 • Pachete TCP aruncate : 23

  24. Conform datelor experimentale CCID 3 (TFRC) se comportă conform așteptărilor, adică are o creștere lină și sigură, ajungând până la urmă să împartă egal lățimea de bandă cu TCP NewReno • Se poate observa pe figuri cum mărirea întârzierii este în favoarea protocolului TCP NewReno

  25. Debit Total CCID 3/ TCP SACK cu întârziere 5 ms • Pachete DCCP trimise :64774 • Pachete DCCP recepționate : 64748 • Pachete DCCP_Data recepționate : 59280 • Pachete DCCP_Ack recepționate : 2748 • Pachete DCCP_DataAck recepționate : 2696 • Pachete DCCP aruncate : 26 • Pachete TCP trimise :150046 • Pachete TCP recepționate : 150008 • Pachete TCP_data recepționate : 75014 • Pachete TCP_Ack recepționate : 74970 • Pachete TCP aruncate : 38

  26. Debit Total CCID 3/ TCP SACK cu întârziere 10 ms • Pachete DCCP trimise :56000 • Pachete DCCP recepționate : 55993 • Pachete DCCP_Data recepționate : 51271 • Pachete DCCP_Ack recepționate : 2364 • Pachete DCCP_DataAck recepționate : 2334 • Pachete DCCP aruncate : 7 • Pachete TCP trimise :165028 • Pachete TCP recepționate : 165005 • Pachete TCP_data recepționate : 82505 • Pachete TCP_Ack recepționate : 82476 • Pachete TCP aruncate : 23

  27. Debit Total CCID 3/ TCP SACK cu întârziere 15 ms • Pachete DCCP trimise :53266 • Pachete DCCP recepționate : 53258 • Pachete DCCP_Data recepționate : 49046 • Pachete DCCP_Ack recepționate : 2106 • Pachete DCCP_DataAck recepționate : 2082 • Pachete DCCP aruncate : 8 • Pachete TCP trimise :169254 • Pachete TCP recepționate : 169236 • Pachete TCP_data recepționate : 84618 • Pachete TCP_Ack recepționate : 84594 • Pachete TCP aruncate : 18

  28. Conform datelor în comparație cu TCP SACK, TFRC are o creștere mult mai rapidă, ajungând după 55 de secunde să controleze majoritatea lățimii de bandă, în defavoarea TCP SACK • Se observă că timpul la care cele două protocoale ajung să împartă egal lățimea de bandă crește direct proporțional cu creșterea întârzierii

  29. Concluzii • Se poate spune că ce s-a dorit la proiectarea acestui protocol s-a obținut, deoarece simulările arată că încărcarea liniei cerută de DCCP este net inferioară celei cerute de TCP • Procentul mic de pachete pierdute arată că este o îmbunătățire evidentă față de UDP

  30. Cu toate acestea se observă că protocolul TCP este mult mai agresiv decât DCCP, ceea ce ar putea crea unele probleme ultimului în cazul în care necesită o lățime de bandă mai mare • În concluzie, cu ceva îmbunătpțiri, DCCP ar putea deveni un protocol de bază la nivelul 4 al stivei OSI

  31. VĂ MULȚUMESC!

More Related