Transport Layer

Asigurarea calitatii IP-telefoniei pe baza protocoalelor RTP si RTCP

Pentru micşorarea jitterului şi reţinerii la nivelul de reţea se foloseşte mecanismele de  garantare a calităţii, cerute de utilizator, RSVP, MPLS, Diff-Serv, ATM şi altele. Ele îmbunătăţesc calitatea serviciilor oferite de reţea, dar nu pot complect să elimine cozile formate în dispozitivele de reţea şi respectiv de a elimina jitterul. Pentru a compensa apariţia lui negativă ne permite protocolul la nivel de aplicaţie dezvoltat de IETF RTP (Real Time Protocol), care se foloseşte de tehnologiile H.322 şi SIP.

Protocolul RTP (RFC 1889) este destinat pentru transmiterea informaţiei sensibilă la reţinere la o adresă sau multi-adresă cu folosirea serviciilor de reţea. El nu posedă mecanisme personale, care va garanta transmiterea pachetelor la momentul potrivit, sau alţi parametri de calitate – aceasta se realizează de protocoalele mai inferioare. El nu asigură nici acele funcţii care le posedă protocoalele de transport, în particular, funcţiile de corectare a erorilor, sau dirijarea fluxului. De obicei RTP funcţionează deasupra UDP şi foloseşte serviciile lui, dar poate funcţiona şi deasupra altor protocoale de transport .

Serviciile RTP prevede indicarea tipului sarcinii utile şi consecutivităţii numărului pachetului în flux, precum şi marcare de timp. Expeditorul înseamnă fiecare pachet-RTP cu marcare de timp, iar destinatarul o extrage şi calculează reţinerea totală. Diferenţa în reţinerea pachetelor permite de a determina jitterul şi de a uşura influenţa lui – toate pachetele se vor transmite la aplicaţie cu una şi aceiaşi reţinere.

În aşa mod, principala caracteristică a RTP – calcularea reţinerii medii unui set de pachete şi transmiterea lor la aplicaţia utilizatorului cu reţinere constantă, egală cu reţinerea medie menţionată. Dar trebuie de menţionat că marcajul de timp RTP corespunde momentului de codare a primului semnal discret a primului pachet. De aceia, dacă pachetul-RTP, de exemplu cu informaţie audio, se împarte în câteva pachete de nivele mai inferioare, atunci marcajul de timp nu va corespunde timpului adevărat de transmitere, deoarece înainte de transmitere ele pot fi organizate în rând de aşteptare.

Încă o prioritate a RTP este că el poate fi folosit cu RSVP pentru transmiterea informaţiei multimedia sincronizată cu determinarea nivelului calităţii de deservire. Plus la aceasta, convorbirea se transmite pe reţeaua Internet necodificată. De aceia oricare nod ce se află în calea de transmitere a datelor se poate de conectat la linie şi să asculte convorbirea. Pentru  a rezolva această problemă, în RTP se propune un mecanism care asigură protecţia datelor, până la un nivel oarecare, de la un acces nesancţionat şi confidenţialitate. Aceste mijloace sînt destul de nesigure şi pot fi privite ca o rezolvare temporală a problemei – până când protocoalele, deasupra cărora lucrează RTP, nu vor fi înzestrate cu mecanisme dezvoltate de asigurare a datelor.

Posibilităţile RTP se pot dezvolta, combinîndul cu alt protocol a IETF şi anume cu protocolul dirijării transportului în timp real RTCP (Real-time Transport Control Protocol). Cu ajutorul RTCP se controlează transportul pachetelor-RTP şi asigură legătură inversă cu partea de transmisie şi alţi participanţi la sesiune. RTCP periodic expediază pachete sale de dirijare, folosind acelaş mecanism de divizare, care se utilizează şi pentru pachetele-RTP a informaţiei utilizatorului.

Funcţia de bază a RTCP este organizarea legăturii în direcţie opusă cu aplicaţie pentru răspuns, în calitate de recepţionare a informaţiei. RTCP transmite informaţii (atât de la receptor, cît şi de la expeditor) despre numărul de pachete transmise şi pierdute, mărimii jitterului, reţinerii. Această informaţie poate fi folosită de expeditor pentru schimbarea parametrilor de transmitere, de exemplu, micşorarea coeficientului de comprimare a informaţiei cu scopul de a îmbunătăţi transmiterea ei. RTCP de asemenea prevede identificarea utilizatorilor sesiunii.

Însă cu toate că posedă funcţii remarcabile, protocolul RTP nu este perfect. De exemplu, protocolul nici ca cum nu poate influenţa la reţinerea din reţea, dar el poate contrebui la micşorarea vibraţiilor vocii la prezenţa reţinerilor. Plus la aceasta, pachetele UDP primesc numere de ordine consecutive şi staţia de recepţie poate stabili dacă au fost pierdute pachete, însă aici RTP nu întreprinde nici o măsură pentru restabilirea pachetelor.

Una din posibilitatea de dezvoltare a posibilităţilor RTP este folosirea lui împreună cu protocolul RSVP, care oficial nu intră în familia de protocoale H.323, dar se susţine de multe aplicaţii de timp real.

Concluzii
Mesajele ICMP raporteaza de obicei erorile din procesarea datagramelor. Pentru a evita reintoarcerea mesajelor despre alte mesaje, nici un mesaj ICMP nu este trimis despre alte mesaje ICMP. De asemenea, mesajele ICMP sunt trimise numai in legatura cu erorile in tratarea primului fragment (fragment zero) al datagramelor fragmentate. (Fragmentul zero este fragmentul cu deplasamentul zero).

RPC este un apel de procedura la distanta. Reprezinta baza pentru aplicatii de retea: procedura care apeleaza este clientul, iar cea apelata este serverul.

RTCP este folosit pentru a strange informatii despre performanta conexiunii. Aceste informatii sunt folosite pentru ajustarea dinamica si optimizarea conditiilor de retea curente. Protocolul specifica raportul de pachete schimbate intre surse si destinatii ale informatiei multimedia.
Elemente de performanţă la nivelul transport – Lungu Mihail
Permite colectarea, salvarea şi interpretarea statisticilor, optimizarea reţelei cu resurse disponibile, detectarea modificărilor de performanţă, asigurarea călitaţii serviciilor.

Detectează schimbările în performanţa reţelei cu ajutorul datelor statistice (cronometre şi contoare) oferind astfel siguranţă şi calitate în funcţionarea reţelei.

Performanţa poate fi utilă şi pentru managementul faulturilor (pentru a detecta erorile), pentru administrarea conturilor (pentru a adapta costurile) şi pentru administrarea configuraţiei(ce modificare este necesară pentru o configuraţie optimă).
Această arie de administrare stabileşte ce reprezintă performanţa de reţea şi cum poate fi măsurată, care sunt elementele care se măsoară şi cu ce se măsoară. Administrarea performanţelor reţelei are legătură directă cu echipamentele hardware, componentele software şi cu datele unei reţele de calculatoare.
Definitia performantei este greu de dat, dar reprezintă actul de a face ceva cu succes, folosind cunoaştere, experienţă. De exemplu, media timpului de bună funcţionare este un parametru de performanţă. Când o componentă fizică, o aplicaţie sau o reţea nu funcţionează la parametrii optimi, aceasta reprezintă o problemă de funcţionare. Uneori problemele funcţionale conduc la probleme de performanţă. Pentru a stabili dacă reţelele funcţionează performant trebuie să le testăm şi să le comparăm cu valori de referinţă.

Procedura standard de testare pentru reţelele LAN şi WAN este monitorizarea reţelei, care poate ajuta în administrarea performanţei de reţea. Cunoscând elementele care influenţează performanţa reţelei şi interpretând rezultatele oferite de uneltele de lucru putem îmbunătăţii randamentul reţelei. Unele informaţii sunt culese direct de la utilizatori, altele prin comenzi ale sistemului de operare.

Pentru utilizator performanţele reţelei sunt reflectate de caracteristicile deservirii cererilor sale. O reţea se caracterizează, din punctul de vedere al majorităţii utilizatorilor, prin capacitate de transport (productivitate), cost, durata de răspuns la o cerere, fiabilitate şi gama de servicii oferite.[5]

De exemplu, o utilizare de 100% a unităţii centrale de prelucrare nu înseamnă neapărat că aceasta are o coadă de procese în aşteptare pentru execuţie, iar acest procent poate să nu aibă deloc legătură cu performanţa procesorului. Utilizatorii raportează că sistemul funcţionează foarte lent, iar problema ar putea fi datorită pierderii pachetelor de către reţea, fie datorită supraîncărcării reţelei, fie datorită funcţionării slabe a rutoarelor.

Stabilirea cauzei care scade performanţa funcţionării unei componente se realizează prin teste pentru a determina valori care au legătură cu aceea componentă. Administratorii reţelei pot măsura performanţa reţelei fără a folosi produse specializate. Administratorii de reţea trebuie să administreze reţeaua şi fără produse comerciale care sunt particularizate pe echipamente şi au dezavantajul că sunt scumpe şi nu pot fi modificate pentru a fi disponibile pentru versiunile noi de echipamente. Administratorul trebuie să seteze iniţial reţeaua şi să păsteze aceste stări. Aceasta se numeşte linia de bază a reţelei.

Metode de colectare a datelor de performanţă pentru reţele
După ce determinăm care elemente de performanţă de reţea trebuie să le monitorizăm, aplicaţiile pentru performanţă trebuie să fie capabile să acceseze datele pentru aceste elemente. Trei metode diferite sunt folosite pentru a obţine date de la reţea:

a) interogarea (querying) dispozitivelor de reţea (calculator central şi comutator) pentru a stoca informaţii;

b) observarea traficului existent în reţea pentru semnalarea performanţei de reţea;

c) generarea de trafic pentru teste pentru a analiza performanţa reţelei.

În continuare sunt prezentate diferenţe între aceste metode cu privire la colectarea

datelor din reţea.

a) Interogarea este cea mai simplă metodă de colectare a datelor de reţea.

Dispozitivele de reţea pot fi administrate sau neadministrate.

Dispozitivele de reţea administrabile includ programe de administrare care colectează statistici despre traficul de reţea care traversează dispozitivul.

Dispozitivele de reţea neadministrabile nu colectează date statistice despre traficul reţelei şi nu pot fi integrate pentru informaţii.

Prima categorie de dispozitive este mai scumpă.

Toate dispozitivele de reţea administrabile implementează protocolul SNMP (Simple Network Management Protocol) oferind atât stocarea datelor în baze de date ierarhice în dispozitivele de reţea, dar şi interograrea bazei de date de la dispozitivul îndepărtat. Protocolul SNMP se foloseşte pentru colectarea de statistici de la obiectale administrate.

Toate dispozitivele SNMP includ MIB pentru a stoca informaţiile de bază ale reţelei despre traficul prin dispozitiv. Aceste informaţii includ octeţii transmişi şi recepţionaţi la interfaţă, numărul şi tipurile de erori în interfeţe şi utilizarea reţelei pe fiecare interfaţă.

Tablea MIB SNMP pentru un dispozitiv de reţea conţine numeroase obiecte folosite în stabilirea performanţei reţelei. Baza de date MIB-II este îmbunătăţită pentru a determina traficul prin reţea şi erorile dispozitivelor de reţea.

Multe din valorile MIB-II sunt contoare. De exemplu, obiectul ifInOctets contorizează numărul de octeţi recepţionaţi de interfaţă de la prima pornire sau de la resetarea bazei de date MIB-II. Această valoare creşte la o valoare maximă apoi descreşte la zero şi porneşte din nou. Dispozitivele de reţea conţin numeroase porturi, menţionând tabele MIB-II separate 34 pentru fiecare interfaţă a dispozitivului. Tabelele separate pentru porturi sunt accesate folosind un index special din cadrul valorii MIB.

b) Observarea traficului existent este o altă tehnică pentru a colecta date necesare

performanţelor de reţea.

În mod implicit, o interfaţă de reţea acceptă doar pachete care sunt destinate pentru dispozitiv sau care sunt trimise pe o adresă de tip difuzare (broadcast) şi difuzare multiplă (multicast). Interfeţa de reţea poate fi setată în modul de lucru prin care permite să accepte toate pachetele din reţea, analizând destinaţia lor. Această facilitate permite dispozitivului de reţea să inspecteze fiecare pachet din reţea fără a ţine cont de unde vine şi unde se duce.

c) Generare de trafic pentru testare

Multe aplicaţii pentru performanţe de reţea generază trafic de reţea propriu, pentru a determina performanţa curentă a reţelei. Această tehnică cere cunoştinţe matematice şi teoria reţelelor. Toate aplicaţiile pentru analizarea performanţelor reţelei care generează trafic pentru testare solicită două dispozitive pe reţea. Performanţa reţelei de-a lungul unei căi între 2 dispozitive este determinată folosind metodele pereche de pachete şi tren de pachete descrise la subcapitolul ,,Capacitatea lăţimii de bandă” din capitolul 2 . Nu este testată nici altă parte a reţelei (ci doar între punctele stabilite).

Dacă se doreşte testarea altor părţi de reţea, dispozitivele de testare trebuie să fie

relocalizate la acele puncte ale reţelei. Este bine să existe multiple perechi de dispozitive testate localizate în puncte diferite ale reţelei. Ideal este să acoperim o cât mai mare suprafaţă din reţea plasând un număr cât

mai mic de puncte de testare.[8]
Etapele de analiză a performanţei:

Analiza performanţelor cuprind următoarele etape:

• identificarea metricilor relevante pentru fiecare componentă de reţea;

• stabilirea modalităţilor efective de măsurare a performanţei pe baza acestor metrici;

• stabilirea legăturilor (relaţionarea) între performanţele observate la metricile

respective;

• transpunerea rezultatelor analizei în oportunităţi pentru creşterea performanţei

sistemului.

Măsurătorile de performanţă au rolul de a:

• ajuta la luarea deciziilor de alocare sau realocare a resurselor şi planificarea dezvoltării în viitor a reţelei;

• monitorizarea activităţii reţelei şi serviciilor pentru a detecta orice schimbare în funcţionare sau în calitatea serviciilor;

• determina gradul prin care utilizatorii sunt satisfăcuţi de reţea şi de serviciile oferite de aceasta;

• servii ca prim pas în identificarea celei mai bune performanţe din practică, folosind performanţa ca scop şi investind în factorii care conduc la performanţă.


Evaluarea performanţei reţelei. Factorii care afectează performanţa reţelei.
Lucrarea nu are intenţia de a prezenta numai formule care descriu teoretic reţeaua, ci de a descrie elementele care influenţează reţeaua pentru a putea înţelege cum lucrează reţeaua, atât din punct de vedere fizic, logic, cât şi informaţional.

În acest subcapitol se prezintă factorii care se pot lua în considerare pentru a putea creşte performanţa reţelei. În capitolele următoare vor fi analizaţi aceşti factori de performanţă ai reţelei.

Performanţa depinde de nenumăraţi factori. Dintre aceştia, există patru factori principali care afectează semnificativ performanţa reţelei:

• lăţimea de bandă;

• problemele hardware;

• încărcarea serverului;

• opţiunile utilizatorului.

O altă problemă care poate degrada performanţele este sindromul fereastrei stupide (Clark, 1982). Această problemă apare atunci când datele sunt transmise la entitatea TCP-lui trimite în blocuri mari, ci o aplicatie interactiva pe partea primirii/citirii de date de 1 octet la un moment dat. Fig. 6-35. Iniţial,bufferul pe partea de primire este completă şi expeditor ştie acest lucru (de exemplu, are o fereastră de dimensiune 0). Apoi aplicatie interactiva citeste un caracter din fluxul TCP. Această acţiune face ca TCP-ul primit sa fie fericit, aşa că trimite o actualizare fereastră la expeditor spunând că totul este optim pentru a trimite un octet. Expeditorul obligă şi trimite un octet. Buffer-ul este acum plin, astfel încât receptorul recunoaşte segmentul de 1-octet, dar seteaza fereastra la 0. Acest comportament poate merge la nesfârşit.[9]

Soluţia lui Clark este de a preveni receptorul de a trimite o actualizare de fereastră pentru 1 octet. În schimb, este forţat să aşteptate până când aceasta are o cantitate decenta de spaţiul disponibil şi de publicitate. Mai exact, receptorul nu trebuie să trimită o actualizare de fereastră până când se poate ocupa de dimensiunea segmentului maximă ce este promovat atunci când conexiunea a fost stabilită sau până când buffer-ul său este pe jumătate gol, oricare dintre acestea este mai mică.

În schimb, aceasta ar trebui să încerce să aşteptaţi până când s-a acumulat suficient spaţiu în fereastra pentru a trimite un segment complet sau cel puţin jumătate conţinând dimensiunea buffer-ului receptorului (pe care aceasta trebuie să estimeze de la modelul de actualizări fereastră care le-a primit în trecut) .

Algoritmul Nagle si solutia Clark la sindromul fereastră prosta sunt complementare. Nagle încearcă să rezolve problema cauzată de cererea de trimitere de date cu livrare la TCP un octet la fiecare tact. Clark a încercat sa rezolve problema cererii pentru primirea datelor de la TCP de un octet la fiecare tact. Ambele soluţii sunt valide şi pot lucra împreună. Scopul este ca expeditorul sa nu trimita segmente mici iar receptorul sa intrebe de ele.

Această problemă este mult mai dificilă la nivelul de transport Internet decât în protocoalele legătură de date. În acest caz​​, în care întârzierea este de aşteptat si foarte previzibila (de exemplu, are o variaţie mică), astfel încât contorul de timp poate fi setat pentru a merge „off” doar după primirea confirmarii, după cum se arată în Fig. 6-38 (a). Deoarece confirmarile sunt rareori întârziate în stratul de legături de date (din cauza lipsei de congestie), lipsa de o confirmare în momentul aşteptat reprezintă, în general, fie un cadru sau confirmare pierduta.

Figura (a) densitate de probabilitate a sosirii confirmării în stratul de legături de date. (b) densitate de probabilitate de sosire a confirmarii pentru TCP.

TCP-ul se confruntă cu un mediu radical diferit. Funcţia de densitate de probabilitate a timpului necesar pentru o confirmare TCP de a se intoarce seamănă mai mult cu Fig.(b) decât (a). Determinarea timpului dus-întors la destinaţie este complicat. Chiar şi atunci când acesta este cunoscut, se decide cu privire la intervalul de expirare, de asemenea, dificil. În cazul în care timpul de terminare este setat prea scurt, să zicem, T1 în Fig.(b), vor avea loc transmisii inutile, înfundarea Internetului cu pachete inutile. Dacă este setat prea mult timp, (de exemplu, T2), performanţa va avea de suferit din cauza întârzierii retransmisiei lungi ori de câte ori un pachet este pierdut. În plus, media şi varianţa de distribuţie a confirmarii se pot schimba rapid în câteva secunde ca congestionării construite. Soluţia este de a utiliza un algoritm extrem de dinamic, care ajustează în mod constant intervalul de „timeout”, bazat pe măsurarea continuă a performanţei reţelei.[10]

Elementele definitorii ale performantei in cadrul unei retele Wireless

În teorie, protocoalele de transport ar trebui să fie independente de tehnologia care sta la baza nivelului de reţea. În special, TCP nu ar trebui să intervina dacă IP-ul se transmite prin fibră optică sau prin radio. În practică, nu contează, deoarece cele mai multe implementari TCP au fost atent optimizate si sunt bazate pe ipoteze care sunt adevărate pentru reţelele cu fir. Ignorarea proprietăţilor de transmisie wireless poate duce la o implementare TCP, care este logic corecta, dar are performante oribile.

În timp ce UDP-ul nu suferă de aceleaşi probleme ca TCP-ul, comunicarea wireless introduce, de asemenea, dificultăţi pentru acesta. Problema principală este că programele de utilizare a UDP-ului aşteaptă ca acesta să fie extrem de fiabila. Ei ştiu că nu sunt garanţii acordate. Într-un mediu fără fir, UDP-ul va fi departe de a fi perfect. Pentru programele care se pot recupera de la mesaje UDP pierdute,doar la costuri considerabile, brusc trecând de la un mediu în care, teoretic, mesajele pot fi pierdute, dar rareori sunt, la unul în care acestea sunt în mod constant pierdute,ceea ce poate duce la un dezastru de performanţă.[13]

Problemele de performanţă sunt foarte importante în reţelele de calculatoare. Atunci când sute sau mii de computere ce sunt interconectate,in interacţiuni complexe, sunt frecvente consecinţele neprevăzute. Frecvent, această complexitate conduce la performanţă slabă şi nimeni nu ştie de ce. În următoarele secţiuni, vom examina multe probleme legate de performanţele reţelei pentru a vedea ce tipuri de probleme există şi ce se poate face pentru ele.

Din păcate, înţelegerea performanţele reţelei este mai mult o artă decât o ştiinţă. Există puţina teorie de bază, care este de fapt cu privire la orice utilizare în practică. Cel mai bun lucru este sa ne folosim de experienţa dobândită şi de exemplele prezente luate din lumea reala. Am întârziat în mod intenţionat această discuţie până când am studiat stratul de transport TCP, pentru a putea folosi TCP-ul ca un exemplu în diferite locuri. Nivelul de transport nu este numai o chestiuni de performanţă. Am văzut unele dintre ele în stratul de reţea în capitolul precedent. Cu toate acestea, stratul de reţea tinde să fie în mare măsură preocupat de rutare şi de control al congestiei.Mai larg, sistemul este orientat spre problemele ce tind să fie legate de transport. În următoarele cinci secţiuni, ne vom uita la cinci aspecte ale performanţei reţelei:
1.Probleme de performanţă.

2. Măsurarea performanţei reţelei.

3. Sistem de proiectare pentru o performanţă mai bună.

4. Fast TPDU prelucrare.

5. Protocoalele pentru viitor, de înaltă performanţă reţele.
Ca o paranteza, avem nevoie de un nume generic pentru unităţile schimbate de către entităţile de transport. Termenul TCP, segment, este confuz şi nu este niciodată folosit în afara lumii TCP.Termeni ATM (CS-PDU, SAR-PDU, şi SCPC-PDU) sunt specifice ATM-urilor. Pachete referă în mod clar la nivelul de reţea, mesaje şi fac parte din stratul de aplicaţie. Pentru lipsa unui termen standard, vom merge înapoi la unităţile de asteptare schimbate de către entităţile de transport TPDUs. Atunci când ne referim atât la TPDU cat şi la pachete impreuna, vom folosi sub formă de pachete ca termen colectiv.Prin aceasta inţelegem atât pachetele din stratul de reţea cat şi TPDU-ul încapsulat în ea.

Unele probleme de performanţă, cum ar fi congestionarea, sunt cauzate de suprasarcini temporare a resurselor. Dacă mai mult trafic brusc ajunge la un router decat router-ul poate suporta, congestia se va construi şi performanţa va avea de suferit.

Performanţa se degradeaza, de asemenea atunci când există un dezechilibru structural al unei resurse. De exemplu, dacă o linie de comunicare Gigabit este ataşata la un PC low-end, CPU nu va fi capabil să proceseze pachetele primite suficient de rapid, iar unele vor fi pierdute. Aceste pachete vor fi retransmise în cele din urmă, adăugand întârziere, pierderea de lăţime de bandă, şi reducerea, în general, de performanţă.

Suprasarcinile pot fi, de asemenea, sincron declanşate. De exemplu, dacă un TPDU conţine un parametru prost (de exemplu, portul pentru care este destinat), în multe cazuri, receptorul va trimite inapoi o notificare de eroare. Acum luam în considerare ceea ce s-ar putea întâmpla dacă un TPDU rău este difuzat la 10.000 de masini: fiecare ar putea trimite înapoi un mesaj de eroare. Furtuna de difuzari rezultata ar putea paraliza reţeaua.

Un al doilea exemplu de supraîncărcare sincrona este ceea ce se întâmplă după o pană de curent electric. În cazul în care puterea revine, toate maşinile pornesc un salt simultan pentru a începe repornire. O secvenţă tipică de repornire ar putea necesita mai întâi câteva servere (DHCP) pentru a aflarea identitatii, şi apoi la unele server de fişiere pentru a obţine o copie a sistemului de operare. În cazul în care sute de maşini fac toate acestea deodată, serverul nu va face fata.

Chiar şi în absenţa unor suprasarcinilor sincrone şi prezenţa unor resurse suficiente, performanţă slabă poate apărea din cauza lipsei menteneantei sistemului. De exemplu, dacă o maşină are o multime de puterea procesorului şi a memoriei, dar nu suficient de memorie a fost alocată pentru spatiu tampon, depăşirile vor apărea şi TPDU-urile vor fi pierdute. În mod similar, în cazul în care algoritmul de planificare orară nu dă o prioritate suficient de mare pentru prelucrare TPDUs primite, unele dintre ele pot fi pierdute.

Un alt aspect de menteneanta este setarea timeoutului corect. Atunci când un TPDU este trimis, un timer este setat de obicei pentru a proteja împotriva pierderii TPDU. În cazul în care timeout-ul este setat prea scurt, retransmisii inutule vor avea loc, blocand firele. În cazul în care este setat timeout prea lung, întârzieri inutile vor apărea după ce un TPDU este pierdut.
Reţelele Gigabit aduc cu ele noi probleme de performanţă. De exemplu, expedierea de 64 de KB de date de la San Diego la Boston, în scopul de a umple receptorului memoria de KB 64. Să presupunem că legătura este de 1 Gbps şi viteză de întârziere este de 20 msec. Iniţial, la t = 0, conducta este goala, aşa cum este ilustrat în Fig. (a). Doar 500 de μsec mai târziu, în Fig.(b), toate TPDU-urile sunt pe fibra. TPDU-ul va fi acum undeva în apropiere de Brawley, California de Sud. Cu toate acestea, transmiţătorul trebuie să se oprească până când aceasta primeste o actualizare de fereastră.