Tema2

Administracin de redes y servidores

rea de Ingeniera de SistemasProfesores: Carlos Elvira Izurrategui Javier Rico Azagra

Profesor: Carlos Elvira Izurrategui

ndice1. 2. 3. 4. 5. 6. 7.

La capa de transporte y sus servicios. Multiplexacin y demultiplexacion. Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable. Transporte orientado a la conexin: TCP. Principios de control de congestin. Mecanismo de control de congestin de TCP.


ndice1.2. 3. 4. 5. 6. 7.

La capa de transporte y sus servicios.Multiplexacin y demultiplexacion. Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable. Transporte orientado a la conexin: TCP. Principios de control de congestin. Mecanismo de control de congestin de TCP.


La capa de transporte y sus serviciosProtocolo de capa de transporte proporciona una comunicacin lgica entre procesos de aplicacin.Semejante a tener los 2 host conectados entre s. Pueden estar los 2 hosts en cualquier sitio, conectados por distintos tipos de enlaces entre routers y switches. Los procesos de aplicacin utilizan la comunicacin lgica (transporte) para enviarse mensajes entre s, sin preocuparse de la infraestructura fsica. Los protocolos de capa de transporte estn implementados en los sistemas terminales (no en los routers). PDUs de capa de transporte: segmentos. En el lado emisor:Convierte y divide los mensajes procedentes de un proceso de aplicacin en segmentos. Aade cabecera del segmento. Pasa el segmento a la capa de red (paquete o datagrama), que se enva al destino.


La capa de transporte y sus serviciosEn el lado emisor:Convierte y divide los mensajes procedentes de un proceso de aplicacin en segmentos. Aade cabecera del segmento. Pasa el segmento a la capa de red (paquete o datagrama), que se enva al destino.aplicacin transport Red enlace fsca

n -e nd le ca gi lo d t or sp an tr

En el lado receptor:La capa de red extrae el segmento de la capa de transporte del datagrama recibido. Los sube a la capa de transporte y se procesa. Se ponen los datos del segmento a disposicin del proceso de la aplicacin receptor.

aplicacin transport red Enlace Fsica


Relaciones entre capas de transporte y redCapa de transporte: proporciona una comunicacin lgica entre procesos que se ejecutan en hosts distintos.

Analoga: 6 nios enviando cartas a sus 4 primos Sus servicios estn procesos = nios restringidos por el protocolo de red Mensajes app. = (retardos, BW). cartas en sobres Tambin puede ofrecer servicios que no hosts = casas ofrezca el protocolo de la capa de red Protocolo trans = subyacente. Ana y Pedro Capa de red: proporciona una Protocolo capa de comunicacin lgica entre hosts red= servicio postalProfesor: Carlos Elvira Izurrategui

La capa de transporte en InternetUDP (User Datagram Protocol): proporciona un servicio sin conexin no fiable a la aplicacin que le invoca. TCP (Transmissin Control Protocol): proporciona un servicio con conexin fiable. Capa de red con IP (Internet Protocol): proporciona un servicio de entrega de mejor esfuerzo.Hace lo que puede. No garantiza la entrega (servicio no fiable)aplicacin transport red Enlace fsica

red Enlace fsica

n -e nd le ca gi lored Enlace fsica red Enlace fsica red Enlace fsica red Enlace fsica red Enlace fsicaProfesor: Carlos Elvira Izurrategui

d t or sp an traplicacin transport red Enlace fsica

ndice1. 2.3. 4. 5. 6. 7.

La capa de transporte y sus servicios. Multiplexacin y demultiplexacion.Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable. Transporte orientado a la conexin: TCP. Principios de control de congestin. Mecanismo de control de congestin de TCP.


Multiplexacin y demultiplexacinDemultiplexado en host rec.: Entrega de segmentos recibidos a su socket= socket aplicacin P3 transporte red enlace fsica = proceso P1 P1 aplicacin transporte red enlace fsica P2 P4 aplicacin transporte red enlace fsica

Multiplexado en host emi.: Reune datos de mltiplies sockets, los encapsulndolos con la cabecera creando el segmento

host 1

host 2

host 3Profesor: Carlos Elvira Izurrategui

Demultiplexacin. FuncionamientoHost receptor recibe paquete o datagrama IP.Cada datagrama tiene IP origen e IP destino. Cada datagrama lleva un segmento de capa de transporte. Cada segmento tiene un puerto origen y un puerto destino. 32 bits puerto or. # puerto dest #

otros campos de cabecera

El host receptor usa la IP y el puerto para colocar cada en su socket.Las tcnicas de multiplexacin y demultiplexacin son necesarias siempre que un nico protocolo de una capa sea utilizado por varios protocolos de la capa superior.Ejemplo: HTTP, FTP, SMTP usan TCP.

datos de aplicacin (mensajes)

Formato segmento TCP/UDP


Multiplexado-demultiplexado sin conexinCreacin de socket UDP en un host (Java):DatagramSocket mySocket0 = new DatagramSocket(); DatagramSocket mySocket1 = new DatagramSocket(12534);

Un socket UDP socket posee la dupla que lo identifica: (dest IP address, dest port number) En la capa de transporte se encapsula la dupla a los datos de aplicacin. La capa de transporte pasa el segmento a la capa de red: encapsula el segmento con cabecera (IP origen+IP destino).IP hace el mximo esfuerzo por entregar el segmento al host receptor (pero IP no garantiza).

En el host receptor:Se examina el nmero de puerto destino indicado en el segmento. Y se entrega el segmento a su socket correspondiente (con ese nmero de puerto). Al mismo socket destino pueden llegar informacin procedente de datagramas con IPs origen distintas y/o segmentos con puertos origen distintos.Profesor: Carlos Elvira Izurrategui

Multiplexado-demultiplexado sin conexinDatagramSocket serverSocket = new DatagramSocket(6428);

P2

P3

P1 P1

SP: 6428 DP: 9157 SP: 9157

SP: 6428 DP: 5775 SP: 5775

cliente IP: A

DP: 6428

servidor IP: C

DP: 6428

clienteIP:B

SP suministra dato de retornoProfesor: Carlos Elvira Izurrategui

Multiplexado-demultiplexado con conexinSocket TCP queda identificado por 4 elementos: SP (source port), DP (destinatio port), SIP (source IP), DIP (destination IP). Cuando un segmento llega a un host se emplean los 4 valores para dirigir (demultiplexar) el segmento al socket adecuado. 2 segmentos TCP entrantes con IPs de origen o n puertos distintos se dirigen a sockets diferentes. Salvo el segmentoLa aplicacin del servidor con TCP tiene un socket de acogida en espera de solicitudes de establecimiento de conexin procedente de clientes en un puerto dado. El cliente TCP genera segmento de establecimiento de conexin:Socket socketcliente = new Socket(nombreHostServidor,#port);

TCP que transporta la solicitud original del establecimiento de la conexin.

Solicitud de establecimiento de conexin: segmento TCP con #port y conjunto especial de bits de establecimiento de conexin en la cabecera TCP. Tambin se genera en el cliente un socket TCP para intercambiar datos. Al llegar la sol. de establecimiento de conexin al servidor, localiza el proceso (daemon) en el servidor que espera a aceptar la conexin. El proceso servidor crea un nuevo socket:Socket socketConexion = socketAcogida.accept();


Multiplexado-demultiplexado con conexinLa capa de transporte en el servidor anota los 4 campos (SP, DP, SIP, DIP). El socket de conexin recin creado queda identificado por los 4 valores.. Todos los segmentos que lleguen despus con estos mismos 4 valores, entrarn por este socket para intercambiar datos entre cliente y servidor.

Un host servidor puede dar soporte a muchos sockets TCP simultneos, y cada uno de ellos queda identificado por los 4 valores.P1 P4 P5 P6SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157

P2

P1 P3

Cliente IP: A

DP: 80 S-IP: A D-IP:C

Servidor IP: C

DP: 80 S-IP: B D-IP:C

ClienteIP:B


TCP en servidores webEjemplo: servidor web Apache. Puerto 80. Los clientes navegadores envan todos los segmentos (de establecimiento de conexin y de transporte de mensajes solicitud HTTP) al servidor, todos lo hacen por puerto 80.El servidor los diferencia segn la IP de origen y puerto origen.

Los servidores web actuales utilizan un proceso y crean una hebra (subproceso) con un nuevo socket de conexin para cada conexin de un cliente.Este tipo de servidores pueden tener muchos sockets de conexin (distintos identificadores) asociados al mismo proceso.

Si el cliente y el servidor utilizan conexiones persistentes, se intercambian los mensajes por el mismo socket. Si el cliente y el servidor utilizan conexiones no persistentes, cada mensaje solicitud/respuesta necesita abrir/cerrar una conexin TCP.Esto puede afectar al rendimiento del servidor.


TCP en servidores webEjemplo: servidor web Apache. Puerto 80. Los clientes navegadores envan todos los segmentos (de establecimiento de conexin y de transporte de mensajes solicitud HTTP) al servidor, todos lo hacen por puerto 80.El servidor los diferencia segn la IP de origen y puerto origen.

Los servidores web actuales utilizan un proceso y crean una hebra (subproceso) con un nuevo socket de conexin para cada conexin de un cliente.Este tipo de servidores pueden tener muchos sockets de conexin (distintos identificadores) asociados al mismo proceso.

Si el cliente y el servidor utilizan conexiones persistentes, se intercambian los mensajes por el mismo socket. Si el cliente y el servidor utilizan conexiones no persistentes, cada mensaje solicitud/respuesta necesita abrir/cerrar una conexin TCP.Esto puede afectar al rendimiento del servidor.


TCP en servidores web

P1

P4SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157

P2

P1 P3

Cliente IP: A

DP: 80 S-IP: A D-IP:C

Servidor IP: C

DP: 80 S-IP: B D-IP:C

ClienteIP:B


ndice1. 2.

La capa de transporte y sus servicios. Multiplexacin y demultiplexacion.

3.4. 5. 6. 7.

Transporte sin conexin: UDP.Principios de un servicio de transferencia de datos fiable. Transporte orientado a la conexin: TCP. Principios de control de congestin. Mecanismo de control de congestin de TCP.


Transporte sin conexin UDPProtocolo de transporte simple y poco sofisticado (vacuo). UDP: RFC 768. Realiza:Funcin de multiplexacin y demultiplexacin.Toma los mensajes del proceso aplicacin.

Encapsula los puertos origen y destino. Aade informacin (2 campos) de comprobacin de errores.

La capa de red encapsula el segmento en un datagrama (paquete) IP. Con el mejor esfuerzo entrega el segmento al host receptor.

UDP no tiene fase de establecimiento de conexin previa al envo del segmento con mensaje de aplicacin. Protocolo sin conexin. Ejemplos: DNS (53), RIP (520). Ventajas de UDP frente a TCP:Mejor control en el nivel de aplicacin sobre qu datos se envan y cundo.Se enva los datos de aplicacin empaquetados y se entregan directamente a capa de aplicacin. TCP no lo hace ya que tiene un mecanismo de control de congestin que regula el flujo.


Transporte sin conexin UDPVentajas de UDP frente a TCP:Sin establecimiento de conexin.TCP lleva un establecimiento de conexin en 3 fases (genera retardo).

Sin informacin de estado de la conexin.TCP mantiene informacin del estado de la conexin en los sistemas terminales.Buffers de recepcin y de envo. Parmetros de control de congestin. Parmetros de nmero de secuencia y nmero de reconocimiento.

Puede suponer problema se congestin en la red. Ejemplo: reproduccin masiva de vdeo a alta velocidad. -> Desbordamiento de paquetes en la cola de los routers. Prdidas de paquetes. No todos los emisores UDP llegarn a su destino. Emisores UDP pueden hacer disminuir mucho la velocidad de transmisin en los emisores TCP (estrangulamiento de sesiones TCP)

Poca sobrecarga debida a la cabecera de los paquetes.Segmentos UCP contienen cabeceras de 8 bytes. TCP posee 20 bytess.

Una aplicacin puede disponer de servicio fiable de transferencia de datos trabajando con UDP.Ojo: aadiendo los mecanismos de fiabilidad en la propia aplicacin


Transporte UDP. Estructura del segmento

32 bits Longitud, en bytes de segmento UDT, incluyendo cabecera Port# origen Port# destino longitud checksum

Datos de aplicacin (mensage)

Formato de segmento UDP


Transporte UDP. ChecksumChecksum (suma de comprobacin): mecanismo de deteccin de errores (OJO: no de correccin).Se utiliza para determinar si los bits contenidos en el segmento UDP han sido alterados al desplazarse desde el origen al destino (seales de ruido en los enlaces, procesamiento en el router)

Funcionamiento del checksum:En el emisor se calcula el complemento a 1 de las suma (con acarreo) de todas las palabras de 16 bits (RFC 1071) Igual en el receptor. Se suma al receptor el checksum.Debe salir 1111.1111 (16 bits a uno) Si algn bit es cero -> error.

Porqe usar checksum en capa de transporte?Hay protocolos de capa de enlace (Ethernet) que tambin los lleva, pero hay otros protocolos que no. Adems aunque exista comprobacin de error en el enlace, puede haber error en el almacenamiento del segmento en memoria (del router). Se cumple el principio terminal a terminal en el diseo de sistemas: las funcionalidades deben implementarse terminal a terminal, de forma que las funciones incluidas en los niveles inferiores pueden ser redundantes o escasamente tiles si se comparan con el coste de proporcionarlas en un nivel superiorProfesor: Carlos Elvira Izurrategui

ndice1. 2. 3.

La capa de transporte y sus servicios. Multiplexacin y demultiplexacion. Transporte sin conexin: UDP.

4.5. 6. 7.

Principios de un servicio de transferencia de datos fiable.Transporte orientado a la conexin: TCP. Principios de control de congestin. Mecanismo de control de congestin de TCP.


Servicio de transferencia de datos fiable.Un servicio de transferencia de datos fiable puede aparecer en capa de transporte, capa de enlace y en capa de aplicacin. Es uno de los problemas que ms afectan a las redes de computadores. Modelo de abstraccin del servicio. El protocolo implementa el modelo.Se proporciona a las entidades de la capa superior un canal fiable por el cual pueden enviar los datos Los protocolos de las capas inferiores pueden ser no fiables, por lo que se complica el modelo y la implementacin. Diseo incremental en ambos lados emisor y receptor.Profesor: Carlos Elvira Izurrategui

Servicio de transferencia de datos fiable.Implementacin del modelo.El lado emisor es invocado desde la capa superior. El lado receptor es llamado desde una capa inferior.

Se utilizan funciones o procedimientos con parmetros (informacin, paquetes, segmentos, datos).


Servicio de transferencia de datos fiable.Rdt_send(): reliable_send) Deliver_data() Rdt_rcv(): reliable receive Udt_send(): unreliable send


Servicio de transferencia de datos fiable.rdt_send(): llamada desde capa superior, (ej.: aplic.). Pasar los datos a entregar en el receptor deliver_data(): llamada por rdt para repartir datos a capa sup.

Emisor

Receptor

udt_send(): llamada por rdt, para transferir paquetes al canal no fiable.

rdt_rcv(): llamada cuando llega un paquete en el lado receptor del canal


Construccin del protocolo.Considerar transferencia de datos unidireccional (simplex). La realidad es full-duplex (bidireccional). En cada lado crear una FSM (Finite-State Machine)Crculo: estados Flechas: transiciones. Leyendas: eventos y acciones.

Evento que origina la transicin de estado Acciones cuando tiene lugar el suceso

Estado: situacin del sistema en un instante dado. El estado siguiente est determinado por un nuevo evento

Estado 1

evento acciones

Estado 2


Construccin del protocolo. Rdt 1.0Canal subyacente fiable:Sin prdida de datos. Sin errores.

Lado emisor acepta datos de la capa superior a travs del suceso rdt_send(datos). Crea un paquete con datos packet=make_pkt(data) y enva un paquete al canal udt_send(packet). Lado receptor recibe un paquete del canal subyacente a travs del suceso rdt_rcv(packet). Crea un paquete con datos packet=make_pkt(data) y enva un paquete al canal udt_send(packet).rdt_send(data) packet = make_pkt(data) udt_send(packet)Esperar una llamada de abajo

Esperar una llamada de arriba

rdt_rcv(packet) extract (packet,data) deliver_data(data)

Emisor

ReceptorProfesor: Carlos Elvira Izurrategui

Construccin del protocolo. Rdt 1.0Protocolo simple. No hay diferencia entre unidad de datos y paquete. Todo el flujo va del emisor al receptor (no hay realimentacin). El receptor puede recibir los datos tan rpido como el emisor los enva. No hay necesidad de solicitar ralentizacin al emisor.


Construccin del protocolo. Rdt 2.0Modelo ms realista supone canal subyacente con posibilidad de corrupcin de bits. Analoga: escenario de dictado de mensajesReconocimiento positivo: De acuerdo. Reconocimiento negativo: Por favor, repita Mensajes o seales de control que permiten al receptor hacer saber al emisor que se ha recibido paquetes con o sin errores.

Protocolos ARQ (Automatic Repeat ReQuest). Deben disponer de 3 capacidades adicionales.Deteccin de errores, en el receptor.Recordar comprobacin de errores en UDP. Tcnicas mltiples para detectar y/o corregir errores. Se aaden bits adicionales a los datos originales.

Realimentacin del receptor, al emisor.Respuestas de acuse de recibo positivo: ACK (acknowledgement). Respuestas de acuse de recibo negativo: NAK (negative ACK). Con un seal binaria: 1 ACK; 0 NAK.

Retransmisin: paquete con errores ser transmitido de nuevo por el emisor.

Protocolo de parada y espera (stop-and-wait-protocol).El emisor no puede recibir ms datos de capa superior, no puede ocurrir mientras espera un ACK o NAK, y salga de ese estado. Justificacin de la necesidad de 2 estados distintos en el emisor


Construccin del protocolo. Rdt 2.0rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK

receptorrdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

emisor

Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)


Construccin del protocolo. Rdt 2.0 con errorrdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK

rdt_rcv(rcvpkt) && corrupt(rcvpkt)udt_send(NAK)


En el estado wait for ACK or NAK Rdt2.0 no puede obtener ms datos de la capa superior. Protocolos de parada y espera Stop-and-wait protocol



Construccin del protocolo. Rdt 2.0 sin errorrdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)




Construccin del protocolo. Rdt 2.0 fallosY si el paquete ACK o NAK se corrompe? Tres posibilidades:Recordar escenario de dictado de mensajes. E1: mensaje. R: `de acuerdo`, `por favor repita`. Corruptos. E2: cmo dice? Problemas: R en distinguir E1 y E2; E2 puede estar corrupto. Aadir bits para detectar y corregir errores. No se soluciona la prdida de paquetes. E reenva el paquete de datos al R al recibir un ACK o NAK alterado. Problema: paquetes duplicados en el canal E-R. El receptor no sabe si el ACK o NAK llega al E. No sabe si el paquete contiene datos nuevos o es una retransmisin del ltimo paquete.

Solucin aplicada: aadir campo nuevo que numere los paquetes de datos (Nmero de secuencia).El receptor comprueba el nmero de secuencia para ver si el paquete contiene datos nuevos o es una retransmisin. El protocolo de stop-and-wait utiliza un bit en el numero de secuencia. Si el bit mantiene el valor: retransmisin de paquete. Si el bit conmuta (desplazamiento a izquierdas): nuevo paquete.

Protocolo Rdt2.1:Posee el doble de estados que rdt2.0. El protocolo refleja si el paquete que enva el E o el que recibe el R incluye un nmero de secuencia 1 o 0.Profesor: Carlos Elvira Izurrategui

Construccin del protocolo. Rdt 2.1rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) &&Wait for call 0 from above Wait for ACK or NAK 0

( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Wait for ACK or NAK 1

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt)

Wait for call 1 from above

rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)


Construccin del protocolo. Rdt 2.1rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Wait for 0 from below Wait for 1 from below rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)


Construccin del protocolo. Rdt 2.1En el emisor:Se aade el num. sec. en el pkt. Este num. sec. puede tomar valores 1 o 0. Debe comprobar si ACK o NAK estn corruptos.

El receptor:Debe comprobar si el paquete recibido est duplicado.El propio estado indica si est esperando un 0 o un 1 en num. sec.


Construccin del protocolo. Rdt 2.2 Misma funcionalidad que rdt2.1. Solo utiliza ACKs En el receptor:En lugar de enviar un NAK, enva 2 respuestas ACKs. Incluye el nmero de secuencia del paquete que est siendo confirmado. make_pkt(ACK, 1, checksum)

En el emisor:Recibe 2 repuestas ACKs consecutivas y duplicadas; equivale a corrupto. Comprueba el num sec del paquete que est siendo confirmado.isACK(rcvpqt,1).


Construccin del protocolo. Rdt 2.2rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || Wait for Wait for isACK(rcvpkt,1) ) ACK call 0 from 0 udt_send(sndpkt) above

sender FSM fragment

rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

Wait for 0 from below

receiver FSM fragment

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK,1, chksum) udt_send(sndpkt)Profesor: Carlos Elvira Izurrategui

Construccin del protocolo. Rdt 3.0 Canal subyacente puede perder paquetes (normal el redes).Cmo detectar la prdida de paquetes. Pueden ser paquetes de datos o paquetes ACK. Solucin con temporizadores. Qu hacer cuando se pierde un paquete.

Solucin a la prdida de paquetes.El emisor debe esperar el tiempo suficiente como para estar seguro de que se ha perdido un paquete. Al menos el emisor debe esperar un RTT (ms tiempo de procesamiento en el receptor).Es un tiempo muy difcil de estimar. El protocolo debe detectar la prdida cuanto antes sea posible. Mtodo: el emisor adopta un mtodo que selecciona juiciosamente un intervalo de tiempo tal que sea probable que el paquete se pierda (no es seguro la prdida). Profesor: Carlos Elvira Izurrategui

Construccin del protocolo. Rdt 3.0 Solucin qu hacer ante la prdida?.La retransmisin. El emisor retransmite el paquete si dentro del tiempo establecido (temporizado) no ha recibido un ACK.

Nota: se introduce la posibilidad de paquetes de datos duplicados en el canal.Solucionado con rdt2.2.

Para el emisor la retransmisin es la solucin para todo.Ante la prdida de un paquete de datos. Ante la prdida de un mensaje ACK. Ante un retardo excesivo (en la red) de un paquete de datos o ACK.

Temporizacin: con un temporizador de cuenta descendente (hacia atrs).


Construccin del protocolo. Rdt 3.0rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer Wait for call 0from above Wait for ACK0 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )

rdt_rcv(rcvpkt)

timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer Wait for ACK1 rdt_send(data) Wait for call 1 from above

timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) )

rdt_rcv(rcvpkt)

sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer


Construccin del protocolo. Rdt 3.0 El emisor en algn momento:Debe inicial la temporizacin. Debe responder a una interrupcin del temporizador. Detener el temporizador.

Protocolo de bit alternante: ya que los nmeros de secuencia alternan valores entre 0 y 1.


Construccin del protocolo. Rdt 3.0


Construccin del protocolo. Rdt 3.0


Construccin del protocolo. Rdt 3.0 Rendimiento de rdt 3.0.Ej: emisor y receptor enlazados con:Enlace de 1GB (109 bits).

RTT=30 ms. => tprop=15ms. Paquete de 8000bits.

d trans

L 8000bits = = = 8 s 9 R 10 bps

El ltimo bit del paquete llega al receptor tras t=RTT/2+dtrans=15.008 ms Supongo que dtrans del paquete ACK es despreciable (paquete pequeo), y el receptor enva ACK tan pronto como recibe el ltimo bit de datos. El ltimo bit del paquete llega al receptor tras t=RTT+dtrans=30.008 msProfesor: Carlos Elvira Izurrategui

Construccin del protocolo. Rdt 3.0 Rendimiento de rdt 3.0.Ej: Observar que:El emisor transmite en dtrans=8 s. El emisor tiene que esperar para emitir el siguiente paquete t=RTT+dtrans=30.8 ms Se define la tasa de utilizacin o de uso del canal: fraccin de tiempo que el emisor est transmitiendo mientras est el canal ocupado: .008 L/R U = = 0.00027 = emisor 30.008 RTT + L / R microsec Supone una tasa efectiva de 267kbps (frente al Gbps). Desaprovechamiento Se han despreciado tiempos de procesamientos de protocolos de capa inferior, retardos de routers intermedios => peor rendimiento.Profesor: Carlos Elvira Izurrategui

Rendimiento del protocolo rdt 3.0emisor Trans. del bit1 del pqt1; t=0 Trans. del bit ltimo. pqt1 , t = L / R Llega el bit1 del pqt1 Llega el ltimo bit del pqt1 Envo de mensaje ACK receptor

RTT

Llega mensaje ACK, Envo siguiente pqt, t = RTT + L / R

U

emisor

=

L/R RTT + L / R

=

.00830.008

= 0.00027microsec


Rendimiento del protocolo pipeliningemisorTrans. del bit1 del pqt1; t=0 Trans. del bit ltimo. pqt1 , t = L / R

receptor

RTT

Llega el bit1 del pqt1 Llega el ltimo bit del pqt1. ACK Llega el ltimo bit del pqt2. ACK Llega el ltimo bit del pqt3. ACK

Llega mensaje ACK, Envo siguiente pqt, t = RTT + L / R

Aumento del rendimiento Factor de 3

U

emisor

=

3*L/R RTT + L / R

=

.02430.008

= 0.0008microsecon


Protocolos pipelining.Procesamiento en cadena de varios paquetes, en lugar de stop-and-wait de cada paquete.El emisor enva varios paquetes sin esperar sus respectivos ACKs.

Consecuencias sobre los protocolos de transferencia de datos fiables:Se incrementa el rango de nmeros de secuencia (mltiples pqt. con sus retransmisiones coexisten en el canal). Buffer en el lado emisor con pqt. transmitidos y no reconocidos. Tambin buffer en el receptor. Rangos y buffers dependen de mtodo para recuperar errores con pipelinig. GBN (Go-Back-N). SR (Selective Repeat)Profesor: Carlos Elvira Izurrategui

Protocolo Retroceder N (GBN) Go-Back-N: el emisor transmite simultneamente N paquetes sin tener que esperar a ser reconocidos.Tamao de ventana N: nmero mximo de paquetes no reconocidos. Paquetes transmitidos y reconocidos: [0 base-1]. Paquetes transmitidos y no reconocidos: [base signumsec-1]. Paquetes que pueden ser transmitidos (si hay datos de capa superior): [signumsec base+N]


Protocolo Retroceder N (GBN)N: rango de nmero de secuencia permitidos en cada instante. Bits para el rango k. Rango [0 2k-1] Al evolucionar GBN los rangos de secuencia N se desplazan hacia adelante: Protocolo de ventana deslizante. Lmites finitos de N. Razones:Control de flujo. Control de congestin TCP.

Implementacin de GBN en FMS ampliada.Basado en reconocimientos ACK. No emplea NAK. Aade variables base y signumbase. Aade buffer al emisor.Profesor: Carlos Elvira Izurrategui

Protocolo Retroceder N (GBN) El emisor opera:Si la ventana no est llena crea y enva pqts. Caso contrario la capa superior lo volver a intentar posteriormente (sincronizacin con flag). El reconocimiento ACK es acumulativo: para todos los pqts con un num. sec. 500 segmentos.1 segmento con num. sec= 0. 2 segmento con num. sec= 1000. Etc.

El nmero de reconocimiento incluye el nmero de secuencia del siguiente byte que espera recibir.Considerar full-duplex y host A y B. Ejemplo1: A ha recibido de B bytes [0 539].Siguiente segmento de A a B incluir num. Rec=540.Profesor: Carlos Elvira Izurrategui

TCP. Nmeros de secuencia y reconocim.Ej1: A ha recibido de B bytes [0 539].Siguiente segmento de A a B incluir num. Rec=540.

Ej2: A ha recibido de B bytes [0 539] y [900 1000].Siguiente segmento de A a B incluir num. Rec=540. TCP slo confirma bytes hasta encontrar prdidas Reconocimiento acumulativo.

Ej3: A ha recibido de B bytes [900 1000] y luego [0 539] (desorden en la llegada).OJO. RFC no imponen nada; existen opciones: Receptor descarta bytes del segmentos fuera de orden. Receptor mantiene bytes no ordenados hasta que lleguen el resto (rellenar huecos). Mtodo utilizado en la realidad: eficiencia en la red.


TCP. Ejemplo en TelnetTelnet (RFC 854): conexin remota Host B Host A trabajando bajo TCP. Usuario Sec=4 2, AC K=79, Es iterativa con escribe datos = C host reconoce C eco de (ACK) la caracteres. recepcin Cada carcter C de C, y s= , dato atraviesa la red 43 devuelve ACK= =79, 2 veces. Sec eco C El reconocimiento reconoce host est (ACK) la Sec=4 3, ACK superpuesto al recepcin =80 segmento de del eco datos de Ctiempo Escenario simple de telnetProfesor: Carlos Elvira Izurrategui

TCP. Estimacin del RTT y temporizacin. TCP con prdida de segmentos utiliza retransmisin controlada con temporizadores.Tiempos de temporizacin?Si se definen tiempos cortos => timeout.Retransmisiones innecesarias.

Si se definen tiempos largos =>Reacciones lentas ante prdidas.

Mayores que los RTT de la conexin.RTT vara => estimacin.

Estimacin del tiempo de ida y vueltaRTTMuestra para un segmento: tiempo que transcurre desde que se enva un segmento (pasa a capa IP), hasta que se recibe su correspondiente reconocimiento.Profesor: Carlos Elvira Izurrategui

TCP. Estimacin del RTT y temporizacin.Las implementaciones TCP toman una sla medida de RTTMuestra de un solo segmento transmitido (no coge retransisiones) pero no reconocido. Se toma nuevo valor cada RTT segundos aproximadamente. RTTMuestra flucta de un segmento a otro. => valores atpicos. Valor RTT tpico: estimar algn valor promedio de los valores RTTMuestra:RTTEstimado = (1- )* RTTEstimado + *RTTMuestra

Combinacin ponderada del valor anterior RTTEstimado y RTTMuestra. =0.125.RTTEstimado = 0.875* RTTEstimado +0.125*RTTMuestra

Media mvil exponencialmente ponderada EWMA (Exponential Weight Moving Average). La influencia de las muestras pasadas decrece exponencialmenteProfesor: Carlos Elvira Izurrategui

TCP. Estimacin del RTT y temporizacin.RTT: gaia.cs.umass.edu to fantasia.eurecom.fr350

300

RTT (milliseconds)

250

200

150

100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) SampleRTT Estimated RTT


TCP. Estimacin del RTT y temporizacin.Medida de la variabilidad de RTT a travs de la estimacin de la desviacin tpica RTTMuestra de RTTEstimado:RTTDesv = (1- )* RTTDesv + * |RTTMuestra-RTTEstimado|

Es una media EWMA de la diferencia entre RTTMuestra y RTTEstimado. Si RTTMuestra tienen poca fluctuacin RTTDesv pequeo. Si RTTMuestra tienen gran fluctuacin RTTDesv grande. Valores recomendados =0.25


TCP. Estimacin del RTT y temporizacin. Valor del intervalo de temporizacin.Mayores que los RTTEstimado. Caso contrarioRetransmisiones innecesarias.

Si se definen muy por encima de RTTEstimado =>Reacciones lentas ante prdidas.

Tomar RTTEstimado + margen.Margen grande cuando RTTDesv grande. Margen pequeo cuando RTTDesv pequeo.

Intervalo de temporizacin:IntervaloFinTemporizacin = RTTEstimado + 4 * RTTDesv


ndice1. 2. 3. 4.

La capa de transporte y sus servicios. Multiplexacin y demultiplexacion. Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable.

5.

Transporte orientado a la conexin: TCP.1. 2. 3. 4.

Estructura de TCP Transferencia de datos fiable Control del flujo Gestin de la conexin

6. 7.

Principios de control de congestin. Mecanismo de control de congestin de TCP.


Transferencia de datos fiable en TCPCapa de red de Internet no es fiable:No garantiza la entrega de datagramas (prdidas en cola del router) Tampoco su orden (segn camino escogido). Ni la integridad en sus datos (corruptos por ruido o por mal almacenamiento en memoria).

Los segmentos transportados en estos paquetes pueden sufrir estos problemas. TCP proporciona un servicio de transferencia de datos fiable sobre el servicio de mejor esfuerzo (no fiable) de IP.Garantiza que el flujo de datos que un proceso extrae del buffer de recepcin TCP no est corrupto. No contiene huecos (prdidas de segmentos), ni duplicados. Est en orden, tal y como lo enva el extremo emisor.

Tcnicas de la transferencia de datos fiable:Procesamiento de mltiples segmentos en cadena (pipelining). Reconocimientos acumulados. Retransmisiones realizadas cuando:Hay final de temporizacin. Reconocimiento duplicados.

Pero OJO: slo un nico temporizador de retransmisin, incluso aunque haya varios segmentos trasmitidos y an no reconocidos. (RFC 2988).


Transferencia de datos fiable en TCP Funcionamiento de TCP. Hay 3 eventos importantes en el emisor relacionados con la transmisin y retransmisin de datos.Datos recibidos desde la aplicacin. AccionesCrear segmento TCP con #numsec=SigNumSec. Si (timer no se est ejecutando) IniciarTemporizador.El temporizador est asociado al segmento no reconocido ms antiguo.

Pasar segmento a IP. SigNumSec=SigNumSec+longitud(datos)

Fin de temporizacin. AccionesRetransmitir segmento aun no reconocido con #numsec ms pequeo (antiguo). IniciarTemporizador.


Transferencia de datos fiable en TCPLlegada de un reconocimiento ACKi. AccionesSi(i>BaseEmision){ BaseEmision=i Si (existen actualmente segmentos no reconocidos) Iniciar temporizador }SigNumSec = NumeroSecuenciaIncial BaseEmision = NumeroSecuenciaIncial loop (siempre) { switch(evento) evento: datos recibidos de la aplicacin de la capa superior crear segmento TCP con nmero de secuencia SigNumSec si (el temporizador no se est ejecutando actualmente) iniciar temporizador pasar segmento a IP SigNumSec = SigNumSec + longitud(datos) evento: fin de temporizacin del temporizador retransmitir el segmento aun no reconocideo con el nmero de secuencia ms pequeo iniciar temporizador evento: ACK recibido, con valor de campo ACK igual a i si (i > BaseEmision) { BaseEmision = i si (existen actualmente segmentos aun no reconocidos) iniciar temporizador } } /* fin buble */


TCP fiable. EscenariosHost ASec=9 2, 8 b yt

Host Bes dat os00

Host A

Host B

fin temporizacin

=1 ACK

Sec=92 timeout

Sec=9 2, 8 b ytes d atos Sec= 100, 20 by tes d atos00 0 =1 CK CK=12 A A

perdidoSeq=9 2, 8 b yt es da tos

X

Sec=92 timeout

=100 ACK

BaseEmision = 100 BaseEmision = 120

Sec=9 2, 8 b yt

es dat os

20 K=1 AC

BaseEmisin = 100

BaseEmision = 120

tiempo Escenario de prdida de ACK

tiempo Fin temporizacin antes de tiempoProfesor: Carlos Elvira Izurrategui

TCP fiable. EscenariosHost ASec=9 2, 8 b yt

Host B

es dat os

timeout

Sec=1 00, 20 b

PerdidoBaseEmisin = 120120 CK= A

X

100 CK= A ytes d atos

tiempo Escenario de ACK acumulado


TCP fiable. Intervalos de temporizacinIntervalos de temporizacin:Datos recibidos desde la aplicacin. Acciones IniciarTemporizador.IntervaloFindeTemporizacion = f(RTTEstimado, RTTDesv).

Fin de temporizacin. IniciarTemporizador.IntervaloFindeTemporizacion =2 * timoValorIntervaloFindeTemporizacin. Se trata de propocionar mecanismo simple de control de congestin congesti

Llegada de un reconocimiento ACK. Acciones IniciarTemporizador.IntervaloFindeTemporizacion = f(RTTEstimado, RTTDesv).


TCP fiable. Generacin de ACKsGeneracin de ACKs en TCP: FRC 1122 y 2581 Accin del receptor TCP Evento en el receptorLlegada de un segmento en orden con el nmero de secuencia esperado. Todos los datos hasta el nmero de secuencia esperado ya han sido reconocidos Llegada de un segmento en orden con el nmero de secuencia esperado. Hay otro segmento en orden esperando la transmisin de un ACK Llegada de un segmento desordenado con un nmero de secuencia ms alto que el esperado. Se detecta un hueco ACK retardado. Esperar hasta 500 ms la llegada otro segmento en orden. Si el siguiente segmento En orden no llega en este intervalo, enviar ACK.

Enviar inmediatamente un nico ACK acumulado, reconociendo ambos segmentos ordenados

Enviar inmediatamente un ACK duplicado indicando el nmero de secuencia del siguiente byte esperado (lmite inferior del hueco) reconociendo ambos segmentos ordenados. Enviar inmediatamente un ACK, suponiendo que el segmento comienza en el lmite inferior del hueco.Profesor: Carlos Elvira Izurrategui

Llegada de un segmento que completa parcial o totalmente el hueco existente en los datos recibidos

TCP fiable. Retransmisiones rpidasRetransmisiones: cuando surge fin de temporizacin (timeout). Intervalo timeout grande provoca un retardo en la retransmisin entre los 2 terminales. Solucin: ACKs duplicados provocan retransmisiones rpidas.El receptor detecta llegada de segmento desordenado con nmero de secuencia superior al esperado => hay un hueco en la ventana (falta un segmento)No se utilizan NAK, sino ACKs duplicados. Un ACK duplicado es un ACK que vuelve a reconocer un segmento para el que el emisor ya ha recibido un reconocimiento anterior.

El emisor suele enviar varios segmentos juntos (pipelining) y, si pierde uno, recibir muchos ACKs duplicado seguidos. Si se recibe 3 ACKs duplicado => el emisor realiza una retransmisin rpida (RFC 2581)Profesor: Carlos Elvira Izurrategui

TCP fiable. Retransmisiones rpidasSi se recibe 3 ACKs duplicado => el emisor realiza una retransmisin rpida (RFC 2581)Host A Host B

El emisor no necesita esperar la finalizacin de la temporizacin (timeout).evento: ACK recibido, con valor de campo ACK igual a i si (i > BaseEmision) { BaseEmision = i si (existen actualmente segmentos aun no reconocidos) iniciar temporizador } sino { /* ACK duplicado para un segmento ya reconocido */ incrementar el nmero de mensajes ACK duplicados recibidos para i si (nmero de ACKs duplicados recibidos para I = 3) /* Se detecta retransmisin rpica */ reenviar el segmento con nmero de secuencia I }

X

timeout

reenv ia

r 2 nd s egme nto

tiempoProfesor: Carlos Elvira Izurrategui

TCP fiable. GBN o RS?Semejanzas con GBN.TCP tiene reconocimientos acumulados. Los segmentos correctamente recibidos, pero fuera de orden, no son reconocidos individualmente por el receptor.. El emisor necesita:Nmero de secuencia del segmento ms antiguo: BaseEmisin. Nmero de secuencia del siguiente byte que se va a enviar: SigNumSec.

Implementaciones TCP almacenan en buffer recepcin segmentos correctos fuera de orden.Ej: se enva segmentos 1..N y se pierde ACKn, pero los ACKN1 restantes llegan al emisor antes de sus timeout.GBN retransmitira paquetes n, n+1,..N. TCP retransmite paquete n (OJO: si el ACKn+1 no llega antes que su correspondiente timeout) .

RFC 2018: reconocimiento selectivo de TCP.Permite a un receptor TCP reconocer segmentos no ordenados TCP de forma selectiva, sin hacer reconocimiento acumulado del ltimo segmento recibido OK y en orden.


ndice1. 2. 3. 4.

La capa de transporte y sus servicios. Multiplexacin y demultiplexacion. Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable.

5.

Transporte orientado a la conexin: TCP.1. 2. 3. 4.

Estructura de TCP Transferencia de datos fiable Control del flujo Gestin de la conexin

6. 7.

Principios de control de congestin. Mecanismo de control de congestin de TCP.


TCP. Control de flujo.TCP dispone de un buffer de recepcin en cada lado de la conexin..Si TCP recibe segmentos correctos y en orden los coloca en el BufferRecepcin. OJO: el proceso aplicacin receptor no tiene porqu leer estos segmentos inmediatamente.Puede estar ocupada haciendo otras tareas/procesos.

Problema: si la aplicacin no lee los segmentos en un breve plazo el BufferRecepcin lo llena el emisor rpido.Solucin: utilizar el servicio de control de flujo. Es un servicio de adaptacin de velocidades; velocidad que transmite la aplicacin emisor frente a la velocidad que recoge la aplicacin receptor.

Distinto concepto que control de congestin: el emisor se atasca por problemas (de congestin) de la red.Profesor: Carlos Elvira Izurrategui

TCP. Control de flujo.Mecanismo de control de flujo en TCP:Variable VentanaRecepcin dinmica en el tiempo: proporciona al emisor una idea del espacio libre en el BufferRecepcin.

TCP full-duplex. El emisor de cada lado de la conexin posee VentanaRecepcin distinta.Ej: Host emisor A enviando archivo grande al host receptor B por TCP.Host receptor B asigna BufferRecepcin a conexin TCP. Variable UltimoByteLeido: n ltimo byte del flujo de datos del buffer ledo por el proceso de aplicacin del host B. Variable UltimoByteRecibido: n del ltimo byte del flujo de datos que ha llegado desde la red y se ha almacenado en el BufferRecepcin del host B.UltimoByteRecibido - UltimoByteLeido No aumentar VentanaCongestion. Velocidad alta no hay retardo o BWenlace alto => Aumenta VentanaCongestion.

TCP es auto-temporizado: utiliza sus propios reconocimientos para provocar (temporizar) sus incrementos de VentanaCongestion.

Principios del mecanismo de ajuste de VentanaCongestion:Un segmento perdido => congestin; la velocidad del emisor TCP debe reducirse. Un segmento que ha sido reconocido=> no hay congestin; la velocidad del emisor TCP debe aumentarse.Profesor: Carlos Elvira Izurrategui

Control de congestin en TCPTanteo del ancho de banda: aumentar la velocidad de transmisin hasta provocar prdidas, y reducir as velocidad de nuevo.Detalles del algoritmo de control de congestin de TCP [Jacobson 1988]:Arranque lento (slow start). Evitacin de la congestin (congestion avoidance). Recuperacin rpida (fast recovery). Se corta el crecimiento exponencial, al detectar prdida de paquete. Se actualiza VentanaCongestion con un valor de la mitad del valor anterior.


Algoritmo de congestin. Arranque lento Arranque lento: al iniciar conexin TCP, valor de VentanaCongestin=1MSS.Velocidad de transmisin: 1MSS/RTT. Se incrementa en 1 unidad en cada reconocimiento transmitido. Valores: 1, 2, 4, Exponencial. Se duplica en cada RTT. La velocidad inicial baja (de aqu el nombre) y crece exponencialmente. La finalizacin del crecimiento se da:Prdida de paquete => VentanaCongestin=1 Variable umbral del arranque lento: se actualiza al valor VentanaCongestin/2.Se termina arranque lento y se pasa a la etapa evitacin de la congestin.Profesor: Carlos Elvira Izurrategui

Algoritmo de congestin. Arranque lento3 paquetes ACK duplicados (retransmisin rpida).Se entra en la etapa de recuperacin rpida.RTT

Host A

Host Bone segm ent

Orgenes del arranque lento: Jacobson 1988.

two segm ents

four segm ents

time


Algoritmo de congestin. Evitacin de la . Evitacin de la congestinVentanaCongestin/2 (desde arranque lento)

Valor de VentanaCongestin+1. Incremento lineal.Mtodo ms conservador.

Implementacin ms habitual:VentanaCongestin=MSS/VentanaCongestin

Parada del crecimiento lineal:En caso de final de temporizacin:VentanaCongestin=1. Umbral=VentanaCongestin/2.

En caso de 3 ACKs duplicados.VentanaCongestin=(VentanaCongestin/2)+3. Umbral=VentanaCongestin/2. Paso a estado de recuperacin rpida.


Algoritmo de congestin. Recuperacin rpid Recuperacin rpida.Se entra desde arranque lento o evitacin de la congestin + 3 ACKs duplicados. VentanaCongestin+1(MSS) por cada ACK duplicado recibido de un segmento que causo la entrada en recuperacin. Se finaliza:Llegada de 1 ACK del segmento que falte. Si se produce un fin de temporizacin, se pasa a arranque lento.VentanaCongestin=1 Umbral=VentanaCongestin/2.

Recuperacin rpida: mecanismo TCP recomendado (RFC 2581).Profesor: Carlos Elvira Izurrategui

Algoritmo de congestin. Recuperacin rpid Recuperacin rpida.TCP Tahoe:VentanaCongestin=1. Arranque lento.

TCP Reno incorpora recuperacin rpida.


Control de congestin TCPState Slow Start (SS) Event ACK receipt for previously unacked data ACK receipt for previously unacked data Loss event detected by triple duplicate ACK Timeout TCP Sender Action CongWin = CongWin + MSS, If (CongWin > Threshold) set state to Congestion Avoidance CongWin = CongWin+MSS * (MSS/CongWin) Commentary Resulting in a doubling of CongWin every RTT

Congestion Avoidance (CA) SS or CA

Additive increase, resulting in increase of CongWin by 1 MSS every RTT Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. Enter slow start

Threshold = CongWin/2, CongWin = Threshold, Set state to Congestion Avoidance Threshold = CongWin/2, CongWin = 1 MSS, Set state to Slow Start Increment duplicate ACK count for segment being acked

SS or CA

SS or CA

Duplicate ACK

CongWin and Threshold not changed


Control de congestin TCP Control de congestin AIMD (Additive-Increase MultiplicativeDecrease).Evitacin de congestin.Crecimiento lineal (aditivo) de

VentanaCongestin.Final de etapa:Decrecimiento multiplicativo.

Diente de sierra: tanteo del ancho de banda.

Variantes de Reno (RFC 3782; RFC 2018). TCP Vegas: evita congestin manteniendo buena tasa de transferencia:Profesor: Carlos Elvira Izurrategui

Tasa de transferencia TCP Cul es la tasa de transferencia media (velocidad media) de una conexin de larga duracin?.Valor medio del diente de sierra.Ignorar fases de arranque lento.

Tamao de Ventana: W. Velocidad media de transmisin = W/RTT TCP incrementa W en 1 MSS cada RTT hasta que se de una prdida. Suponiendo RTT y W constantes durante la conexin:Velocidad de transmisin vara entre W/(2RTT) y W/RTT.

Tasa de transferencia media de una conexin = 0.75W/RTTProfesor: Carlos Elvira Izurrategui

Evolucin y futuro de congestin en TCP Control de congestin original (RFC 2581). Evolucin de TCP: altas velocidades de aplicaciones de computacin reticular.Ejemplo: TCP con segmento de 1500 bytes; RTT de 100ms; conexin 10Gbps.W= 119304 segmentos Si se pierden?

Tasa de transferencia media=

Si deseo mantener la tasa media de transferencia perdindose una fraccin L de los transmitidos. 1.22 MSS Probabilidad de prdidas: 2 10-10 RTT L 1 prdida cada 5000000000 segmentos

Nuevos TCP en estos entornos.Profesor: Carlos Elvira Izurrategui

Tema2

Documents

Transcript of Tema2