3.

Capa de Transporte

3.1 Capa de transporte y sus servicios

La capa de transporte brinda comunicacin lgica entre procesos de de aplicacin que se ejecutan
en host diferentes.

3.1.1. Relaciones entre la capa de transporte y la capa de red

Capa de transporte -> Comunicacin lgica entre procesos de hosts

Capa de red -> Comunicacin lgica entre hosts

Se da la similitud entre Capa de red = servicio postal, capa de transporte = persona en la

casa que realiza la tarea de repartir cada carta o correo a quien corresponda, el pap, la
mam, etc. En este caso los hosts seran las viviendas y los procesos las personas en
especifico.

3.1.2. Capa de transporte en Internet

2 protocolos en la capa de transporte:

- UDP, Protocolo de datagramas de usuario, servicio sin conexin no fiable.

- TCP, Protocolo de control de transmisin, orientado a conexin fiable.

Segmentos, paquetes de la capa de transporte.

Capa de red: Protocolo IP, es best effort, enva los segmentos pero no garantiza la entrega
ni la integridad de los datos.

El trmino multiplexacin y demultiplexacin de la capa de transporte se refiere a

extender la entrega host a host a una entrega proceso a proceso.

UDP, solo ofrece 2 servicios: Entrega de datos proceso-proceso y comprobacin de

errores.

TCP, ofrece mltiples servicios, transferencia de datos fiables mediante tcnicas de control
de flujo, nmeros de secuencia, mensajes de reconocimiento y temporizadores, adems
de mecanismos de control de congestin.

3.2. Multiplexacin y Demultiplezacin

Demultiplexacin: Entregar los datos contenidos en un segmento de la capa de transporte

al socket correcto (cada socket tiene un identificador para cada proceso).

Multiplexacin: Reunir los fragmentos de datos en el host de origen desde los diferentes
sockets, encapsulando cada fragmento con la informacin de cabecera y asi crear los
segmentos y pasarlos a la capa de red.

Para esta operacin se requiere que:

- Sockets con identificadores nicos

 - Campos especiales en el segmento que indiquen el socket al que tienen que
entregarse el segmento.
Estos campos especiales son: campo nmero de puerto de origen y el campo nmero
de puerto de destino.

Los nmeros de puertos son de 16 bits en el rango de 0 a 65535, del 0 al 1023 se conocen
como puertos bien conocidos y son restringidos.

Proceso general de demultiplexacin: cada socket del host se puede asignar a un nmero
de puerto y, al llegar un segmento al host, la capa de transporte examina el nmero de
puerto de destino contenido en el segmento y lo enva al socket correspondiente, luego
los datos del segmento pasan a travs del socket y se entregan al proceso asociado.

Multiplexacin y demultiplexacin sin conexin

La capa de transporte crea un segmento con el puerto de origen y el puerto de destino, entonces
en cada host ocurre la multiplexacin y demultiplexacin segn el socket con el puerto UDP
asignado de destino o origen. Por qu es necesario que se ponga el puerto de origen? Para que si
el host receptor desee devolver el segmento sepa a donde enviarlo.

Multiplexacin y demultiplexacin orientadas a conexin

A diferencia del socket UDP, el socket TCP se identifica por una tupla de 4 elementos: IP de origen,
puerto de origen, IP de destino, puerto de destino.

El cliente TCP genera una segmento de establecimiento de conexin, este es enviado al servidor,
el cual recibe el segmento e identifica el puerto de destino y asigna un socket al proceso, adems
tambin identifica los 4 elementos que contiene, y los relaciona a este socke8t de conexin, es
entonces cuando ya se podr enviar datos entre estos. Cada socket tiene asignado una nica tupla
de los 4 elementos.

Servidores web y TCP

El texto hace nfasis en la manera en que se establecen las conexiones cliente servidor, hace
referencia al termino HTTP persistente y no persistente, persistente es cuando se establece la
conexin de cliente servidor y se pueden transmitir todos los objetos o mensajes a travs del
mismo socket, pero cuando es no persistente, para cada peticin/respuesta (osea para cada
mensaje o objeto) se crea un nuevo socket, y esto ltimo genera poca eficiencia.

3.3. Transporte sin conexin: UDP

Se dice que es un protocolo sin conexin porque no establece conexin entre emisor y receptor
antes de enviar el segmento a la capa de red.

El proceso de UDP es simple, nunca toca IP, el que se encarga de comunicarse con IP es la capa de
aplicacin, UDP recpciona estos datos obtenidos por la capa de aplicacin y coloca puerto de
origen y destino para hacer el servicio de multiplexacin/demultiplexacin, aade 2 pequeos
campos ms y enva el segmento resultante a la capa de red, la capa de red lo encapsula en un
datagrama IP y hace el mayor esfuerzo por entregar el ssegmento al host receptor.

Y luego de que llega, si es que llega, se encarga de enviar al proceso segn el puerto de destino.

Nunca hubo un proceso preliminar de establecimiento de la conexin.

Por qu preferir UDP en vez de TCP? Si todo parece indicar que UDP no parece ser para nada
efectivo, las ventajas de usar UDP son:

- Sin establecimiento de la conexin: TCP realiza un proceso de 3 fases de

establecimiento de la conexin, UDP no hace nada de esto, y esto sirve para que no
hayan retardos en la transmisin, esto ayuda a tener respuestas rpidas como en el
caso de los DNS, para paginas web(HTTP) si es importante TCP.
- Mejor control en el nivel de aplicacin sobre que datos se envan y cuando: Esto
quiere decir que UDP solo enva los datos y all queda, y en TCP la capa de aplicacin
enva los datos y hay un proceso interno donde se pueden reenviar muchas veces el
dato hasta que llegue, o talvez hay congestin y TCP tmbn realiza un proceso que
genera colas, entonces para la capa de aplicacin es un poco ms complicado saber
exactamente cuando fue que se logr envar el mensaje, en cambio la aplicacin en
UDP solo enva y registra en ese momento la hora en que envi y qe fue lo que se
envi.
- Poca sobrecarga: la cabecera de TCP contiene 20bytes, la de UDP 8 bytes.

Telnet,SMTP, HTTP, FTP, son TCP

SNMP, RIP, DNS, NFS, son normalmente UDP.

TCP empieza cada vez ms a desplazar a UDP, si bien es cierto que muchas aplicaciones
multimedia, de videoconferencias, telefnica, etc, utilizan UDP por su velocidad, ya se estn
viendo cosas que algunas que usan TCP.

Es posible que se puede transmitir datos de manera fiable usando UDP, y esto se consigue
incorporando caractersticas de fiabilidad a la aplicacin en si, es algo complicado pero da
ENORMES ventajas, ya que no tendra las restricciones de velocidad de transmisin impuestas por
TCP.

3.3.1 Estructuras de segmentos UDP

Esta es la estructura:
La cabecera UDP solo tiene 4 campos y cada uno con 2 bytes, como ya se mencion :el host de
destino utiliza el puerto para asociarlo al proceso adecuado.

El campo longitud especifica la longitud del segmento en bytes incluyendo la cabecera.

3.3.2. Suma de comprobacin de UDP

Sirve para detectar si el segmento UDP ha sido alterado durante la transmisin. En el lado emisor,
UDP calcula el complemento a 1 de todas las palabras de 16 bits del segmento acarreando
cualquier desbordamiento obtenido durante la operacin de suma, sobre el bit de menor peso.

Es mejor que lo entiendan (los que leen esto) con el ejemplo del libro:

Como se produjo desbordamiento el 1 pas al bit de menor peso (osea el de la derecha), luego se
saca complemento a 1 de este resultado y se obtiene la suma de comprobacin, luego el receptor
suma este valor con las otras 3 palabras y tiene que salir 11111111111111, si no, es que hay error.

Porqe presenta deteccin de errores si ya hay en la capa de enlace uno?

Es porque no es seguro que todos los encales presenten control de errores, adems el error se
puede producir luego que la capa de enlace termine su trabajo, osea se puede producir errores de
bit cuando el segmento se almacena en la memoria del router.

El principio terminal terminal, hace referencia a cuan importante es la comprobacin de errores

en una capa como la de transporte( terminal - terminal) ya que es una capa superior a las dems
que ya presentan un proceso de comprobacin, esto hace parecer que los procesos de
comprobacin de las capas inferiores sean redundantes o poco tiles.

UDP al detectar error, simplemente descarta el segmento o lo enva a la aplicacin junto con una
advertencia. AQU TERMINA UDP.

3.4 Principios de un servicio de transferencia de datos fiables

Uno de los principales problemas es que si bien se puede tener una transferecnai de datos fiables
en la capa de transporte (TCP), en las capas inferiores tal vez no presenten este servicio, como en
de red terminal terminal no fiable (IP).
Durante lo que sigue del capitulo solo se explicara todo desde la perspectiva unidireccional,
porque la bidireccional es mas complicada de entender.

3.4.1. Construccin de un protocolo de transferencia de datos fiable

A continuacin se irn mostrando los protocolos, hasta llegar a uno que no tiene defectos.

Transferencia de datos fiable sobre un canal totalmente fiable: rdt 1.0 (reialable data transfer)

Se muestran maquinas de estados finitos (FSM), en este caso solo tienen 1 estado, el suceso que
provoca la transicin se pondr encima de la lnea horizontal y los sucesos que provoca, debajo de
la lnea horizontal.

Para este caso el receptor no necesitar de realimentacin ya que dispone de un canal totalmente
fiable, y adems la velocidad con la que el receptor recibe el mensaje es igual a la que el emisor
enva asi que tampoco habr problemas con eso. Es un caso ideal en realidad, ms que todo el
autor lo usa para dar detalles de como funcionarn los procesos de las maquinas de estados que
mostrar.

Transferencia de datos fiables sobre un canal con errores de bit rdt 2.0

Este es un caso ms real en donde el canal presenta errores y corrompe el paquete de datos, en
este caso se relizan los procesos como cuando una persona esta hablando por telfono con otra y
cuando entiende algo dice: ok si, ok esta bien, pero cuando no entiende dice: que? Puedes
repetir?, lo mismo ocurre aqu, cuando no se enva correctamente un paquete este enva
automticamente un ARQ, mediante protocolos ARQ (automatic repeat reQuest) en estos
protocolos se necesitan 3 capcacidades de de protocolos adicionales para gestionar la deteccin
de errores de bit:

- Deteccin de errores: Se necesita saber que hubo error, esto si tiene UDP, para esto se
hace que el emisor envie unos datos adicionales al paquete que enva para el cculo
de suma de comprobacin de paquete de datos rdt 2.0
- Realimentacin del receptor: para que el emisor sepa que su paquete se envio con
errores necesita que el receptor le diga algo, para esto son el ACK y NAK (ACUSE DE
 RECIBO POSITVO Y NEGATIVO), estos paquetes solo necesitan 1 bit, osea 0 para NAK y
1 PARA ACK.
- Retransmisin: su nombre lo dice, cuando el paquete tiene error, el receptor debe
retransmitir.

Este es el diagrama de maquinas de estados finitos del protocolo rdt2.0, no es necesario

que lo analicen, con los que les dir basta :v

Bueno resulta que el emisor recibe los datos de la capa superior y los empaqueta junto con la
suma de comprobacin y los enva, es entonces cuando pasa a otro estado, en donde solo se pone
a esperar el ACK o NAK, si recibe el ACK recin pasa a su estado anterior donde puede recibir
datos, por el contrario solo estar esperando a que el receptor envie NAK o ACK, esto se le llama
protocolo de parada y espera (stop and wait protocol), obviamente si recibe un NAK tendr que
retransmitir el ltimo paquete recibido.

Por parte del receptor si recibe bien el paquete manda un ACK al emisor y extrae el paquete
entrga los datos, si recibe mal enva un NAK.

Posteriormente se plantean protocolos 2.1, donde se incluye un numero de secuencia en los

paquetes a enviar del emisor, que sirven para saber si un paquete es uno retransmitido o es un
paquete nuevo, por ejemplo se enva un paquete con numero de secuencia 0, y recibe un NAK
vuelve a mandar con 0, entonces el receptor sabr que es una retransmisin, ya que si detecta 1,
es porque es un paquete nuevo, adems las rspuestas ACK y NAK tendrn su propia suma de
comprobacin para saber si los ACK o NAK no son adulterados o incorrectos.

Y el 2.2 consiste en que ahora los ACK/NAK incorporan el numero de secuencia en su

nomencaltura, osea en vian ACK 1 o ACK0.
Transferencia de datos fiable sobre un canal con prdidas y errores de bit: rdt3.0

Ahora se considera que el paquete puede perderse, ya no solo corromperse.

Para esto se crean un temporizador con un promedio razonable de tiempo en que el paquete
puede perderse, el emisor inicia su temporizador al enviar el paquete, si no recibe el ACK/NSK, en
el tiempo indicado, vuelve a mandar el paquete, en este caso hay la posibilidad de que haya
duplicado de paquetes enviados (en caso no se haya perdido el paquete sino solo se haya
demorado un poco ms), pero con las respuestas ACK 0 o ACK1 (0 y 1 los nmeros de secuencias
mencionados anteriomente), se puede determinar el duplicado y el sistema continuar
funcionando normalmente.

Este es el mejor diagrama para entenderlo: (si es que quieren)

A este tipo de protocolos se les llama de bit alternante, (por sus numros de secuncia 0 y 1).
3.4.2. Protocolo de transferencia de datos fiable con procesamiento en cadena (GBN)

El protocolo rdt3.0 es muy bueno, pero lo malo es que es un protocolo de parada y espera, y esto
afecta el rendimiento, para laas redes de alta velocidad actuales.

Todo se resume en esta imagen:

En vez de estar esperando a que el paquete se envie y llegue la respuesta del ACK, se puede enviar
paquetes simultneamente.

Esto implica algunas cosas adicionales como que se necesitar un rango mayor de nmeros de
secuencia, y que los buffer del emisor y receptor van a almacenar mas de un paquete.

Estas implicancias dependern de como responde el protocolo a las perdidas o retrasos excesivos
de paquetes, para ayudar en la recuperacin de errores en los procesamiento en cadena se
utilizan: Retroceder N y la repeticin selectiva.

3.4.3 Retroceder N

Este protocolo puede transmitir varios paquetes sin necesidad de ser reconocidos, pero tiene un
lmite, N, al cual se le llama ventana, este grafico resume todo:

Se asigna como base al numero de paquete mas antiguo no reconocido y signumsec como el
numero de secuencia mas pequeo no enviado. A partir de aqu se definen 4 rangos de nmeros
de secuencia (los mostrados en Clave del grfico).

A este protocolo se le llama de ventana deslizante, porque cada que los paquetes vayan
reconocindose y enviando otros la ventana se desplaza hacia adelante.

El emisor responde a 3 sucesos:

 - Invocacin desde la capa superior, este recibe el paquete y corrobora que la ventana
no este llena.
- Recepcin de un mensaje de reconocimiento ACK.
- Tambin presenta temporizador para reenviar todos los paquetes enviados pero no
reconocidos.

Con reconocidos se refiere a los respondidos con un ACK por parte del receptor.

Una caracterstica importante en este protocolo es que no recibe paquetes en desorden, los
descarta, por ejemplo si se pierde el paquete con nro de secuencia 2, no va a recibir el 3 4 y 5
hasta que el emisor no vuelva a enviar y que el receptor reciba satisfactoriamente este paquete.

3.4.4. Repeticin Selectiva (SR)

El protocolo GBN, como se puede notar tiene un gran punto en contra y es que por el hecho de no
aceptar paquetes en desorden genera muchas retransmisiones, ocasionando muchas
transmisiones innecesarias.

Este protocolo SR, subsana esto, cada vez que el receptor detecte que se perdi un paquete y esta
recibiendo en desorden, los guarda en un buffer, y manda un aviso al emisor de cual es el paquete
que se perdi, entonces el emisor solo manda el paquete perdido y cuando el receptor lo recibe
bien, recin procesa los otros paquetes.
3.5. TCP

3.5.1. La conexin TCP

Tcp esta orientado a conexin ya que antes de que un proceso en un host trasmita datos
hacia otro proceso en otro host se debe establecer comunicacin entre ambos procesos.
La comunicacin en TCP es full dplex, es decir ambos procesors pueden trasmitir datos
hacia el otro en el mismo instante
Un conexin TCP, es un enlace punto a punto dado que casi siempre permite una
comunicacin entre 1 proceso emisor y un proceso receptor
Al establececimiento de una conexin TCP se le conoce como ACUERDO DE 3 FASES ya
que el cliente (el que inicia la comunicacin) enva un segmento especial,el recepto le
responde con otro segmento y por ultimo el cliente le responde con con un 3er segmento
que por lo general este ultimo segmento contiene la informacin de la capa de aplicacin.
Una vez establecida la conexin ya se puede comenzar a trasmitir datos, los datos primero
pasan por un socket luego llegan a la capa de transporte (al protocolo tcp) ,tcp dirige los
datos hacia un buffer de emisin para posteriormente tomar cuando sea conveniente
fragmentos de datos para poder trasmitirlos
MSS ( Tamao mximo de segmento) nos indica la mayor cantidad de datos de la capa de
aplicacin que se pueden encapsular en un segmento.Utliza para definir ese valor el
MTU(unidad mxima de trasnmision)

3.5.2 Estructura del segmento TCP

Cabecera tcp : 20 bytes

Cabecera udp : 8 bytes

Longitud del segmento TELNET: 21 BYTES

 NUMERO DE PUERTO DE ORIGEN Y DESTINO : Sirven para multiplexar y demultiplexar los
segmentos
NUMERO DE SECUENCIA Y RECONOCIMIENTO : son utilizados para brindar un servicio de
trasferencia de datos fiable
LONGITUD DE CABECERA: Nos indica la longitude cabezera del segmento (tpica 20 bytes)
CAMPO OPCIONES: OPCIONAL y de longitur variable
CAMPO INDICADOR : 6 bits
RST-SYN-FIN: establecimiento y cierre de conexione
PSH:el receptor debe pasar los datos a la capa superior
ACK: transmisin exitosa
URG: nos indica que este segmento contiene datos URGENTES
NUMERO DE SECUENCIA: nos indica la posicin del primer byte de datos de un segmento
dentro un flujo de bytes

NUMERO DE RECONOCIMIENTO:

Todos los segmentos que llegan procedentes del host B tienen un nmero de secuencia para los
datos que fluyen de B a A. El nmero de reconocimiento que el host A incluye en su segmento es el
nmero de secuencia del siguiente byte que el host A est esperando del host B.

Suponga que el host A ha recibido todos los bytes numerados de 0 a 535 procedentes de B y
suponga tambin que est enviando un segmento al host B. El host A est esperando al 536 y todos
los bytes que le siguen del flujo de datos del host B. Por tanto, el host A incluye 536 en el campo
nmero de reconocimiento del segmento que enva a B.

PROTOCOLO TELNET

Se ejecuta sobre tcp y permite el inicio de sesin remotos. cada vez que un cliente teclee un
carcter este viaja al receptor y luego regresa al cliente para su visualizacin

3.5.3 Estimacin del tiempo de ida y vuelta y fin de temporizacin

Tcp utiliza un temporizador para recuperarse de la perdida de segmentos ,pero no se sabe cunto
tiene que ser ese tiempo necesario para afirmar que un segmento se ha perdido o daado.

ESTIMACION DEL TIEMPO DE IDA Y VUELTA (RTT)

PARA poder ponderar los rtt de cada conexin tcp en el tiempo se utiliza LA EWMA (
MEDIA MOVIL EXPONCENCIALMENTE PONDERADA) con eso recolectamos un RTTestimado

Definicion y gestin del intervalo de fin de temporizacio para la restrasmision

El intervalo que debe usarse para el fin de temporizacin TCP tiene que ser mayor que el
rttestimado sino se producen retrasmisiones innecesarias pero tampoco muy mayor q el
 rttestimado puesto que se tendra que esperar mucho para la restrasmision de un
segmento perdido o corrompido .

3.5.4 TRANSFERENCIA DE DATOS FIABLE

Tcp crea un servicio de trasnferencia de datos fiable sobre el servicio de mejro esfuerzo de
ip,logrando que los segmentos que lleguen a los buffers de recepcin TCP no se hayan perdido
,corrompido y que lleguen en orden.
El protocolo TCP solo utiliza un temporizador para todo el flujo de datos trasnmitido y ya no para
cada segmento ya que esto genera un sobrecarga a la red

Sucesos en la emisin de un segmento :

-Los datos son recibidos de la capa de aplicacin ,se encapsula en ip y se llevan a la red
- si sucede el fin de temporizacion,tcp retrasmite el segmento que ha causado dicho fin de la
temporizacion
-la llegada de un semneto de reconocimiento ACK,TCP usa una RECOCIMIENTOS ACUMULATIVOS:
EJEMPLO SI EL ACK= 98 SIGNIFICA QUE HA RECIBIDO CORRECTAMENTE DESDE EL NUMERO INICIO
DE SECUENCIA HASTA EL 98AVO BIT

RECONOCIMIENTO ACUMULATIVO:

SIGNIFICA QUE SI ENVIAMOS 2 SEGMENTOS Y EL SEGMENTO DE RECOCIMIENTO DEL

PRIMER SEGMENTO ENVIADO SE PIERDE PERO EL DEL 2DO SI LLEGA ESTO SIGNIFICA QUE
TANTO EL PRIMER 1ER Y 2 SEGMENTO LLEGARON AL RECEPTOR Y YA NO ES NECESARIO
RETRANSMITIR PERO EL SEGMENTO DE RECONOCIMIENTO DEL 2 SEGMENTO TIENE QUE
LLEGAR ANTES DE QUE FINALIZE EL TEMPORIZADOR DEL 1ER SEGMENTO DE LO
CONTRARIO RETRASMITIRA AMBOS SEGMENTOS

DUPLICACION DE INTERVALOS DE FIN DE TEMPORIZACION

CUANDO UN TEMPORIZADOR FINALIZA EL PROTOCOLO TCP ASIGNA UN NUEVO

INTERVALO DE TEMPORIZACION MAYOR AL ANTERIOR ,CADA EMISOR RETRASMITE
DESPUES DE INTERVALOS MAS GRANDES CADA VEZ

RETRASMISION RAPIDA : AQU SE RETRASMITEN LOS SEGMENTOS ANTES DE QUE FINALIZE

EL TEMPORIZADOR DEL SEGMENTO ,SI LLEGA AL EMISOR 3 ACK DUPLICADOS REALIZA
UNA RETRASMISION RAPIDA

TCP ES UN HIBRIDO ENTRE GBN Y SR (RECONOCIMIENTO SELECTIVO)

3.5.5 CONTROL DE FLUJO

TCP brinda un servicio de control de flujo a los procesos de las aplicaciones para que no desborden
el buffer del receptor ,adapta la velocidad a la q el emiso esta trasmitiendo a la velocidad con la
que la aplicacin esta leyendo los datos )
Para ello utiliza una ventana de recpcion que le indica cuanto espacio disponible hay en el buffer
de recepcin
Udp no implmenta ningn servicio de control de flujo

3.5.6 Gestion de la conexin

ACUERDO DE 3 FASES :

1er paso CLIENTE TCP enva un segmento especial al SERVIDOR TCP ,este segmento especial no
tiene datos pero tiene un bit SYN PUESTO A 1

2 DO PASO : Cuando llega el segmento SYN al receptor este asigna los buffer y las variables tcp y
enva un segmento de respuesta indicando que se ha establecido la conexin
(SEGMENTO SYNACK)

3ER PASO : el emisor al recibir el segmento SYNACK asigna tambin buffer y variables a la
conexin,el emiso enva otro segmento confirmando la conexin
En los segmentos enviados despus el bit SYN esta puesto a 0
Completados los 3 pasos ya se puede comenzar a trasmitir los segmentos que contienen los datos

Cuando se quiere abadonar una conexio el emisor manda un segmento especial con un bit FIN
puesto a 1 ,asimismo el servidor responde con otro segmento con bit FIN PUESTO A 1 confirmando
la desconexin del servidor

3.6 PRINCIPIOS DEL CONTROL DE CONGESTIN

Mtodos para controlar la congestion

CONTROL DE CONGESTION TERMINAL A TERMINAL: aqu la capa de red no proporciona

soporte a la capa de trasnporte para el control de congestion
Se basa en el comportamiento de la red ( perdida de paquetes,retardos)

La perdida de paquetes se produce por ( fin de temporizacion y triple paquete ACK

duplicado)

TCP APLICA ESTE METODO DE CONTROL DE CONGESTION

CONTROL DE CONGESTION ASISTIDO POR LA RED : LOS ROUTERS INFORMAN AL EMISOR

SOBRE EL ESTADO DE CONGESTION DE LA RED. LOS ROUTER TIENE 2 FORMAS DE
INFROMAR AL EMISOR , LA PRIMERA ES MEDIANTE UN PAQUETE DE ASFIXIA que indica
que la red esta congestionada y la otra forma es marcando un campo del segmento el cual
nos indica q existe congestion .

Utilizado en atm
3.7 MECANISMO DE CONTROL DE CONGESTION DE TCP

Utiliza un control de congestion terminal a terminal,el mtodo consiste en que cada

emisor limita su velocidad a la que trasmite teniendo en cuenta la congestion de la red
-Un segmento perdido implica congestion y por tanto la velocidad del emisor TCP debe
reducirse cuadno se pierde un segmento
-Un paquete q ha sido reconocido implica q la red esta entregando los segmentos
correctamente por lo q la velocidad de trasmisin puede aumentarse
-Incrementa su velocidad dependiendo de llegas de paquetes ACK