Calitatea serviciului

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare
Fără note de subsol
Acest articol sau secțiune privind telecomunicațiile lipsește sau lipsește de note specifice și referințe bibliografice .
Deși există o bibliografie și / sau linkuri externe , nu există o contextualizare a surselor cu note de subsol sau alte referințe precise care indică cu promptitudine originea informațiilor. Puteți îmbunătăți această intrare citând mai precis sursele .

În domeniul rețelelor de telecomunicații , termenul de calitate a serviciului sau mai simplu QoS (din limba engleză Quality of Service ) este utilizat pentru a indica parametrii utilizați pentru a caracteriza calitatea serviciului oferit de rețea (de exemplu pierderea pachetelor , întârzierea ) , sau instrumentele sau tehnicile pentru a obține o calitate dorită a serviciului.

Calitatea serviciului este în mod normal corelată negativ cu traficul oferit rețelei și pozitiv cu resursele utilizate pentru construirea și gestionarea rețelei.

Traficul oferit rețelei și intervenția defecțiunilor sunt de obicei modelate ca procese stochastice : în consecință, parametrii utilizați pentru a caracteriza calitatea serviciului sunt de obicei variabile aleatorii .

Atunci când un contract de servicii prevede parametri de calitate a serviciilor, cu penalități aferente, dacă acești parametri nu sunt respectați, vorbim de SLA sau acord de nivel de serviciu .

Descriere

Telefonie

În domeniul telefoniei și, în general, al comutării circuitelor, calitatea serviciului include parametri precum:

  • disponibilitatea serviciului;
  • nivelul de zgomot pe circuit;
  • nivelul sonor;
  • probabilitatea de a găsi o linie liberă pentru a iniția comunicarea;
  • probabilitatea încetării nedorite a unei comunicări;
  • durata medie și maximă a ineficiențelor.

Rețele de pachete

Într-o rețea de pachete , un pachet primit de un comutator poate găsi portul pe care ar trebui să fie transmis de un alt pachet în transmisie. În acest caz, este stocat într-o coadă a unui buffer și, prin urmare, suferă o întârziere la coadă. Dacă coada este plină, pachetul este eliminat sau pierdut.

Parametrii considerați de obicei pentru o rețea de pachete sunt:

  • livrare în afara comenzii sau în afara comenzii - în unele rețele, o secvență de pachete trimise de la un nod la altul poate fi livrată într-o ordine diferită de cea originală. Acest lucru se întâmplă de obicei, deoarece pachetele sunt direcționate pe căi diferite din cauza comutării pachetelor . Această problemă face necesar ca protocoalele de transport să reordoneze pachetele scoase din comandă odată ce ajung la destinație și duce la întârzieri suplimentare în reconstruirea fluxului de date la nivelul aplicației. Din punct de vedere cantitativ, se ia în considerare probabilitatea ca un pachet să nu funcționeze.
  • eroare de transmisie : un pachet poate fi livrat la destinație, dar nu identic cu cel trimis. Multe rețele recunosc majoritatea erorilor de transmisie, iar unele sunt chiar capabile să corecteze aceste erori. Din punct de vedere cantitativ, se ia în considerare procentul de pachete greșite. Protocoalele de transport recunosc de obicei un pachet rău și solicită retransmiterea acestuia ca și cum ar fi fost pierdut, dar este, de asemenea, posibil ca eroarea să ajungă la aplicația finală.
  • întârziere (întârziere) suferită de un colet plasându-l în rețea până la livrarea către destinatar. Se iau în considerare caracteristici precum întârzierea medie („pachetele medii necesită 10 ms pentru a traversa rețeaua”) și percentilele sale („99% din pachete sunt livrate în termen de 20 ms”). De asemenea, se ia în considerare jitterul , adică variația întârzierii între pachetele trimise în ordine de la un nod la altul.
  • pierdere de pachete sau pachete scăzute ( pierdere de pachete ): se ia în considerare procentul de pachete pe care rețeaua în ansamblu nu le livrează la destinație. Pierderea unui pachet este gestionată în moduri diferite de protocoalele de transport, chiar dacă acest lucru depășește definiția calității serviciului rețelei: într-un protocol fără confirmare, informațiile nu ar fi transmise, într-un protocol cu ​​confirmare ca TCP , receptorul, după așteptarea unui timp rezonabil, ar trebui să solicite retransmiterea informațiilor, provocând întârzieri grave (întârziere) în transmisia generală.
  • transfer : lățimea de bandă a cărei valoare maximă permisă este în general adăugată parametrilor anteriori depinde de contractul stipulat de utilizator cu furnizorul de servicii .

Pentru aplicații sau servicii în timp real , cum ar fi transferul de fișiere sau partajarea video , unii dintre acești parametri (cu excepția întârzierii și transferului) sunt satisfăcuți de protocolul de rețea TCP care se ocupă de cererea de reordonare și recuperarea erorilor pe pachetele primite și retransmiterea pachetelor pierdute sau a pachetelor neprimite la costul unui anumit timp de procesare. Întârzierea și variabilitatea acesteia pentru aceste aplicații nu sunt considerate un parametru critic, deoarece este tolerat de utilizator ca timp necesar pentru a-și satisface cererea de achiziție de date. Dacă timpul de transmisie este excesiv, utilizatorul tinde de obicei să solicite un randament mai mare care, totuși, poate fi satisfăcut de furnizor numai printr-o lățime de bandă mai mare .

Pe de altă parte, pentru aplicații în timp real , cum ar fi voce peste IP ( VOIP ) și streaming audio-video live , parametrii de întârziere, variabilitatea întârzierii și pierderea pachetelor devin sensibile, ceea ce implică, respectiv, timpi de latență prea mari, jitter care dă naștere la livrarea în afara secvenței și, în consecință, necesitatea reordonării cu întârziere de procesare suplimentară și, în cele din urmă, cererile de retransmisie de către TCP cu o întârziere suplimentară suplimentară. Prin urmare, în astfel de aplicații, este preferabil să se evite utilizarea protocolului TCP în favoarea celuilalt protocol de transport UDP care nu controlează transmisia sau nu îndeplinește funcțiile de mai sus, cu prețul unor pierderi de date.

În plus, este adesea necesară o garanție mai mare asupra așa-numitelor parametri de calitate a serviciului (QoS) în cazul comunicațiilor în timp real, cum ar fi vocea și difuzarea conținutului multimedia audio - video în timp real în situații de congestie. pe interne noduri . comutare .

Aplicații care necesită QoS

Modelul QoS original al internetului, care nu este QoS, este potrivit pentru aplicații flexibile , care pot funcționa chiar și pe rețele cu performanțe foarte degradate și viceversa utilizează toată lățimea de bandă disponibilă, dacă aceasta este abundentă.

Alte tipuri de servicii sunt numite inelastice , ceea ce înseamnă că necesită un anumit nivel de lățime de bandă pentru a funcționa - dacă obțin mai mult, nu îl folosesc și dacă primesc mai puțin, nu funcționează deloc. Aceste aplicații fac necesară luarea de măsuri pentru a asigura o anumită QoS.

Aplicațiile care necesită QoS sunt, de exemplu, următoarele:

  • streaming multimedia : poate necesita un flux garantat;
  • Telefonia VoIP poate necesita constrângeri foarte stricte privind întârzierea și variabilitatea întârzierii ( jitter );
  • emularea dedicată a legăturii necesită atât un debit garantat, cât și o întârziere maximă limitată;
  • o aplicație critică de securitate, cum ar fi operația la distanță, poate necesita un nivel de disponibilitate garantat, numit și QoS dur .

În contextele de lucru, se poate întâmpla ca cerințele QoS să fie definite chiar și pentru aplicații care nu sunt intrinsec elastice, pentru a asigura niveluri adecvate de productivitate. De exemplu, „terminalul agenției de turism trebuie să poată finaliza tranzacția în decurs de 10 s în 98% din cazuri”. Adesea, însă, o cerință de acest tip necesită intervenția atât în ​​rețea, cât și în sistemul informațional care furnizează serviciul (de exemplu, configurarea unui număr adecvat de servere).

Mecanisme QoS pe Internet

Când a fost creat Internetul , nu a fost percepută o nevoie de QoS pentru aplicații. De fapt, întregul Internet urmează cea mai bună filosofie de efort , adică sistemul garantează că va face tot posibilul pentru a finaliza o operațiune, dar nu garantează deloc că operațiunea va fi efectuată sau în ce mod. Chiar dacă protocolul IP oferă 4 biți pentru tipul de serviciu (tip de serviciu) și 3 la prioritatea fiecărui pachet, acești biți sunt în mare parte neutilizați. Odată cu creșterea numărului și tipurilor de servicii și a traficului oferit în comparație cu capacitatea rețelei, problema calității serviciilor a început să devină importantă și din ce în ce mai luată în considerare.

În principiu, există două modalități de a oferi garanții privind calitatea serviciilor.

Supraprovizionare

Prima metodă, numită supraprovizionare ( supradimensionare ), constă în furnizarea de resurse de rețea (transmisie, stocare și procesare) din abundență, suficientă pentru a satisface cererea maximă așteptată, cu o marjă substanțială de siguranță. O soluție simplă, dar unii cred că, în practică, este prea scump și nu se aplică dacă cererea maximă crește mai repede decât s-a prevăzut: este nevoie întotdeauna de timp pentru a avea resurse noi.

Prioritate

Alternativa este de a administra lățimea de bandă disponibilă, asigurându-vă că pachetele care sosesc la un nod de rețea ( router ) sunt supuse unui tratament diferențiat sau acelora cărora trebuie să li se garanteze un anumit QoS primesc un tratament special. Pentru a realiza acest lucru, trebuie rezolvate două probleme:

  • Identificați pachetele care urmează să primească un tratament privilegiat ( clasificarea traficului sau discriminare ).
  • Aplicați acestor pachete identificate o disciplină de coadă care garantează performanțele necesare pentru a fi aplicate apoi pe porturi sau pe interfețele de ieșire ale routerelor.

Clasificare

Metodele structurate pentru a identifica traficul care trebuie privilegiat sunt:

  • Servicii integrate , bazate pe rezervări: înainte de a începe o sesiune care are cerințe QoS, aplicația trebuie să „întrebe” rețeaua dacă poate garanta performanța necesară ( controlul admiterii ): rețeaua evaluează dacă are resurse adecvate și, în caz afirmativ, el acceptă rezervarea prin acordarea serviciului solicitat.
  • Servicii diferențiate , prevede că utilizatorii rețelei stipulează a priori un contract care definește cantitatea maximă de trafic „privilegiat” pe care o pot genera și marchează acest trafic folosind câmpul Tip de serviciu ( TOS ) al antetului IP. Prin urmare, în acest caz, rezervările sunt strict „statice”.

Mai ales în rețelele mici, pot fi folosite metode mai simple, care implică identificarea manuală a traficului care trebuie prioritizat pe routere, de obicei folosind liste de control al accesului (ACL).

Disciplinele cozii

Pe un router care nu aplică politicile QoS, pachetele sunt transmise pe porturile de ieșire în ordinea în care au ajuns. O disciplină de coadă, sau planificarea pachetelor, constă în esență în gestionarea pentru fiecare port a mai multor cozi de ieșire, în care sunt clasificate pachetele. Disciplina cozii determină în ce ordine vor fi preluate pachetele din diferitele cozi.

Exemple de disciplină de coadă:

  • prioritate strictă : cozile sunt sortate după prioritate. Ori de câte ori un pachet urmează să fie transmis, acesta este preluat din coada cu cea mai mare prioritate care are un pachet pregătit. În acest fel, o aplicație cu prioritate mai mare poate monopoliza întreaga bandă disponibilă, în detrimentul celor cu prioritate mai mică ( foame ).
  • Round robin ponderat : se ia câte un pachet din fiecare coadă la rând. Acest lucru asigură că toate clasele de aplicații vor putea fi difuzate. „Ponderat” înseamnă că fiecărei cozi i se poate atribui o greutate, adică o fracțiune din lățimea de bandă disponibilă, iar pachetele sunt preluate pentru a garanta această lățime de bandă disponibilă. Dacă o clasă de trafic la un anumit moment nu folosește banda alocată, aceasta este utilizabilă de către celelalte ( împrumut de lățime de bandă ).
  • Discipline mai avansate de așteptare, cum ar fi Coada Ierarhică a Pachetelor (H-PFQ) și Curba Serviciului Târgului Ierarhic (H-FSC) , vă permit să exprimați atât o lățime de bandă cât și o cerință de întârziere pentru fiecare coadă. În acest moment, acestea sunt disponibile numai pe software - ul, BSD- pe bază sau linux- routere pe bază. A se vedea Programarea curbei de servicii echitabile ierarhice .

Alte instrumente utilizate pentru gestionarea lățimii de bandă disponibile:

  • RED ( Detectare aleatorie timpurie ): pe măsură ce se apropie congestia , rețeaua aruncă în mod arbitrar un procent mic din trafic. Acest lucru este interpretat de TCP ca o indicație a congestiei, reducând cantitatea de trafic trimis. Un caz particular al acestei tehnici numit WRED ( Weighted Random Early Detection ) permite să se distingă fluxul de trafic de la care să înceapă aruncarea pachetelor în prezența congestiei. Cu WRED este posibil să se definească praguri de utilizare a legăturilor care, odată atinse, determină respingerea pachetelor care aparțin unor clase specifice de trafic. Astfel, când se atinge primul prag, vor fi eliminate numai pachetele de fluxuri neimportante, în timp ce la atingerea unor praguri de utilizare din ce în ce mai mari, pachetele aparținând fluxurilor de trafic mai importante vor fi de asemenea eliminate. „Ponderat” înseamnă că clasa de trafic care va experimenta cel mai mare număr de pachete aruncate va fi cea asociată cu cel mai mic prag. Definiția pragurilor de utilizare și a diferitelor fluxuri de trafic se face pe bază de configurație.
  • limitarea ratei : o clasă de trafic poate fi limitată astfel încât să nu folosească mai mult decât o anumită bandă.

Discuţie

Piața nu a favorizat încă apariția serviciilor QoS end-to-end, adică capabile să garanteze constrângeri asupra QoS unui flux de date schimbate între utilizatori la distanță. Unii cred că o rețea stupidă , care este supradimensionată, adică care oferă suficientă lățime de bandă pentru majoritatea aplicațiilor și de cele mai multe ori, este deja cea mai bună soluție posibilă din punct de vedere economic, arătând puțin interes în sprijinirea aplicațiilor non-standard capabile de QoS.

Internetul are deja acorduri complexe între furnizori și pare să existe puțin entuziasm în sprijinirea QoS prin conexiuni care implică rețele aparținând diferiților furnizori sau în acorduri cu privire la politicile care ar trebui sprijinite pentru a le sprijini.

Scepticii QoS indică faptul că dacă aruncați prea multe pachete pe o conexiune elastică cu QoS scăzut, sunteți deja periculos de aproape de punctul de aglomerare pentru aplicațiile inelastice cu QoS ridicat, deoarece nu mai există o modalitate de a arunca pachete suplimentare fără a încălca contractele de pe traficul QoS.

De asemenea, este important să subliniem că gestionarea QoS în rețelele de acces fără fir LTE și WiMAX este un subiect de primă importanță care trebuie abordat pentru difuzarea acestor tehnologii. De fapt, organismele responsabile cu emiterea specificațiilor LTE și WiMAX au încorporat deja mecanismele standard necesare pentru gestionarea QoS oferite terminalelor.

În termeni generali, după cum subliniază Kotler, deoarece companiilor le este mai greu să își diferențieze produsele fizice, se orientează către diferențierea serviciilor, indiferent dacă aceasta înseamnă livrarea la timp, răspunsuri mai bune și mai rapide la întrebări sau soluționarea mai rapidă a reclamațiilor. Cei mai buni furnizori de servicii cunosc bine aceste beneficii și, de asemenea, știu cum să creeze experiențe memorabile ale clienților. [1]

Probleme QoS cu unele tehnologii

Următoarele proprietăți pot fi utilizate numai pe porturile finale, dar nu și pe servere , backbones sau alte porturi, care mediază multe fluxuri concurente.

  • jumătate duplex - coliziuni de legătură poate provoca întârzieri de a varia ( bruiaj ), deoarece pachetele sunt întârziate de fiecare coliziune cu un timp backoff.
  • IEEE 802.3x porturi tamponate la coadă ( control flux ).

Controlul fluxului IEEE 802.3x nu este un control real al fluxului, ci mai degrabă un control al cozii. Un exemplu de probleme IEEE 802.3x sunt blocurile de cap de linie . Multe dintre comutatoarele de astăzi folosesc IEEE 802.3x în mod implicit - chiar și pe portul uplink / backbone.

Citat din: Network World, 13.09.1999, „Feedback control feedback” : „... Hewlett-Packard subliniază că calitatea serviciilor este o modalitate mai bună de gestionare a congestiei potențiale, iar Cabletron și Nortel observă că funcțiile QoS pot„ nu funcționează corect dacă un comutator trimite [IEEE 802.3x] cadre de pauză .... "

Acest citat sugerează că QoS și IEEE 802.3x sunt incompatibile între ele.

Notă

  1. ^ Philip Kotler și Kevin Lane Keller (2016). Managementul marketingului, ediția a 15-a, Pearson Education, Harlow.

Bibliografie

  • M. Menth, R. Martin și J. Charzinski „Supraprovizionarea capacității pentru rețele cu cerințe de rezistență.” În Proc. Al ACM Sigcomm 2006.

Elemente conexe

Alte proiecte

linkuri externe

Controlul autorității LCCN (EN) sh2012001112 · GND (DE) 4496068-2
Adus de la „ https://it.wikipedia.org/w/index.php?title=Quality_of_service&oldid=121070380 ”