1 / 33

Notiuni privind calitatea serviciului in Internet

Notiuni privind calitatea serviciului in Internet. Calitatea serviciului in retele. Calitatea serviciului (Quality of Service, cu acronimul QoS) inseamna ca utilizatorilor li se garanteaza ca anumite cerinte de calitate le vor fi satisfacute de retea.

jafari
Download Presentation

Notiuni privind calitatea serviciului in Internet

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. Notiuni privind calitatea serviciului in Internet

  2. Calitatea serviciului in retele • Calitatea serviciului (Quality of Service, cu acronimul QoS) inseamna ca utilizatorilor li se garanteaza ca anumite cerinte de calitate le vor fi satisfacute de retea. • Aceste cerinte se exprima de obicei prin parametri masurabili: • Intirzierea datelor (delay) • Variatii ale intirzierii datelor, numita jitter • Jitter-ul e important in aplicatii de streaming • Capacitatea de trecere (throughput) • Fiabilitate (procent de date pierdute, receptionate eronat, intr-o ordine gresita, duplicate, etc). • Garantiile pot fi absolute (mai rar) sau statistice • (de ex 95% din pachete vor avea o intirziere < … secunde)

  3. Calitatea serviciului in retele: aplicatii real-time • Cind nu se garanteaza QoS, atunci reteaua e de tip best effort (face ce poate) • In afara de QoS mai conteaza QoS differentiation (diferentierea calitatii serviciilor), adica: • Utilizatorii sa poata fi tratati diferit, in functie de cit au platit sau in functie de tipul aplicatiei, etc. • Aplicatiile de timp real au de obicei cerinte mai ridicate de QoS. • Exemple de aplicatii real-time: • Sesiuni la distanta (remote login sau telenet) • Jocuri on-line • Aplicatii bancare sau de bursa (stock exchange) • Video conferinte • audio si video streaming • voce (de ex VoIP : voice over IP), …

  4. Aplicatii non real-time • Exemple de aplicatii care nu sint in timp real (non real-time sau nrt): • e-mail • Transfer de fisiere (FTP) • Navigare pe internet (WWW) • Aplicatiile nrt au in general cerinte mai mici privind intirzierea, dar cerinte mai mari de fiabilitate • Si intre ele exista diferente (de ex la www intrizierea e mai importanta decit la e-mail)

  5. Istoric • Internetul a fost dezvoltat ca o retea de date de tip best effort: • Datorita faptului ca primele aplicatii erau transferul de fisiere si schimbul de mesaje electronice (e-mail) • Se bazeaza pe comutarea de pachete (PS = pachet switching), care nu e potrivita pentru QoS la aplicatii rt. • In timp au aparut si aplicatii de timp real, de exemplu ideea de a transmite si voce, tv, etc, pe aceeasi retea • In mod normal vocea se transmite pe retele cu comutare de circuite (CS = Circuit Switching)

  6. ATM • In anii ’70 au fost propuse retelele ATM (Asynchronous Transfer Mode) • Sint primele (si deocamdata singurele) retele proiectate pentru QoS • Folosesc comutare cu circuite virtuale, un compromis intre PS si CS: • Se stabilesc circuite intre sursa si destinatie, ca la CS, dar in noduri resursele se partajeaza intre mai multe conexiuni • Datele, numite celule (a nu se confunda cu celulele de la telefonia celulara), sint pachete cu lungimea de 53 octeti: 5 octeti header + 48 de octeti payload (date utile) • Doreau sa permita trafic rt si nrt, integrind voce, date, TV, etc • Doreau sa inlocuiasca Internetul • Acest lucru nu s-a reusit, retelele ATM avind acum un rol mult mai limitat. • Totusi, idei din ATM au fost preluate si aplicate la Internet, pentru a se obtine QoS pe Internet.

  7. QoS in Internet: IntServ si DiffServ • IETF (Internet Engineering Task Force), organizatia de standardizare a Internetului, a propus intii standardul ISA (Integrated Services Architecture), sau Integrated Services (IntServ) • Datorita complexitatii ridicate si a faptului ca arhitectura IntServ nu se scaleaza bine cind nr de fluxuri de date e foarte mare, a fost propusa arhitectura DiffServ (Differentiated Services) • IntServ si DiffServ vor fi prezentate in continuare dupa William Stallings, Data and Computer Communications, , 8th edition, Pearson Prentice Hall,2007 [Sta08], ISBN 0-13-243310-9

  8. IntServ. Tipuri de trafic • Tipuri de trafic: • Elastic • Ne-elastic (inelastic) • Trafic elastic: • Se poate adapta la variatii mari ale intirzierii (delay) si capacitatii de trecere (throughput), continuind sa indeplineasca cerintele aplicatiei • E tipul traditional de trafic din Internet • Aplicatiile care genereaza astfel de trafic utilieaza in mod tipic TCP sau UDP la nivel transport • UDP: aplicatia va utiliza atita capacitate a retelei cita este disponibila, pina la limita maxima la care aplicatia poate genera date • TCP: aplicatia va utiliza atita capacitate a retelei cita este disponibila, pina la limita data de capacitatea receptorului conexiunii end-to-end.

  9. Trafic elastic • Tipuri de trafic elastic: • E-mail (protocol SMTP): nu e senzitiv la modificari ale intirzierii (delay changes) • Transfer de fisiere (FTP): senzitiv la modificari de throughput, deoarece utilizatorul se asteapta ca intirzierea fisierelor sa fie proportionala cu lungimea lor • Trafic interactiv: remote login (TELNET) si acces Web (HTTP) – senzitiv la intirzieri • Network management (SNMP): senzitiv la delay doar in cazul congestiilor • QoS perceput de utilizatori nu se refera la intirzierea pachetelor (IP), ci la intirzierea unui element al aplicatiei curente (o tastare la Telnet, un fisier la FTP, o pagina Web la HTTP, dar o pagina web poate fi mica sau foarte mare, daca are multe imagini) • Pt elemente mici intirzierea lor e determinata doar de intirzierea pe internet, pe cind pt elemente mari intirzierea totala e determinata de fereastra TCP (“the sliding-window performance of TCP”[Sta08]) • Necesitatea QoS e evidenta chiar si doar pt traficul elastic

  10. Trafic inelastic • Definitie: traficul inelastic NU se adapteaza cu usurinta sau nu se adapteaza deloc la modificarile de delay si throughput de pe internet • Exemplu tipic: traficul real-time (rt) • Cerintele pt traficul inelastic pot fi: • Throughput: cere o valoare minima pt a putea functiona • Delay: exemplu de delay-sensitive application: stock trading (bursa) • Jitter. Jitter = variatia intrizierii – e un parametru critic pt unele aplicatii rt (streaming, videoconferinte) • Pt a compensa jitter-ul se utilizeaza bufferarea datelor, dar lungimea bufferelor trebuie de asemena limitata (ex: videoconferinte) • Packet loss: de multe ori aplicatiile rt tolereaza pierderi de pachete • Cerinte introduse de traficul inelastic: • Sa se acorde tratament preferential aplicatiilor cu cerinte mai ridicate • Traficul inelastic nu isi reduce rata de transfer in caz de congestie, ceea ce ar afecta traficul elastic => necesitatea de a utiliza rezervarea resurselor

  11. Abordarea ISA • Scopul ISA: sa asigure QoS in retele IP • Ideea centrala: cum sa aloce (sa imparta) capacitatea existenta a retelei in caz de congestie • Mecanisme de controlul congestiei utilizate in routere inainte de ISA: • Algoritmi de rutare: majoritatea incearca sa minimizeze intirzierea, asigurind asfel load balancing • Packet discard: cind bufferele routerului sint pline, pachetele sosite cel mai recent sint eliminate => conexiunile TCP respective isi vor reduce rata de generare a datelor => se reduce congestia • Aceste mecanisme nu mai sint suficiente in cazul traficului inelastic

  12. Abordarea ISA • Fiecare pachet poate fi asociat unui flux (flow) • Flow = “a distinguishable stream of related IP packets that results from a single user activity and requires the same QoS” (RFC 1633, conform [Sta08]) • Diferente intre flux si conexiune TCP: • Fluxul e unidirectional • Fluxul poate avea mai multi destinatari (multicast) • Un pachet IP e identificat ca membru al unui flux pe baza adresei IP a sursei si a destinatiei

  13. Functii ale ISA pentru congestion management • Admission control (AC): • un flux trebuie sa rezerve resurse • Daca routerele nu au suficiente resurse pentru a garanta QoS-ul cerut, atunci acel flux nu este admis • Pt rezervari se foloseste protocolul RSVP (resource ReSerVation Protocol) • Algoritmi de routare: • Rutarea poate fi facuta pe baza a diferiti parametri de QoS, nu doar pe baza intirzierii • Queueing discipline: • Cum se aloca resurse cozilor (scheduling) • Discard policy: • Ce pachete se elimina (discard, or drop) din cozi

  14. Arhitectura ISA [Sta08]

  15. Componentele ISA • In figura, functiile de sub linia orizontala se aplica fiecarui pachet, deci trebuiesc optimizate (forwarding functions) • Functiile de deasupra liniei se numesc background functions: • Ele creaza structuri de date utilizate de forwarding functions • Reservation protocol: rezerva resurse ptr un flux si mentine informatii de stare despre fiecare flux in routere si end systems (probleme de scalare !) • AC: cind apare un nou flux se invoca functia de AC, care determina daca resursele existente sint suficiente pt noul flux, astfel incit sa ii fie satisfacute cerintele de QoS si sa nu fie afectat negativ QoS-ul fluxurilor existente • Management agent: poate modifica politicile de AC • Routing protocol: mentine o baza de date de rutare (routing database) care da urmatorul nod (next hop) pt fiecare adresa destinatie a fiecarui flux.

  16. Forwarding functions • Classifier and route selection: • Pachetele sint mapate unor clase • O clasa poate corespunde unui singur flux sau unui set de fluxuri care au aceleasi cerinte de QoS (ex: toate fluxurile de videostreaming sau toate fluxurile care apartin unei anumite organizatii) • Selectia unei clase se face pe baza unor cimpuri din header-ul pachetului IP • Packet scheduler: • managementul unei sau a mai multor cozi pt acelasi port de iesire • Include si functia de policing: sa determine daca un flux depaseste rata negociata si ce masuri sa se ia in acest caz.

  17. Servicii ISA • Se definesc la doua niveluri: • Categorii generale de servicii, fiecare din ele oferind anumite garantii (service guarantees). • In cadrul fiecarei categorii, serviciul pentru un anumit flux este specificat prin valorile anumitor parametri. Impreuna, acesti parametri formeaza Tspec (traffic specification – specificatia de trafic) • Cind un flux cere o rezervare, Tspec defineste cantitatea exacta de servicii cerute. • Daca rezervarea e acceptata, serviciul se obliga sa asigure QoS cerut atita timp cit traficul respecta descrierea din Tspec. • Traficul poate fi bine specificat utilizind token bucket.

  18. Token bucket [Sta08]

  19. Token bucket • Sursa de token-uri genereaza token-uri cu o rata de generare R • R = the continually sustainable data rate: rata medie de generare a datelor ce poate fi suportata pt o perioada relativ lunga de timp pt acel flux de date. • Daca tokenurile nu sint consumate, in recipient (galeata=bucket) se acumuleaza token-uri pina la capacitatea B octeti. • B e cantitatea cu care rata de generare poate fi depasita pentru perioade scurte de timp (burstiness) • Un pachet IP e trimis doar daca cantiatea de bucket-uri din recipient e mai mare sau egala cu lungimea pachetului (in octeti) si atunci din recipient se scot token-urile corespunzatoare lungimii pachetului. • Daca nu e indeplinita conditia, atunci pachetul va fi supus unei actiuni de policing, adica pachetul poate fi eliminat, intirziat, degradat la best effort sau marcat pt a fi eliminat ulterior, daca va fi nevoie. • Se garanteaza astfel ca, de-a lungul oricarei perioade de timp T, cantitatea maxima de date ce poate fi trasmisa pt acel flux de date nu poate depasi valoarea RT+B.

  20. Categorii de servicii ISA • Categoriile actuale de servicii sint: • Guaranteed (garantat) • Controlled load (incarcare controlata) • Best effort • Guaranteed service: • Se specifica o limita superioara pt intirzierea in cozi (queueing delay), ce trebuie adaugata la timpul de propagare (propagation delay or latency) • Nu sint pierderi de pachete in cozi (queueing losses due to buffer overflow), dar se pot pierde pachete datorita altor cauze (caderi ale unor elemente de retea sau schimbarea cailor de rutare) • E cel mai solicitant serviciu oferit de ISA.

  21. Categorii de servicii ISA • Controlled load: • Aproximeaza serviciul primit de aplicatiile best effort in conditii de incarcare scazuta a retelei. • Nu exista limita superioara a intirzierii, dar serviciul asigura ca un procent foarte mare de pachete nu vor avea intirzieri mai mari decit timpul de tranzit in retea (propagare + procesarea in rutere) • Pierderile in cozi vor fi aproape zero. • E potrivit pt adaptive real-time applications. • Best effort • RSVP: protocolul de rezervare a resurselor pt a asigura functionalitatea ISA.

  22. Differentiated Services • Probleme intimpinate de IntServ (ISA): • Complexitate ridicata • Cantitate mare de semnalizari, ceea ce face ca solutia sa nu fie scalabila pt volum mare de trafic • Routerele mentin informatii de stare => problema pt volum mare de trafic • Tosusi, exista o necesitate imediata de a asigura niveluri diferite de QoS unor fluxuri de date diferite => • arhitectura DS (Differentiated Services, or DiffServ), RFC 2475: • Usor de implementat, cost scazut, low-overhead

  23. Caracteristici ale DiffServ • Several key characteristics of DS contribute to its efficiency and ease ofdeployment: • • IP packets are labeled for differing QoS treatment using the existing IPv4or IPv6 DS field.Thus, no change is required to IP. • • A service level agreement (SLA) is established between the service provider(internet domain) and the customer prior to the use of DS. This avoids theneed to incorporate DS mechanisms in applications. Thus, existing applicationsneed not be modified to use DS. • • DS provides a built-in aggregation mechanism. All traffic with the same DSoctet is treated the same by the network service. For example, multiple voiceconnections are not handled individually but in the aggregate. This providesfor good scaling to larger networks and traffic loads. • • DS is implemented in individual routers by queuing and forwarding packetsbased on the DS octet. Routers deal with each packetindividually and do nothave to save state information on packet flows.

  24. DS domain • DS domain = a contiguous portion of Internet over which a consistent set of DS policies are administrated. • Serviciile oferite intr-un DS sint definite printr-un SLA (Service Level Agreement), care este un contract intre client si furnizorul de servicii, contract ce specifica serviciul forwarding ce trebuie sa il primeasca clientul pt diferite clase de pachete. • Clientul indica clasa fiecarui pachet IP prin cimpul DS setat in header-ul fiecarui pachet IP • Furnizorul de servicii trebuie sa configureze in fiecare router politicile de forwarding necesare indeplinirii contractului si trebuie sa masoare performantele fiecarei clase de pachete. • Daca destinatia pachetelor este in exteriorul domeniului DS, atunci domeniul va incerca sa trimita pachetele spre alte domenii, cerind acelor domenii servicii cit mai apropiate de cel negociat cu clientul in SLA. • Cimpul DS se numeste DS codepoint (DSCP) si are 6 biti.

  25. DS field [Sta08]

  26. Configurarea si operarea DS • Un domeniu DS consta intr-un set contiguu de routere (se poate ajunge de la un router la altul fara sa se iasa din domeniu). • Routerele dintr-un domeniu DS pot fi: • Noduri de frontiera (boundary nodes) • Noduri interioare (interior nodes) • Tratamentul de forwarding intr-un router se numeste Per Hop Behaviour (PHB). • PHB trebuie sa fie in orice router, dar in mod tipic cele interioare ofera doar PHB • Nodurile de frontiera indeplinesc, in afara de PHB, si functii mai complexe: clasificare, masurare (metter), marcare (marker), formare (shaper) si eliminare (dropper). • Clasificarea va separa pachetele in functie de clasa lor (pe baza DSCP) • Masurarea: verifica daca pachetul e conform cu TSpec negociat. In caz ca nu e, se aplica una din functiile de marcare, intirziere (formare) sau eliminare,

  27. Configurarea si operarea DS [Sta08]

  28. DS traffic conditioner [Sta08]

  29. Per hop behaviour (PHB) • Sint definite doua PHB: EF si AF: • Expedited forwarding (EF) PHB • Servicii end-to-end de tip low-loss, low-delay, low-jitter • Se asteapta ca pachetele din clasa EF vor intilni cozi goale sau foarte scurte • Border nodes vor limita rata si burstiness-ul acestor pachete la valori predefinite, iar interior nodes le vor trata astfel incit sa nu apara efecte de queueing • Se poate implementa folosind priority queueing, traficul EF avind prioritate mai mare decit alte cozi (cu alt tip de trafic). • Assured forwarding (AF) PHB • Ofera servicii mai bune decit beste effort (BE), dar fara sa necesite rezervarea de resurse si fara sa necesite tratarea diferita a fluxurilor de la useri diferiti. • Se definesc 4 clase AF, fiecare corespunzind unui profil de trafic • In cadrul fiecarei clase se definesc 3 valori de precedenta in caz de drop. Daca apare congestie, pachetele vor fi eliminate in functie de prcedenta lor (cele cu precedenta mai mica vor fi protejate fata de cele cu precedenta mai mare).

  30. Queueing disciplines • FIFO (first in first out): • Usor de implementat, dar: • fara garantii de QoS • fara protectia unor fluxuri de date fata de fluxurile care nu respecta contractul • Pot aparea situatii defavorizante: de ex mai multe pachete mici in coada in urma unui pachet mare => pachetele mici pot avea intirzieri foarte mari • EDF (earliest deadline first): • Fiecare pachet are in header momentul la care trebuie sa plece din coada • Pachetele sint sortate in ordinea plecarii, ceea ce inseamna inserarea unor pachete in coada • Inserarea e o operatie costisitoare • Ar fi algoritmul ideal, mai ales pt trafic rt, dar e prea complex de implementat • Algoritmi de tip fair queueing: situatie intermediara intre FIFO si EDF

  31. Queueing disciplines [Sta08]

  32. Weighted Fair Queueing • Aproximeaza un algoritm ideal, numit fluid fair queueing (FFQ) sau GPS (Generalized Processor Sharing), propus de Parekh si Gallagher, ce isi are originea in algoritmul (ideal) bit by bit round robin (Keshav si Demers): • GPS presupune ca fiecare pachet e infinit divizibil si ca pachetele din toate fluxurile cu date in coada (backlogged) transmit simultan • Fiecare flux i are o pondere wi, si atunci, daca capacitatea retelei este C, fiecare flux va primi C x Wi/(sum(Wj)) din capacitatea retelei • Suma e pt toate fluxurile backlogged • Fiecarui pachet I se calculeaza timpul de start (cind incepe sa fie servit) si timpul de finish (cind se termina trimiterea lui din coada) in GPS (FFQ) • Algoritmii reali aproximeaza FFQ (GPS), trimitind pachetele reale dupa timpul de finish sau/si de start al pachetelor in FFQ. • Algoritmii reali aproximeaza mai bine sau mai rau algoritmul ideal FFQ si au o complexitate de implementare mai mare sau mai mica • Pt a reduce calculele, se introduce notinuea de timp virtual, si pachetele primesc ca si etichete timpul de start si de finish virtual. • La timpul virtual valorile acestor timpi nu sint importante, ci doar ordinea lor. • Algoritmi reali: Packet by Packet GPS PGPS ( Weighted Fair Queueing WFQ), Start time Fair Queueing SFQ, Worst Case Weighted Fair Queueing WF2Q, etc…

  33. Priority queueing • E un caz limita de fair queueing • Datele utilizatorilor se pun in mai multe cozi, fiecare coada avind o anumita prioritate • O coada de prioritate mai mica nu va fi servita decit daca toate cozile de prioritate mai mare decit a ei sint goale. • Se poate ajunge la blocarea cozilor de prioritate mica. • Algoritmul mai e cunoscut sub numele de static priority queueing (SPS) sau simple priority queueing • Se poate folosi o combinatie de SPS cu WFQ: de exemplu SPS cu o coada pt trafic EF, un set de cozi pt trafic AF si o coada pt BE. In cadrul traficului AF se poate face WFQ intre cozile de tip AF.

More Related