1. El protocol TCP a fons

1.1. Protocol de Control de la Transmissió (repàs)(Aquest apartat no es penja)
1.2. Timeouts i retransmissions
1.3. Resposta a la congestió
1.4. Finestres menguants
1.5. Millores de TCP i rendiment

1.2.TIMEOUTS I RETRANSMISSIONS

()

La idea principal del TCP radica en las variables de timeout i en los algoritmos de retransmisiones que se usan en sus comunicaciones. Este protocolo es diferente de los otros protocolos de redes debido a su origen. TCP es un protocolo creado para la Internet, y es por ello que a de tener unas características muy especiales. Estas características se deben principalmente a que Internet es un medio muy hostil, en donde puede haber pérdidas de paquetes, maquinas caídas, congestiones u otros impedimentos que no dejen llegar los paquetes a su destino.

La idea del timeout es algo muy sencillo: TCP envía un timer cada vez que envía un segmento y si no recibe confirmación de que ese segmento a llegado a su destino, antes de que ese timer se agote, se vuelve a enviar el mismo segmento. Si por el contrario se recibe la confirmación de que el segmento a llegado con éxito antes de que se acabe su timer, se pasa a enviar el siguiente segmento.

Pero cómo calcular que timeout se ha de aplicar a cada comunicación? De esto se encarga un algoritmo de retransmisión adaptativo. Esto quiere decir que TCP ajusta constantemente el valor del timeout en función del feedback que obtiene de sus comunicaciones. Este feedback se hace para cada conexión que se establece, de modo que según el estado de cada conexión, el timeout aplicado a esta cambiará. Para crear el valor de este timeout, se calcula cual es la diferencia de tiempo entre el momento en que se envía un segmento, y el momento en que recibe su confirmación (ACK). A este valor se le llamará roundtrip (RTT --> Round Trip Time). A medida que la comunicación vaya sucediendo, este valor podrá ir cambiando según cómo se encuentre la red en ese momento. Este cambio dinámico se consigue haciendo una media ponderada de los diferentes RTT que se van obteniendo. Así, si una comunicación comienza a perder paquetes (no recibe confirmación por parte del receptor), se irá incrementando el RTT para ver si es un problema de congestión de la red.

Para obtener el RTT se empezó usando una sencilla formula:

• RTTcalulado = (alfa * antiguoRTT) + ((1 – alfa) * nuevoRTT)

En esta formula, alfa esta comprendida entre cero y uno. Así, según el valor que le diéramos a alfa, el RTT calculado cambiaría más o menos según los RTT puntuales de la comunicación. Con un alfa cercano a uno el RTTcalculado sería poco propenso a los nuevos cambios, mientras que con un alfa cercano a cero, cambiaría mucho con los nuevos RTT recibidos.

Pero una vez tenemos el RTT hay que calcular el timeout, y para ello tenemos la formula:

• Timeout = Beta * RTT

en donde Beta ha de ser mayor que uno. En este caso si Beta es cercano a uno, se detectaran rápidamente las perdidas de paquetes, pero por el contrario se retransmitirían muchos paquetes (por el reenvío) y se ampliaría rápidamente el ancho de banda usado.

• Según la especificación TCP el valor de Beta será 2.

Cómo calcular las muestras de RTT?

Hasta aquí parece todo muy sencillo, pero es ahora cuando empiezan los problemas. Como ya se ha comentado en cursos anteriores, TCP utiliza un esquema de confirmación acumulativo de flujo de datos, no de datagramas específicos, lo que nos lleva al problema de la ambigüedad de la confirmación. Este problema se da cuando el emisor no ha obtenido confirmación de la recepción de un paquete, y lo vuelve a enviar. Entonces si que recibe la confirmación del receptor, pero no sabe si es la confirmación al primer paquete que ha enviado, o del segundo, que es una copia exacta del primero. Cualquiera de las dos suposiciones que puede tomar, son perjudiciales para la comunicación:

• Si tomamos como buena la confirmación del primer paquete enviado y siguen habiendo perdidas, el RTT irá creciendo continuamente, lo que generará que los sucesivos RTTs también crezcan, así cómo el timeout.
  
  

• Si por el contrario tomamos como buena la confirmación del último paquete enviado, y hay un pequeño colapso en la red, el timeout se agotará antes de recibir la contestación y el paquete será enviado de nuevo. Así, si ahora si que se recibe confirmación, se asumirá que ha sido del último envío, con lo que el RTT se hará más pequeño y el timeout también. Con ello nos continuaremos encontrando con el mismo problema.

Así pues, cual es la medida que debemos tomar ante un caso como el de la ambiguidad de la confirmación? La respuesta es el algoritmo de Karn.

ALGORITMO DE KARN

El algoritmo de Karn se rige por una regla muy sencilla: solo permite actualizar el RTT con las confirmaciones no ambiguas. Esto nos permitirá poder superar con éxito el problema arriba expuesto, pero nos generará otro de nuevo. Si siempre hay confirmaciones ambiguas, el RTT no se actualizará y seguiremos teniendo problemas de timers. Así pues el algoritmo de Karn se ha de combinar con una estrategia de backoff del timeout. Con esta estrategia lo que se hace es incrementar el timeout con cada retransmisión que se efectúe (llegando a un máximo de 120 segundos). Una vez le llega al emisor la confirmación de su paquete, este vuelve a poner el timer a su estado original. Si el timeout alcanza esta cifra máxima de 120 segundos, ya no aumentará y se seguirá usando hasta que el paquete llegue con éxito. Así pues, el nuevo timeout se calculará con la fórmula:

• Timeout Nuevo = Gama * Timeout (donde normalmente Gama = 2)

Así pues, resumiendo, podemos decir que el algoritmo de Karn combina una estimación usando únicamente las confirmaciones no ambiguas y un Backoff del timeout cuadrático.

A titulo de nota, se ha de decir que este mecanismo varía según la implementación del sistema operativo.

()

Todos los mecanismos explicados hasta ahora parten de la base de considerar una variancia en los retrasos pequeña y constante, pero esto no es fiel a la realidad, ya que pueden darse grandes variaciones.

Según aumenta la carga de la red, se produce un aumento del RTT, pero lo que es más "grave" es que la variancia Õ del RTT crece mucho más!!, siguiendo una proporción 1 / (1-L) siendo L la carga de la red 0<=L<=1

Con estas nuevas consideraciones, es facil observar que la adaptación RTO = ß x RTT, con ß=2 que habíamos explicado hasta ahora no es suficiente en muchos casos. Se ha podido constatar que a partir de una carga de red del 30%, dicha adaptación deja de funcionar correctamente, ya que al presuponer que las confirmaciones llegaran y una vez pasado el timeout, se retransmite el segmento, lo que aumenta aún más la carga de la red y se contribuye a aumentar la congestión de la red.

Para evitar estos problemas se ha tenido en cuenta la estimación tanto de la variancia como del RTT en la nueva especificación de TCP. Donde la estimación de la variancia pasará ejercer de ß, consiguiendo así que el throughtput de TCP aumente de forma considerable.

ALGORITMO DE JACOBSON

Para calcular un tiempo de timeout que se adapte a condiciones de carga alta, se aprovecha la estimación de la variancia del RTT:[[BR]]

• SRTT = RTT + Õ * ( RTTm - RTT )
  Dev(RTT) = Devo + p * ( | RTTm - RTT | - Devo( RTT ) )
  RTO = SRTT + η * Dev( RTT )
  
  

  • SRTT: representa el RTT de variación suave (Smooth RTT).
    Õ: cómo afecta el nuevo RTT; 0 ≤ Õ ≤ 1
    p: velocidad de adaptación de la variación; 0 ≤ p ≤ 1
    η: cómo la variación afecta al timeout
    Dev( RTT ): se le suele llamar jitter.
    Para que los cálculos sean rápidos loa valores de Õ i P suelen ser inversos de potencias de 2, así se pueden realizar con desplazamientos de bits. Empíricamente se han calculado estos valores, que son los sugeridos: Õ = 1/8 , p = 1/4 y η = 2,3,4.
    
    

Veamos dos posibles situaciones:

• Si no hay muchos cambios entre el RTT de muestra y el RTT estimado, el SRTT y el RTT són muy parecidos durante bastante tiempo y el Dev(RTT) tenderá a acercarse al 0, lo que conllevará que el SRTT sea una buena estimación del RTO.
  
  

• Si hay muchos cambios entre el RTT de muestra y el RTT estimado, el algoritmo "no lo tiene en cuenta", es decir, que "desconfía" de que dichos cambios vayan a prolongarse en el tiempo y deja un margen grande, proporcional a la incerteza sobre los cambios.
  
  

Ahora podemos ver dos gráficas comparativas de funcionamiento entre el algoritmo original y usando el algoritmo de Jacobson:[[BR]]

• ALGORITMO ORIGINAL
  ALGORITMO DE JACOBSON

Como se puede ver en las gráficas, mientras que el algoritmo original no es capaz de dar una respuesta rápida y al RTO le cuesta tanto subir como luego bajar. Mediante el algoritmo de Jacobson se detecta rápidamente el cambio y el RTO se incrementa y disminuye a tiempo, consiguiendo una mejora de eficiencia considerable.
Hay que hacer notar que si el RTO es menor que el RTT se produce una retransmisión innecesaria.

TEMPORIZADOR DE KEEPALIVE

Pueden existir conexiones TCP en las cuales no se esten intercambiando datos (idle), es decir que no circule ni un sólo segmento. Si esto lo unimos al hecho de que ubna conexión puede estar abierta durante meses, nos encontramos ante un problema: ¿Como podemos saber que la conexión sigue viva? Es decir, que durante el tiempo que la conexión ha estado abierta sin ningún intercambio de segmentos, pueden haberse producido cambios de routers, pueden haberse producido cambios de lineas telefónicas, etc.
En definitiva, no podemos saber si la conexión TCP sigue viva, si no existe por cambios en la red o si el otro extremo la ha dado por finalizada y no nos ha llegado la notificación, con el consiguiente riesgo de mantener esa conexión como ficticiamente viva para siempre (no hay mecanismos de polling).

Así que, aunque son las aplicaciones las encargadas de detectar cuál es el estado del otro extremo de la conexión. Algunas implementaciones de TCP incorporan un sistema para poder hacer esta detección, un temporizador de keepalive.

En realidad, como ya hemos indicado, los keepalive no son parte de la especificación de TCP, porque presentan algunos problemas:

• Fallos temporales producidos durante una conexión buena pueden provocar su cierre, perdiendo así la conexión buena.
  
  

• Implican un consumo de ancho de banda innecesario.
  
  

• Como consecuencia del envío de datos, tienen un coste monetario en caso de que el proveedor de Internet nos facture por datagrama.
  
  

Por otro lado, los keepalive son muy eficientes cuando los cleintes no están siempre encendidos, como PCs, portátiles, PDAs. Los cuales pueden "apagarse" dejando conexiones abiertas que no se cerrarían jamás. Gracias a los keepalive estas conexiones serán cerradas.

FUNCIONAMIENTO DEL KEEPALIVE

Si el servidor detecta que una conexión ha estado 2 horas abierta sin ningún tipo de actividad, hace una prueba de la conexión, es decir, envía un segmento de sondeo. Se pueden dar 4 diferentes casos:

• Que el cliente esté conectado y la conexión tenga que seguir viva. El cleinte contestará al servidor y éste volverá a sondearlo después de 2 horas de inactividad.
  
  

• Que el cliente no esté conectado, la conexión tiene que acabar. El servidor enviará hasta 10 segmentos de sondeo cada 75 segundos para cerciorarse que el cliente no está conectado y la conexión tiene que acabar.
  
  

• Que el cleinte esté conectado, pero no le lleguen los segmentos de sondeo del servidor. La conexión tiene que acabar, porque aunque el cliente esté conextado, hay un error en la conexión que la hace inalcanzable. El servidor repetirá los pasos del caso anterior.
  
  

• Que el cleinte haya rebotado. Enviará un mensaje de reset al servidor.
  
  
  

Fuentes:

• Apuntes de la asignatura.

  http://www.redeweb.com/microbit/articulos/660603.pdf http://www.it.uc3m.es/celeste/docencia/inf/rroo0405/traspas/clase191004/tcp_3.pdf

índex

1.3. RESPOSTA A LA CONGESTIÓ

(DanielMartín)

TCP no només considera endarreriments entre els punts finals de la connexió: també reacciona a la congestió de la internet.

Congestió: Condició d'endarreriments importants causada per una sobrecàrrega de datagrames en un o més elements de commutació (p.e. routers).

Si hi ha congestió, l'endarreriment augmenta i els datagrames fan cua al router mentre aquest els pugui mantenir -tenen memòria limitada-.

Des de TCP només és possible apreciar els endarreriments. S'ignoren totalment les causes.

Si quan hi ha congestió tothom reenvia els segments sense confirmació es produiria encara més congestió, fins al col·lapse!!

TCP pot ajudar a disminuir la congestió aplicant mecanismes i estratègies d'enviament de dades que disminueixin la probabilitat de sobrecàrrega de la xarxa i que permetin la seva recuperació.

S'ha d'anar amb molt de compte per a evitar detectar com congestions variacions grans del RTT que han estat degudes a un altre motiu, ja que a Internet hi ha variacions molt grans en els RTT.

Si hi ha congestió no és bona idea enviar un flux de dades massa gran (la probabilitat de que no arribi serà proporcional a la mida).

A més de la finestra d'emissió, TCP ha de mantenir una finestra de congestió per a reduir el flux de dades per sota de la finestra lliscant quan hi ha congestió.

Inicialment, i si no hi ha congestió, el tamany d'aquestes dues finestres és el mateix. Només es podran enviar dades de la finestra permesa:

• F.Permesa = min( F.Anunciada, F.Congestió)
  

• Exemple de tranmissió entre un host lent i un de ràpid:

  • 

TCP assumeix que la pèrdua de datagrames és causada per congestió.

L'estàndard de TCP recomana tres tècniques molt fàcils d'implementar:

• 
  

• Decrement multiplicatiu: Si hi ha pèrdua divideix per dos la finestra de congestió (com a mínim serà d'un segment). Pels que queden, augmenta el RTO exponencialment.
  

  • - El seu objectiu es reduir el tràfic per a donar temps a que es redueixin les cues als routers.
    - El problema escau ara en que quan començem a retransmetre augmentem la velocitat massa ràpid. Cal algun mecanisme per a recuperar-se després d'una congestió sense col·lapsar el router de seguida. Per això tenim la següent tècnica:
    

  
  

• Començament lent: Per a començar el tràfic en una nova connexió, o per a incrementar el tràfic després d'una congestió, s'utilitza aquest mecanisme.
  

  • - Es posa la finestra de congestió a un sol segment.
    - S'incrementa en un segment cada vegada que arriba una confirmació.
    - El seu objectiu es evitar col·lapsar la xarxa tot just comencem a enviar un flux de dades, o després d'una congestió.
    - Deprés del SYN+ACK en l'establiment de connexió, ja podrem enviar 2 segments. Quan arribin les seves confirmacions, 4 segments més, i així succesivament.
    - Normalment amb 4 RTT (15 segments) és suficient per a arribar a la mida de la finestra anunciada.
    

    • Un exemple de funcionament amb començament lent seria:

      

    
    

• Fase d'evitar congestió: TCP entra en aquesta fase si la finestra de congestió baixa fins la meitat.
  

  • - Només s'incrementa la finestra de congestió si tots els segments de la finestra han estat confirmats.
    - Els mecanismes descrits: Decrement multiplicatiu, Començament lent i Fase d'evitar congestió, juntament amb el Backoff del timeout (Karn) i la Mesura de la variació (Jacobson), milloren el rendiment de TCP de manera molt significativa (de 2x fins a 10x!!) sense afegir massa computació addicional.
    

  
  
  

S'han anat afegint modificacions i altres algorismes per a evitar la congestió:

• Algorisme de retransmissió ràpida: Si rebem tres o més confirmacions s'assumeix que el segment s'ha perdut.
  

  • - S'envia el segment que sembla haver-se perdut, sense esperar el timeout.
    - Tot just després es comença l'evitament de congestió, però no el començament lent (slow start). Això es coneix com l' algorisme de recuperació ràpida.
    

    • Un exemple del seu funcionament seria:

      

    • Amb els ACK 1025 repetits ens adonem que el paquet amb número de seqüència 1025 s'ha perdut i no esperem un timeout per retransmetre aquell paquet.
      

CUES

Encara que les capes de protocols siguin independents les unes de les altres, els comportaments d'uns protocols afecten d'altres en molts casos.

Pel disseny de nous mecanismes en un protocol, tots els altres protocols de la resta de capes han de ser reconsiderats també!!

La interacció més important entre IP i TCP és deguda a la gestió de les cues d'IP.

Un router tria el camí que ha de seguir un datagrama segons els mecanismes que hem anat veient. Mentres un datagrama és processat, la resta de datagrames que arriben esperen fent "cua".

Donat que la memòria dels routers no és infinita, caldrà una política de gestió de cues específica per a determinar què es fa si arriben més datagrames dels que caben a la cua (quins es descarten).

Les polítiques més habituals són:

• Política Tail drop: Es descarten els datagrames que arriben si la cua ja està plena (es llença la cua). També s'anomena pfifo (per datagrames) o bfifo (per bytes).
  

  • - Problema: Sincronització global. Es perden els datagrames de N connexions, i totes entren en començament lent al mateix temps.
    - L'únic paràmetre d'aquesta política és el tamany de la cua.
    

Fonts:

• Apunts de clase.
  http://hmyblog.vmmatrix.net/lna/0131777203_ch24lev1sec4.html#ch24lev2sec10
  http://www.isoc.org/inet2000/cdproceedings/2d/2d_2.htm
  

(/ DanielMartín)

(DavidSánchez)

• Política de Random Early Discard (RED): Per evitar els problemes del Tail Drop, anteriorment explicats per DanielMartín ("Sincronització global. Es perden els datagrames de N connexions, i totes entren en començament lent al mateix temps") ¹ , s'utilitza aquesta política de gestió de cues.
  Aquesta política per evitar el problema de la sincronització global el que fa és descartar alguns datagrames abans d'arribar a la capacitat màxima de la cua gestionada.
  En aquesta política, existeixen 3 components, la capacitat, T_min i T_max, els quals són els límits de la cua, que seran responsables del comportament de la cua juntament amb la seva mida acutal.
  El comportament de la cua a l'arribada d'un nou datagrama en realció a la posició en que ocupa aquesta es regeix per:

  • - T_min > #datagrames ==> el datagrama s'afegeix a la cua.
    - T_max < #datagrames ==> el datagrama es descarta.
    - T_min < #datagrames < T_max==> el datagrama es descarta segons una probabilitat p.
    

  Vist això podem dir que RED simula la congestió abans de que es produeixi per no tenir la obligació de descartar els últims datagrames que li arribin.
  Per el bon funcionament d'aquesta política de gestió ha de tenir uns valors de T_min,#datagrames i T_max adecuats ("La clau per a que RED funcioni bé és triar uns bons valors per T_min, T_max i p") ² . Un valor bo és aquell que cumpleix les següents consideracions:

  1. T_min: Gran per provocar una bona utilització de l'enllaç.

  2. T_max: Ha de ser més gran que 2 vegades T_min (increment habitual durant un RTT).

  3. p: És el més complexe de tot el procés. Aquest valor de p es diferent per a cada datagrama. Aquest valor dependrà del tamany de la cua(T_min i T_max) seguint una distribució linial entre 0 i 1 com mostra la gràfica i aplicant una certa modificació per poder-lo usar:
     

• Si apliquèssim "literalment" la distribució que mostrem en la gràfica, implicaria una alta probabilitat d'eliminació dels últims segments d'una ràfaga, cosa que seria important que no passes a la vegada que s'eliminèssin els que acaben d'omplir la cua.
  Per solucionar el problema, es pot fer com en TCP, es a dir, mantenir un promig de la cua a l'hora de calcular les probabilitats.
  Per calcular l'estimació de la mida se segueix la següent fórmula:

• Per un valor pertit de gamma el promig reflexa els canvis que duren, però és inmune a les ràfagues.
  Per poder implementar la cua s'ha de tenir en compte que la mida d'aquesta no és el nombre de datagrames sinó que es fa servir la seva mida, es a dir, la mida del datagrama per a l'estimació de la mida. Els datagrames de major tamany tindran una probabilitat més alta de ser descartats ( es por dir que no hi cabran), i quan es treballa per bytes, les confirmacions tindran menor probabilitat de extrabiar-se per un camí congestionat.
  La següent imatge mostra gràficament el procés explicat anteriorment:

• Nota: Quan més gran es el thoughput (0 < throughput < 1) la mitja de capacitat de la cua, es a dir, ocupació de la cua, en la política Drop Tail te un creixement mes exponentcial que no pas RED no arribant aquest últim a la capacitat màxima de la cua ³ .
  L’IETF recomana utilitzar la política RED, pero en hi han altres polítiques de gestió de cues més útils en altres casos:

  • pfifo_fast (FIFOF): És igual que la política de pfifo (Tail Drop: es descarten els datagrames un cop la cua està plena), però utilitzant tres bandes diferents (Tail Drop: recordem que en aquesta política solament té una banda i els datagrames van ocupant aquesta de forma ordenada i per ordre d'arribada). El datagrama va a una banda o a una altra depenent del seu valor de TOS. Cada banda te una prioritat diferent, per tant el TOS és qui dona la prioritat als datagrames. Aquesta política, com és llógic, processarà abans els datagrames amb més prioritat alta (cas concret de priorització de cues, PRIO).

• Stochastic Fairness Queuing (SFQ): Cada “conversa”, identificada per les adreces IP i els ports, es manté en una cua FIFO diferent. Els datagrames són agafats de les cues, que per a que no siguin massa grans s'utilitza un mecanisme de hash, segons un esquema RR (Round-Robin).
  

• Política Token Bucket Filter (TBF): Es tracta d'una política de control de congestió basada en tokens. Aquesta política permet limitar l'ampli de banda que s'assigna a cada cua. El funcionament està insipirat en una galleda que s'omple de tokens amb una certa freqüència. Aquesta freqüència és la que determinarà quin és l'ample de banda que se li assgina a un determinat tipus de paquets ja que aquests només poden sortir de la galleda si van acompanyats d'un token.

  • - Aventatges: Permet una limitació de la velocitat màxima de cada cua.
    - Inconvenients: És més complexe d'implementar que altres mecanismes.

• Differentiated Services Mark (DSMark): Ena aquest cas es diferenciarà als datagrames per el camp TOS (Type of Service) i segonas aquest es classificarà al datagrama en una cua diferent amb una política de gestió de cues difernt. D'aquesta manera podem aconseguir donar prioritat als datagrames que tenen un camp TOS determinat mentre que relegarem a un servei menor als de menys prioritat.

  • - Avantatges: Permet classificar els datagrames segons la seva urgència
    - Inconvenients: Ens molts casos els camp TOS no s'utilitza i per tant no servirà per a classificar datagrames que facin "forwarding". Per altra banda, si que pot servir per a datagrames sortints.

• Class Based Queuing (CBQ): Es podria dir que el CBQ és una generalització del DSMark que em vist anteriorment. Aquesta politica classifica els datagrames en diferents cues segons la classes a la que pertanyi. D'aquesta manera s'aconsegueix un aprofitament just de l'ampli de banda de que disposa l'enllaç. Aquesta classe pot dependre de diversos parametres com:

  • - La prioritat (DSMark)
    - La interficie de que prove
    - La interficie a la que va dirigit (si es tracta de datagrames que han de ser enrutats)
    - El programa que ha originat el datagrama

()

• Hierarchy Token Bucket (HTB): Aquesta política és la que ha replaçat a la CBQ al sistema operatiu Linux. Es basa en la utilització de sub-interficies virtuals que son genstionades amb una TBF. D'aquesta manera es pot limitar el trafic de pujada i de baixada segons el client i evitar d'aquesta manera que se saturi l'ample de banda total del sistema.

• Fonts:

  • Transparències de l'assignatura
    http://en.wikipedia.org/wiki/Hierarchical_Token_Bucket#Hierarchical_Token_Bucket.3D http://en.wikipedia.org/wiki/Class_Based_Queueing http://en.wikipedia.org/wiki/Token_bucket_filter

índex

1.4. Finestres menguants

()

IMPLEMENTACIÓ DE LES FINESTRES EN TCP

Per tal de sincronitzar l'enviament de paquets entre emisor i receptor TCP utilitza les anomenades sliding windows. Aquestes permeten una bona optimització del thorughput i a més ofreixen la possibilitat d'incrementar o decrementar la mida de la finestra per tal de donar resposta a la congestió. TCP però ha de permetre un serie de funcionalitats afegides a la sliding window per tal de que no es produeixin erros

• Els canvis de mida de finestra només es fan durant les confirmacions per tal d'evitar una dessincronització entre emisor i receptor. D'aquesta manera la finestra canvia al mateix temps que abança.
  

• Quan la finestra del receptor és zero l'emissor deixa d'enviar.
  

• Si el receptor torna a disposar d'espai en els buffer envia un anunci diferent de zero. Tot i axír l'emisor podrà emetre dades quan aquestes siguin urgents (TOS = urgent). En realitat com que la mida de la finestra de l'emisor pot anar canviant de tamany, el receptor ha de poder saber quina mida tenia aquest inicialment per a poder recuperar-la quan sigui necessari. Per a fer això el que en realitat es fa és implementar dos sliding windows. Aquest fet, tot i que pugui semblar molt costos no ho és pas ja que s'utilitzen punters i per tant és molt òptim:

()

TIMER DE PERSISTÈNCIA

Hi ha situacions en les que la connexió es queda parada durant molta estona i no es vol que aquesta es perdi. Per evitar que algun dels dos extrems es trobi en situació de deadlock (ie: cregui que l'altre extrem està viu quan en realment està mort) s'envia un segment buit i s'espera a que el receptor contesti amb un ACK. D'aquesta manera si el receptor contesta sabem que la connexió segueix oberta.

Aquest segment s'envia utilitzant un backof exponencial de 1,5 segons on 5 és el mínim i 60 és el màxim.

SÍNDROME DE LA FINESTRA TONTA (Silly Window syndrome)

El síndrome de la finestra tonta es produia en les primeres implementacions de TCP i feia que el throughput de la connexió entre un emisor i un receptor baixes dràsticament. Aquest es produeix quan l'aplicació que llegeix/escriu en el buffer de comunicació ho fa molt lentament (o byte a byte). Per ferne una petita aproximació suposarem que és el receptor el qui llegeix byte a byte

1. En receptor envia una nunci de finestra de K bytes a l'emissor.
2. L'emissor envia K bytes i atura els enviaments ja que no disposa de més finestra.
3. El receptor envia un ACK dels K bytes enviat per l'emissor però com que tindrà el buffer ple l'anunci de finestra serà de 0 bytes
4. Ara el programa llegeix 1 byte de la finestra del receptor i aquest envia una anunci de finestra de 1 byte
5. L'emissor envia 1 byte
6. El receptor llegeix un altre byte...

D'aquesta manera el throughput és molt dolent ja que per cada byte de dades que envia l'emissor hi ha 20 bytes de capçaleres TCP + 20 bytes de capçalers IP.

Per tal d'evitar-hi s'implementen una serie d'heuristiques orientades a evitar que s'enviin dades entre l'emissor i el receptor fins que la mida de finestra no sigui prou gran. Aquestes heurístiques s'implementaran tant en l'emissor com en el receptor ja que no em d'oblidar que una connexió TCP és full duplex i per tant consta d'un emisor i un receptor en cada extrem de la connexió

()
==== HEURÍSTIQUES DE RECPTOR === Aquestes heurístiques s'implementaran al receptor de cadascun dels extrems d'una connexió. Una primera aproximiació podria ser evitar que es faci una anunci de finestra (per part del receptor) fin que la finestra tingui una mida mínima. Aquesta mida mínima es calcularà de la següent manera:

Una segona tècnica aplicable al receptor és la de no enviar confirmacions fins de rebuda de paquets fins que la mida de la finestra no sigui suficientment gran. De fet l'estandard TCP (RFC793) recomana aquesta tènica. Tot i així aquesta tècnica te certs avantatges i inconvenients:

• Avantatges: Decrementa el tràfic de segments augmentant el throughput ja que ens envitem enviar una ACK amb finestra 0 i un altre ACK per a indicar que la finestra ja ha incrementat

• Inconvenients: Cal posar un temps màxim d'espera per a evitar que hi hagin retransmissions. A l'hora de la veritat aquest temps màxim es calcularà a paritir del RTT dels paquets.
  

()

HEURÍSTIQUES D'EMISSOR

• Se intenta maximizar el throughput global de la red intentando no enviar datagramas demasiado pequeños.
  

CLUMPING

• Las técnicas de clumping o de agrupamiento consisten en ir generando datos hasta llegar a una cantidad determinada o a un tiempo máximo ( ya que la aplicación podría no generar mas tráfico ( p.e. Telnet ) ).
  Estas técnicas conllevan dos problemas principales:
  

  1. Si hay demasiada espera la comunicación es muy lenta. Además, una alta latencia puede dar sensación de lentitud al usuario.
     

  2. La estimación del RTT varia por lo que desciende la velocidad de transmisión.
     

  Para intentar paliar estos problemas se establecen dos medidas:
  

  1. Un tiempo máximo de espera de 500 ms ( valor obtenido de forma empírica ).
     

  2. Se envía un mensaje de confirmación de forma alternada para no variar excesivamente las estimaciones del RTT.
     

  Estas soluciones no sirven para todos los casos y por ello se requiere en el estándar de TCP la aplicación del algoritmo de Nagle.
  

ALGORITMO DE NAGLE

• Consiste en no enviar información hasta llenar el segmento o recibir el ACK del mensaje anterior.
  De esta forma si es una aplicación de baja latencia ( por ejemplo un terminal remoto en una red local ) se recibirá de forma rápida los ACK y se enviará la información a continuación, en cambio, en transferencias de archivos se llegará al MSS en cada uno de los paquetes por lo que no se espera a los ACK.
  Es muy sencillo de implementar ya que no requiere temporizadores por cada paquete (menor uso de memoria).
  
  

índex

()

1.5. MEJORAS DE TCP Y RENDIMIENTO

MEJORAS DE TCP

1. Redes con ancho de banda y RTT grandes
   

   • Por ejemplo conexiones vía satélite.
     Llamadas LFN ( Long fat-pipe Network, pronunciada en inglés como Elefant )
     

   • Rendimiento
     

     • Tamaño limitado de la ventana
       

       • El tamaño de ventana máximo es de 64KB.
         Para ampliarlo se utiliza un escalado de la ventana mediante las opciones de TCP donde se especifica un shift del tamaño de 0 a 14 posiciones, de esta forma la ventana puede llegar hasta 1GB.
         Como contrapartida se debe destacar que se es mas vulnerable a ataques de RESET.
         

     • Perdida de datagramas
       

       • TCP da por supuesto que la red sobre la que se transmite tiene un nivel muy bajo de perdida de paquetes. Se pueden utilizar algoritmos de fast retransmit/fast recovery (FRR), estos consisten en no esperar a que se llegue al timeout para reenviar un segmento, sino que después de recibir 3 veces el ACK de un mismo paquete se reenvía automáticamente
         

     • Estimación del RTT mediante timestamp: RTTM
       

       1. timestamp de cada paquete: desventaja almacenamiento de cada timestamp, necesidad de una 'libreta' donde ir guardándolos.
          

       2. Igual que en el caso anterior pero utilizando los propios paquetes como memorias, guardar en cada uno su timestamp y copiándolo el receptor en los ACK. De esta forma solo se requerirá una resta para el computo.
          

   • Fiabilidad
     

     • Repetición de los números de secuencia
       

       • PAWS (Protection Againts Wrapped Sequence Numbers).
         Debido a la gran velocidad de transmisión los números de secuencia se repiten cada poco tiempo. Un retraso en un paquete concreto puede dar problemas debido a que se podría interpretar que pertenece a una conexión posterior.
         Para solucionar este problema se utiliza el timestamp, el mismo utilizado para el RTTM explicado anteriormente, descartando los segmentos mas antiguos ( Por si no quedo claro, con esto queremos decir que se descartan los que tienen un timestamp menor a otros recibidos anteriormente ) . La identificación de cada datagrama seria la concatenación de número de secuencia y timestamp.
         
         

     • Todas estas mejoras no tienen que implementarse obligatoriamente y por ello deben negociarse cada vez entre emisor y receptor.
       

• B. Redes Wireless
  

  • El mayor problema que se suele encontrar en estas redes es debido a las interferencias que otros aparatos electrónicos pueden provocar.
    Estas perdidas de paquetes, disminuyen la velocidad de conexión, ya que TCP no contempla otro hecho que el de la congestión de la red.
    Utilizando ECN ( Explicit congestion notification ) se puede diferenciar en que casos se ha perdido un paquete por congestión de la red y en cuales ha sido un error en la transmisión.
    

RENDIMIENTO

El throughput del protocolo se mide como:

•  Throughput (bits) = ampladaBanda(bits/seg) * dadesUtils / DadesEnviades 

Ejemplo sobre una red Ethernet a 10Mb:

• Con dos segmentos de datos llenos y una confirmación:
  

  •  Throughput (bits) = ( ( 10 000 000 (bits/seg) / 8 (bits/seg)) * 2*1460bytes ) / 2*1538 + 84 bytes = 1155063 bytes/seg 

  Con el máximo tamaño de la ventana de TCP ( 64KB ) y una confirmación cada 22 segmentos:
  

  •  Throughput (bits) = ( ( 10 000 000 (bits/seg) / 8 (bits/seg)) * 44*1460bytes ) / 44*1538 + 2*84 bytes = 1183667 bytes/seg. 

• En la práctica hay dos limitaciones mas que se podrían resaltar:
  1. No se puede ir mas rápido que el enlace mas lento.
  2. El ancho de banda máximo tambien lo mimita la memoria mas lenta entre las maquinas.