1

3.5.5 Transferul sigur de date

S ne amintim ca serviciul oferit de nivelul reea al Internet-ului (serviciul IP) nu este sigur.
Serviciul IP nu garanteaz recepia datagramelor, nu garanteaz recepia n ordine a datagramelor i nu
garanteaz integritatea datelor din datagrame. Folosind serviciul IP, datagramele pot suprancrca
buffer-ele router-elor i pot s nu ajung niciodat la destinaie; datagramele pot s nu soseasc n
ordine, i bii din datagrame pot fi eronai (schimbai din 0 n 1 i vice-versa). Deoarece segmentele de
nivel transport sunt transmise prin reea cu ajutorul datagramelor IP, segmentele de nivel transport pot
avea, de asemenea, aceleai probleme.
Protocolul TCP creeaz un serviciu de transfer sigur de date peste serviciul IP nesigur(de tip
best-effort). Multe protocoale de nivel aplicaie populare inclusiv FTP, SMTP, HTTP i Telnet
utilizeaz mai degrab TCP dect UDP n primul rnd pentru c protocolul TCP ofer un serviciu de
transfer sigur de date. Acest serviciu asigur faptul c fluxul de date pe care un proces l citete din
buffer-ul de recepie TCP nu este eronat, nu conine spaii goale, nu conine duplicate i este n ordine,
adic acest flux de octei este exact acelai cu fluxul de octei care a fost trimis de ctre sistemul gazd
aflat la cellalt capt al conexiunii. n aceast subseciune vom oferi o viziune informal asupra
modului n care protocolul TCP ofer transferul sigur de date. Vom vedea c serviciul de transfer sigur
de date al protocolului TCP utilizeaz multe dintre principiile prezentate n Seciunea 3.4.

Retransmisiile
Retransmisiile datelor pierdute sau eronate sunt cruciale pentru a oferi transferul sigur de date.
Protocolul TCP ofer transferul sigur de date utiliznd confirmri pozitive i contoare n aproape
acelai mod pe care l-am studiat n Seciunea 3.4. Protocolul TCP confirm datele care au fost
recepionate corect i retransmite segmente atunci cnd segmentele sau confirmrile lor
corespunztoare sunt pierdute sau eronate. La fel ca i n cazul protocolului de transfer sigur de date,
rdt3.0, protocolul TCP nu poate spune de unul singur dac un segment, sau confirmarea sa, este
pierdut, eronat, sau a ntrziat foarte mult. n toate aceste cazuri, rspunsul protocolului TCP va fi
acelai: retransmiterea segmentului n cauz.
Protocolul TCP utilizeaz de asemenea i transmisia n regim de band de asamblare,
permindu-i emitorului s aib mai multe segmente transmise dar nc neconfirmate la un anumit
moment de timp. Am vzut n seciunea precedent c aceast comunicare n regim conduct poate
mbunti rata de transfer a unei conexiuni TCP atunci cnd raportul dintre dimensiunea segmentului
i timpul dus-ntors este mic. Numrul exact de segmente transmise dar nc neconfirmate pe care le
poate avea un emitor este determinat de controlul fluxului TCP i mecanismele de control al
congestiei. Despre controlul fluxului TCP se va discuta la sfritul acestei seciuni; despre controlul
2
congestiei TCP se discut n Seciunea 3.7. Deocamdat, trebuie doar s tim c emitorul poate avea
mai multe segmente transmise, dar nc neconfirmate, la un anumit moment de timp.

/* presupunem c emitorul nu este constrns de controlul congestiei
sau al fluxului TCP, c datele provenite de la nivelul superior au
dimensiuni mai mici dect MSS i c transferul de date este
unidirecional */

sendbase = numrul de secven iniial /* vezi Figura 3.4-11 */
nextseqnum = numrul de secven urmtor

while (true) { /*bucla infinita*/
switch(eveniment)

eveniment:date primite de la o aplicaie de nivel superior
creeaz segmente TCP cu numrul de secven nextseqnum
pornete contorul pentru segmentul nextseqnum
trimite segmentul ctre IP
nextseqnum = nextseqnum + lungime(date)

eveniment:expirare contor pentru segmentul cu numrul de secven y
retransmite segmentul cu numrul de secven y
calculeaz un nou interval de timp pentru expirarea contorului
pentru segmentul y
repornete contorul pentru numrul de secven y

eveniment: primirea confirmrii, valoarea cmpului de confirmare fiind
y
dac (y > sendbase) { /* confirmare cumulativ a tuturor datelor
pn la y */
anuleaz toate contoarele pentru segmentele cu numerele de
secven < y
sendbase = y
}
altfel { /* o confirmare duplicat pentru un segment deja
confirmat */
incrementeaz numrul de confirmri duplicate recepionate
pentru y
dac (numrul de confirmri duplicate recepionate pentru y
== 3) {
/* retransmiterea TCP rapid */
retransmite segmentul cu numrul de secven y
repornete contorul pentru segmentul y
}
} /* sfritul buclei while*/

Figura 3.5-5: Emitorul TCP simplificat

Figura 3.5-5 ilustreaz cele trei evenimente majore legate de transmisia/retransmisia datelor
ntr-un emitor TCP simplificat. Fie o conexiune TCP ntre sistemele gazd A i B. S ne ndreptm
atenia asupra fluxului de date transmis de la sistemul gazd A ctre sistemul gazd B. La sistemul
gazd emitor (A), protocolul TCP primete date de nivel aplicaie pe care le ncapsuleaz n
segmente i le trimite mai departe protocolului IP. Transmiterea datelor de la nivelul aplicaie ctre
protocolul TCP i apoi ncapsularea i transmiterea unui segment este primul eveniment important de
care trebuie s se ocupe protocolul TCP. De fiecare dat cnd protocolul TCP trimite un segment ctre
protocolul IP, el pornete un contor pentru acel segment. Dac acest contor expir, se genereaz un
3
eveniment de ntrerupere pe sistemul gazd A. Protocolul TCP rspunde la evenimentul de expirare a
contorului, al doilea eveniment major pe care trebuie s-l trateze protocolul TCP de la emitor,
retransmind segmentul care a cauzat ntreruperea.
Al treilea eveniment major pe care trebuie s-l trateze protocolul TCP de la emitor este
sosirea unui segment de confirmare (ACK) de la receptor (mai exact, un segment care conine o
valoare valid a cmpului de confirmare). Aici, protocolul TCP de la emitor trebuie s determine
dac acea confirmare reprezint o prim confirmare pentru un segment pentru care emitorul nu a
primit nc o confirmare, sau este o aa-numit confirmare duplicat care reconfirm un segment pentru
care emitorul a primit deja o confirmare. n cazul recepionrii unei prime confirmri, emitorul tie
acum c toate datele pn la octetul care a fost confirmat au fost recepionate corect la receptor.
Emitorul poate astfel s-i actualizeze variabila de stare TCP care memoreaz numrul de secven al
ultimului octet despre care se tie c a fost recepionat corect i n ordine la receptor.
Pentru a nelege rspunsul emitorului la o confirmare duplicat, trebuie s vedem mai nti
de ce receptorul transmite o confirmare duplicat. Tabelul 3.5-1 rezum politica de generare a
confirmrilor din cadrul protocolului TCP de la receptor. Cnd un receptor TCP recepioneaz un
segment cu un numr de secven care este mai mare dect urmtorul numr de secven ateptat n
ordine, el detecteaz un spaiu gol n fluxul de date, adic un segment lips. Din moment ce protocolul
TCP nu utilizeaz confirmrile negative, receptorul nu poate transmite o confirmare negativ explicit
napoi ctre emitor. n schimb, el transmite o reconfirmare (genereaz o confirmare duplicat) pentru
ultimul octet de date primit n ordine. Dac protocolul TCP de la emitor primete trei confirmri
duplicate pentru aceleai date, el consider acest lucru ca fiind o indicaie a faptului c segmentul care
urmeaz segmentului care a fost confirmat de trei ori a fost pierdut. n acest caz, protocolul TCP
realizeaz o retransmitere rapid [RFC 2581], retransmind segmentul lips nainte de expirarea
contorului acelui segment.

Eveniment Aciunea protocolului TCP de la receptor
Sosirea n ordine a unui segment cu un numr
de secven ateptat. Toate datele pn la
numrul de secven ateptat sunt deja
confirmate. Nu exist spaii goale n datele
recepionate.
Confirmare ntrziat. Ateapt pn la 500ms
sosirea n ordine al unui alt segment. Dac
urmtorul segment n ordine nu sosete n acest
interval, trimite o confirmare.
Sosirea n ordine a unui segment cu un numr
de secven ateptat. Un alt segment n ordine
ateapt transmiterea confirmrii. Nu exist
spaii goale n datele recepionate.
Trimite imediat o singur confirmare cumulativ,
care s confirme ambele segmente n ordine.
Sosirea unui segment care nu este n ordine, cu Trimite imediat o confirmare duplicat, indicnd
4
un numr de secven mai mare dect cel
ateptat. Detectarea unui spaiu gol.
numrul de secven al urmtorului octet ateptat.
Sosirea unui segment care umple total sau
parial spaiul gol din datele recepionate.
Trimite imediat o confirmare, dac segmentul
ncepe n partea de jos a spaiului gol.
Tabelul 3.5-1: Recomandrile de generare a confirmrilor n cadrul protocolului TCP [RFC1122, RFC
2581]

Cteva scenarii interesante
Vom ncheia aceast discuie analiznd cteva scenarii simple. Figura 3.5-6 ilustreaz scenariul
n care sistemul gazd A trimite un segment ctre sistemul gazd B. S presupunem c acest segment
are numrul de secven 92 i conine 8 octei de date. Dup ce trimite acest segment, sistemul gazd A
ateapt un segment de la B avnd confirmarea cu numrul 100. Dei segmentul de la A este
recepionat la B, confirmarea de la B este pierdut. n acest caz, contorul expir i sistemul gazd A
retransmite acelai segment. Desigur, cnd sistemul gazd B recepioneaz retransmisia, el va observa
c a depozitat deja n buffer-ul de recepie octeii segmentului duplicat. Astfel protocolul TCP din
sistemul gazd B va ignora octeii din cadrul segmentului retransmis, ins va confirma nc o data
segmentul.

Figura 3.5-6: Retransmisia datorat unei confirmri pierdute

ntr-un al doilea scenariu, sistemul gazd A transmite dou segmente unul dup altul. Primul
segment are numrul de secven 92 i 8 octei de date i al doilea segment are numrul de secven
100 i 20 octei de date. S presupunem c ambele segmente sosesc intacte la B i B trimite dou
confirmri separate pentru fiecare dintre segmente. Prima dintre aceste confirmri are numrul de
confirmare 100; a doua are numrul de confirmare 120. S presupunem acum c nici una dintre cele
Sistemul
gazd B
Timp
Timp
Sistemul
gazd A

Expirarea
contorului
Ignor continutul
segmentului
5
dou confirmri nu ajunge la sistemul gazd A nainte de expirarea contorului pentru primul segment.
Cnd contorul expir, sistemul gazd A retransmite primul segment cu numrul de secven 92. Acum,
v putei ntreba, oare A retransmite i cel de-al doilea segment? Conform regulilor descrise mai sus,
sistemul gazd A retransmite segmentul doar dac expir contorul nainte de sosirea unei confirmri cu
un numr de confirmare mai mare sau egal cu 120. Astfel, aa cum este ilustrat n Figura 3.5-7, dac
cea de-a doua confirmare nu este pierdut i sosete nainte de expirarea contorului pentru cel de-al
doilea segment, A nu retransmite cel de-al doilea segment.
Figura 3.5-7: Segmentul nu este retransmis deoarece confirmarea sa este primit nainte de expirarea
contorului
ntr-un al treilea i ultim scenariu, s presupunem c sistemul gazd A transmite dou
segmente, exact ca n exemplul doi. Confirmarea pentru primul segment este pierdut n reea, dar
chiar nainte de expirarea contorului pentru primul segment, sistemul gazd A primete o confirmare
cu numrul de confirmare 120. Sistemul gazd A tie astfel c sistemul gazd B a recepionat totul
pn la octetul 119; astfel sistemul gazd A nu retransmite nici unul dintre cele dou segmente. Acest
scenariu este ilustrat n Figura 3.5-8.


Sistemul
gazd A

Sistemul
gazd B
Timp
Timp
E
x
p
i
r
a
r
e

s
e
q
=
1
0
0

E
x
p
i
r
a
r
e

s
e
q
=
9
2

6

Figura 3.5-8: O confirmare cumulativ evit retransmisia primului segment

S ne amintim c n seciunea precedent am spus c protocolul TCP este un protocol de tip
Go-Back-N, deoarece confirmrile sunt cumulative i segmentele corect recepionate, dar care nu sunt
n ordine nu sunt confirmate individual de ctre receptor. n consecin, aa cum este ilustrat n Figura
3.5-5 (vezi de asemenea i Figura 3.4-11), emitorul TCP trebuie s pstreze numai cel mai mic
numr de secven al unui octet transmis dar nc neconfirmat (sendbase) i numrul de secven al
urmtorului octet care trebuie transmis (urmsecvnum). Dar cititorul nu trebuie s uite c dei
componenta protocolului TCP care se ocup cu transferul sigur de date seamn cu cea a protocolului
Go-Back-N, ea nu este deloc o pur implementare a protocolului Go-Back-N. Pentru a vedea c exist
cteva diferene notabile ntre protocoalele TCP i Go-Back-N, s vedem ce se ntmpl cnd
emitorul transmite o secven de segmente 1,2,,N i toate segmentele sosesc n ordine, fr erori la
recepie. Mai mult, s presupunem c mesajul de confirmare pentru pachetul n < N se pierde, dar cele
N-1 confirmri rmase sosesc la emitor nainte de expirarea contoarelor corespunztoare. n acest
exemplu, protocolul Go-Back-N va retransmite nu numai pachetul n, dar i toate pachetele n+1,
n+2,,N. Protocolul TCP, pe de alt parte, va retransmite cel mult un segment, adic segmentul n.
Mai mult dect att, protocolul TCP nici mcar nu va retransmite segmentul n dac mesajul de
confirmare pentru segmentul n+1 sosete nainte de expirarea contorului pentru segmentul n.
Au existat de curnd mai multe propuneri [RFC 2018, Fall 1996, Mathis 1996] de extindere a
schemei de confirmri a protocolului TCP pentru a fi mai similar cu un protocol cu repetare selectiv.
Ideea de baz a acestor sugestii este s ofere emitorului o informaie explicit despre care segmente
au fost corect recepionate i care lipsesc nc la receptor.

3.5.6 Controlul fluxului

Sistemul
gazd A
Sistemul
gazd B
Timp Timp
E
x
p
i
r
a
r
e
a

c
o
n
t
o
r
u
l
u
i

7
S ne amintim c sistemele gazd care particip la o conexiune TCP rezerv fiecare cte un
buffer de recepie pentru acea conexiune. Cnd conexiunea TCP recepioneaz octei care sunt coreci
i n ordine datele sunt plasate n buffer-ul de recepie. Procesul de nivel aplicaie corespunztor va citi
datele din acest buffer, dar nu neaprat chiar n momentul n care sosesc datele. Aplicaia de la recepie
poate fi ocupat cu o alt sarcin i este posibil ca nici mcar s nu ncerce s citeasc datele dect
dup mult timp dup ce acestea au sosit. Dac aplicaia este relativ lent la citirea datelor, emitorul
poate foarte uor s suprancarce buffer-ul de recepie trimind multe date ntr-un interval foarte scurt
de timp. Protocolul TCP ofer astfel un serviciu de control al fluxului pentru aplicaiile sale
eliminnd posibilitatea ca emitorul s suprancarce buffer-ul de recepie. Controlul fluxului este
astfel un serviciu de autoreglare a vitezelor potrivirea ratei cu care transmite emitorul cu rata la
care citete aplicaia de la recepie. Aa cum am menionat mai devreme, un emitor TCP poate de
asemenea s fie ncetinit datorit congestiei din reeaua IP; aceast metod de control al emitorului
este numit controlul congestiei, un subiect pe care l vom detalia n Seciunile 3.6 i 3.7. n timp ce
aciunile ntreprinse de controlul fluxului i controlul congestiilor au un efect similar (ncetinirea
emitorului), cauzele care le determin sunt diferite. Din nefericire, muli autori folosesc termenul
interschimbabil i cititorul trebuie s fie atent pentru a face distincia ntre cele dou cazuri. S
discutm acum modul n care protocolul TCP ofer serviciul su de control al fluxului.
Protocolul TCP ofer controlul fluxului determinnd emitorul s pstreze o variabil numit
fereastr de recepie. Informal, fereastra de recepie este utilizat pentru a oferi emitorului o idee
despre ct de mult spaiu este disponibil n buffer-ul de recepie. ntr-o conexiune full-duplex,
emitorul de la fiecare capt al conexiunii pstreaz o fereastr de recepie distinct. Fereastra de
recepie este dinamic, adic ea se schimb pe durata unei conexiuni. S analizm acum fereastra de
recepie n contextul transferului unui fiier. S presupunem c sistemul gazd A transmite un fiier de
dimensiuni mari sistemului gazd B printr-o conexiune TCP. Sistemul gazd B aloc un buffer de
recepie acestei conexiuni; notm dimensiunea lui cu BufferRec. Din cnd in cnd, procesul de nivel
aplicaie din sistemul gazd B citete din buffer. Definim urmtoarele variabile:

UltimulOctetCitit = numrul ultimului octet citit din fluxul de date de ctre procesul de
nivel aplicaie de pe sistemul gazd B
UltimulOctetRecepionat = numrul ultimului octet din fluxul de date care a sosit din reea
i a fost plasat n buffer-ul de recepie n sistemul gazd B
Deoarece protocolul TCP nu permite suprancarcarea buffer-ului alocat, trebuie s fie
ndeplinit urmtoarea condiie:

UltimulOctetRecepionat UltimulOctetCitit <= BufferRec

Fereastra de recepie, notat FereastraRec, este setat la dimensiunea spaiului liber disponibil
din buffer:
8

FereastraRec = BufferRec [UltimulOctetReceptionat - UltimulOctetCitit]

Deoarece spaiul disponibil se schimb n timp, FereastraRec este dinamic. Variabila
FereastraRec este ilustrat n Figura 3.5-9.


Figura 3.5-9: Fereastra de recepie (FereastraRec) i buffer-ul de recepie (BufferRec)

Cum folosete conexiunea variabila FereastraRec pentru a oferi serviciul de control al
fluxului? Sistemul gazd B informeaz sistemul gazd A despre ct de mult spaiu liber are disponibil
n buffer-ul de conexiune, punnd valoarea curent a FereastraRec n cmpul de fereastr al fiecrui
segment pe care l trimite ctre A. Iniial, gazda B seteaz FereastraRec = BufferRec. Observm
c, pentru a reui acest lucru, sistemul gazd B trebuie s in evidena ctorva variabile specifice
conexiunii.
Sistemul gazd A ine pe rnd evidena a dou variabile, UltimulOctetTransmis i
UltimulOctetConfirmat, care au roluri evidente. Observm c diferena dintre aceste dou variabile,
UltimulOctetTransmis UltimulOctetConfirmat, reprezint volumul de date neconfirmate pe
care A le-a trimis pe conexiune. Meninnd volumul de date neconfirmate mai mic dect valoarea
variabilei FereastraRec, sistemul gazd A se asigur c nu va umple buffer-ul de recepie al
sistemului gazd B. Astfel, pe durata conexiunii, sistemul gazd A se asigur c:

UltimulOctetTransmis UltimulOctetConfirmat <= FereastraRec

Exist o mic problem tehnic a acestei scheme. Pentru a vedea acest lucru, s presupunem c
buffer-ul de recepie al sistemului gazd B se umple, astfel nct FereastraRec = 0. S presupunem
c dup ce avertizeaz sistemul gazd A ca FereastraRec = 0, sistemul gazd B nu mai are nimic de
transmis ctre A. Pe msur ce procesul de nivel aplicaie din sistemul gazd B golete buffer-ul,
protocolul TCP nu transmite noi segmente cu noua valoare a variabilei FereastraRec ctre sistemul
gazd A protocolul TCP va trimite un segment ctre sistemul gazd A doar dac are date sau o
confirmare de transmis. Aadar, sistemul gazd A nu va fi informat c s-a eliberat spaiu n buffer-ul
de recepie al lui B: sistemul gazd A este blocat i nu mai poate transmite date! Pentru a rezolva
aceast problem, specificaiile protocolului TCP cer ca sistemul gazd A s continue s transmit
FereastraRec
BufferRec

Date
de la IP
Procesul de
nivel
aplicaie
Spaiu liber

Date TCP
din buffer
9
segmente cu un singur octet de date cnd fereastra de recepie a lui B este zero. Aceste segmente vor fi
confirmate de receptor. La un moment dat buffer-ul va ncepe s se goleasc i confirmrile vor
conine o variabil FereastraRec diferit de zero.
Dup ce am descris serviciul de control al fluxului oferit de ctre protocolul TCP, menionm
pe scurt aici faptul c protocolul UDP nu ofer controlul fluxului. Pentru a nelege aceast problem,
s presupunem transmiterea unei serii de segmente UDP de la un proces care ruleaz pe sistemul gazd
A ctre un proces care ruleaz pe sistemul gazd B. Pentru o implementare UDP tipic, protocolul
UDP va pune segmentele (mai exact, datele din segmente) n ateptare ntr-o coad de dimensiuni
finite care precede socket-ul (adic ua ctre proces) corespunztor. Procesul citete pe rnd cte un
segment din coad. Dac procesul nu va citi segmentele din coad ndeajuns de repede, coada se va
umple i unele segmente vor fi pierdute.

3.5.7 Timpul dus-ntors i timpul de expirare a contorului

S ne amintim c atunci cnd un sistem gazd transmite un segment TCP ntr-o conexiune, el
pornete un contor. Dac acel contor expir nainte ca sistemul gazd s primeasc o confirmare pentru
datele din segment, atunci sistemul gazd va retransmite segmentul. Timpul care se scurge din
momentul n care este pornit contorul pn cnd acesta expir se numete timpul de expirare a
contorului. O ntrebare normal este ct de mare ar trebui s fie acest timp? n mod evident, timpul de
expirare ar trebui s fie mai mare dect timpul dus-ntors al conexiunii, adic timpul care se scurge din
momentul n care este transmis un segment pn cnd acesta este confirmat. Altfel, ar avea loc
retransmisii care nu sunt necesare. Dar timpul de expirare nu ar trebui s fie cu mult mai mare dect
timpul dus-ntors; altfel, atunci cnd un segment este pierdut, protocolul TCP nu ar retransmite repede
segmentul, introducnd astfel ntrzieri semnificative n transferul datelor n cadrul aplicaiei. Mai mult
dect att media si variana distribuiei sosirii confirmrilor se poate schimba cu rapiditate pe parcursul
a ctorva secunde atunci cnd apare sau se rezolv o congestie. nainte de a discuta mai detaliat despre
timpul de expirare, s studiem cu atenie timpul dus-ntors (eng. round trip time RTT). Discuia de
mai jos este bazat pe lucrarea despre protocolul TCP din [Jacobson 1988].

Estimarea timpului dus-ntors mediu
Soluia este s se utilizeze un algoritm profund dinamic, care ajusteaz in mod constant
intervalul de expirare al contorului bazndu-se pe msurtori continue ale performanei reelei.
Eantion RTT, notat EsantionRTT, pentru un segment reprezint intervalul de timp din
momentul n care un segment este transmis (adic trimis ctre IP) pn cnd se recepioneaz o
confirmare pentru acel segment. Fiecare segment va avea propriul sau EsantionRTT. n mod evident,
valorile EsantionRTT vor varia de la segment la segment datorit congestiilor din router-e i gradului
10
de ncrcare a sistemelor capt. Datorit acestei variaii, o oarecare valoare a EsantionRTT poate fi
atipic. Pentru a putea estima o valoare tipic pentru RTT, este normal s se considere un fel de medie
a valorilor EsantionRTT. Protocolul TCP pstreaz o medie, numita EstimatRTT, a valorilor
EsantionRTT. Dup ce primete o confirmare i obine o nou valoare a EsantionRTT, protocolul TCP
actualizeaz valoarea lui EstimatRTT dup formula:

EstimatRTT = (1-x) EstimatRTT + x EsantionRTT

Formula de mai sus este scris sub forma unei expresii dintr-un limbaj de programare noua
valoare a lui EstimatRTT este o combinaie ponderat a valorii anterioare a lui EstimatRTT i noua
valoare a lui EsantionRTT. x este un factor de netezire care determin ponderea dat vechii valori. O
valoare tipic pentru x este x = 0.1, i n acest caz formula de mai sus devine:

EstimatRTT = 0.9 EstimatRTT + 0.1 EsantionRTT

Observm c EstimatRTT reprezint o medie ponderat a valorilor EsantionRTT. Aa cum
vom vedea n tem, aceast medie ponderat ine cont mai mult de noile valori dect de vechile valori.
Acest lucru este normal, din moment ce valorile mai noi reflect mai bine congestia curent din reea.
n domeniul statisticii, acest gen de medie este numit medie ponderat exponenial variabil
(exponential weighted moving average - EWMA). Cuvntul exponenial apare n EWMA deoarece
ponderea unei anumite EsantionRTT scade exponenial de repede pe msur ce apar actualizrile. n
problemele din tem vi se va cere sa derivai termenul exponenial din EstimatRTT.

Setarea timpului de expirare a contorului
Timpul de expirare a contorului ar trebui s fie setat astfel nct acesta s expire devreme (adic
nainte de sosirea ntrziat a unei confirmri pentru un segment) numai n situaii rare. Este deci
normal ca timpul de expirare sa fie setat egal cu EstimatRTT plus anumite intervale. Intervalele ar
trebui s fie mari cnd exist multe variaii n valorile EsantionRTT; intervalele ar trebui s fie mici
cnd exist puine variaii. Protocolul TCP utilizeaz urmtoarea formul:

TimpulDeExpirare = EstimatRTT + 4*Deviaia

unde Deviaia reprezint o estimare a ct de mult difer MostraRTT de EstimatRTT:

Deviaia = (1-x) Deviaia + x | EsantionRTT EstimatRTT |

Observm c Deviaia reprezint o medie ponderat exponenial variabil a ct de mult
difer EsantionRTT de EstimatRTT. Dac valorile EsantionRTT au variaii mici, atunci Deviaia
este mic i TimpulDeExpirare este doar puin mai mare dect EstimatRTT; pe de alt parte, dac
11
variaiile sunt mari, Deviaia va fi mare i TimpulDeExpirare va fi mult mai mare dect
EstimatRTT.
O problem legat de estimarea dinamic a RTT se refer la ce trebuie fcut in situaia in care
un segment cauzeaz o depire i trebuie retransmis. Atunci cnd se primete confirmarea pentru un
segment retransmis nu este clar dac aceasta se refer la prima transmisie sau la o retransmisie
ulterioar. O decizie eronat poate afecta serios estimarea lui RTT. Soluia este simpl si anume s nu
se actualizeze RTT pentru nici un segment retransmis. Daca pentru un anumit segment nu se primete
confirmarea in intervalul specificat acesta va fi retransmis iar TimpulDeExpirare se dubleaz la fiecare
eec pn segmentele ajung la destinaie de la prima transmisie. Aceasta corecie este denumita
algoritmul lui Karn.