SISTEMAS OPERATIVOS Y REDES I

Trabajo Práctico 2
Año Lectivo 2016

Profesores:
Verghelet, Paula
Trigila, Mariano Diego

Alumnos:
Gerszenswit Rober, 36716590/2016, rober.gerszen@gmail.com
Barrientos Damiana, 32663440/2016, damianal.barrientos@gmail.com
 Redes y sistemas operativos I | Trabajo Práctico 2

Índice

Introducción ............................................... 3
Encabezado TCP ............................................. 3
Handshake TCP .............................................. 5
Cierre de comunicación ..................................... 6
Control de congestión ...................................... 7
Control de flujo ........................................... 7
AIMD ....................................................... 7
Causas de congestión ....................................... 9
Ventana de congestión ..................................... 10
Slow Start ................................................ 10
Fast Retransmit y Fast Recovery ........................... 10
TCP Tahoe, Reno y Vegas ................................... 11
RSVP ...................................................... 12
Bibliografía .............................................. 13

P á g i n a 2 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

Introducción:
El protocolo de control de transmisión (TCP, por sus siglas en ingles), cuya especificación se
encuentra en el RFC 793, publicado en septiembre de 1981, es junto con el protocolo UDP, la base
de la capa de transporte en la pila de protocolos TCP/IP sobre la que funciona Internet. [2005, The
TCP/IP guide v3, Charles M. Kozierok]
Se puede definir a TCP por los servicios que brinda a la capa de aplicación como un protocolo
orientado a la conexión, end-to-end, confiable y de flujo de bytes [2012 TCP/IP Illustrated Vol. 1
The protocols.,K.R. Fall & W.R. Stevens ; RFC 793, IETF]
Entre sus características más importantes se hallan las siguientes:
• Orientado a la conexión: Ningún flujo de datos de aplicación entre dos hosts se realiza
antes de establecer una conexión previa entre ambos. (Three way handshake TCP).
• Entrega confiable: Números de secuencia se utilizan para identificar los flujos de bytes
correctamente recibidos, cuales son los siguientes que se esperan recibir y cuales se están
enviando en el otro sentido. Si se detecta un segmento de bytes no recibido, la entidad
TCP retransmitirá ese segmento.
• Adaptación a la red: TCP se pensó para funcionar sobre un servicio de datagramas no
confiable sobre redes heterogéneas. TCP esta diseñado para aprender dinámicamente las
características de la red en la que opera y ajusta su funcionamiento para maximizar el
troughput útil/valido (algo que Tanenmabum llama "goodput") sin sobrecargar la red y por lo
tanto congestionarla (troughput alto pero goodput bajo). Para lograr este cometido
implementa una serie de técnicas teóricas tales como Max-Min fairness y AIMD.
• Control de flujo: TCP administra buferes de datos y coordina el trafico para evitar
overflow. Técnicas de ventana deslizante y ventana de congestión permiten cumplir con
este cometido.
Encabezado de TCP:
Antes de proceder a responder a las consignas propias del tp se pasa a describir brevemente el
encabezado TCP.[RFC 793]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

P á g i n a 3 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

Source Port: 16 bits

El número del puerto de origen.
Destination Port: 16 bits
El numero del puerto de destino.
Sequence Number: 32 bits
El numero de secuencia del primer byte de datos en este segmento (Cuando SYN esta presente el
primer byte de datos es es el numero de secuencia inicial (ISN) + 1).
Acknowledgment Number: 32 bits
Si el bit de control ACK se encuentra establecido a 1, este campo contiene el valor del siguiente
numero de secuencia que el emisor del segmento esta esperando recibir. Una vez que se
establece una conexión, este bit siempre se encuentra establecido a 1.
Data Offset: 4 bits
El numero de palabras de 32 bits que se hallan en el encabezado TCP. Indica donde comienzan los
datos. El tamaño mínimo del encabezado es de 20 bytes (sin el campo opcional) y de un máximo
de 60 bytes en caso de contener campos opcionales(limitado por el máximo numero que puede
almacenar el campo Data Offset).
Reserved: 6 bits
Reservado para uso futuro, deben ser 0. Posteriores RFC que implementan mejoras sobre TCP
clásico usan parte de los bits de este campo. A saber:
• NS (1 bit): véase RFC 3540.
• CWR (1 bit): Ventada de congestión reducida. véase RFC 3168

• ECE (1 bit): Notificación explicita de congestión. véase RFC 3168.

Control Bits: 6 bits (de izquierda a derecha):
Cuando los bits están establecidos en 1, este es su significado:

• URG: El campo de puntero urgente es significativo.

• ACK: El campo de acuse de recibo es significativo.

• PSH: Se debe ejecutar la función de push (pasar el flujo de bytes bufereado a la capa de
aplicación).

• RST: Reiniciar la conexión.

• SYN: Sincronizar números de secuencia.

• FIN: No hay mas datos a enviar por el emisor de este segmento.

Window: 16 bits
El numero de bytes comenzando con el indicado en el campo de acuse de recibo que el emisor de
este segmento puede aceptar.
Checksum: 16 bits
Campo de verificación de suma.

P á g i n a 4 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

Urgent Pointer: 16 bits

Este campo comunica el valor actual del puntero urgente como un desplazamiento positivo
tomando como base al numero de secuencia de este segmento. Campo interpretado solo si el bit
de control URG esta establecido.
Options: variable
Campos opcionales van a aquí. Futuras mejoras al protocolo almacenan campos adicionales de
control en esta zona. e.g. SACK, marcas de tiempo.
● Describir cómo es el handshake TCP.

La figura muestra una linea de tiempo de lo que pasa durante el establecimiento de una conexión
TCP mediante el saludo de tres vías (Handshake TCP), generalmente toman lugar los siguientes
eventos:
1. El cliente envía un segmento de control SYN (osea un segmento TCP con el bit SYN en 1
dentro la cabecera TCP, sin datos de carga) especificando el numero de puerto del par al
que desea conectarse y el número de secuencia inicial ISN=x de su flujo de bytes
almacenado en el campo SEQ.Tipicamente se envia el segmento de control con una o mas
opciones en este punto.
2. El servidor responde con su propio segmento de control SYN conteniendo su propio
numero inicial de secuencia ISN=y almacenado en el campo SEQ. El servidor a su vez
tiene el bit ACK establecido en 1 y el campo acknowledgement indica un acuse de recibo
acumulativo (el segmento SYN consume una secuencia de bytes). El numero de este
campo en cuestión informa el siguiente byte de la secuencia que el servido espera recibir.
En caso de perdida este paquete es retransmitido.
3. El cliente hace acuse de recibo acumulativo del segmento SYN enviado por el servidor.
Notese que se incrementa el campo acknowledgement pero no el campo sequence, esto
es así debido a que un segmento de control ACK no consume secuencias de bytes.
El intercambio de estos tres segmentos entre hosts cliente y servidor completan el establecimiento
de la conexión y es lo que se conoce como el saludo de tres vías TCP. Posteriomente cliente y
servidor pueden intercambiar datos. [TCP/IP Illustrated vol. 1 2a Ed. pág. 596].

P á g i n a 5 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

● Describir cómo termina una comunicación TCP.

La figura muestra como una conexión tcp es terminada en (tambien llamado cierre de conexión) en
este caso por el cliente. Cualquier host o terminal puden iniciar una operación de cierre.
Tradicionalmente es más comun que el cliente sea quien inicia el cierre de una conexión sin
embargo hay servidores que suelen iniciar el cirre de la conexión cuando completan una solicitud, a
su vez es posible que se de el caso de un cierre simultaneo de conexión. [TCP/IP Illustrated vol
1. ].
La secuencia de cierre es como sigue:
1. El cliente envia un segmento de control FIN especificando en numero actual de secuencia
que el servidor espera recibir. El segmento FIN tambien incluye un ACK por los ultimos
datos enviados por el servidor.
2. El servidor reponde enviando un acuse de recibo acumulativo (el segmento FIN consume
un número de secuencia). En este momento la aplicación que hace uso de la conexión es
notificada para que tome las medidas necesarias ante este evento.
3. Posterior a esto el servidor envia su propio segmento de control FIN. Es recibido por el
cliente este envia un ACK al servidor y da por terminada la conexión en el sentido
cliente→servidor.
4. El servidor recibe el ACK y da por terminada la conexión en el sentido servidor→cliente.
Si el FIN del servidor se pierde, el mismo se retransmite hasta recibir un ACK.
Y así es cómo finalmente termina una conexión TCP de forma normal.

P á g i n a 6 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

● ¿Qué es el control de congestión? ¿Para qué sirve?

¿Cómo se utiliza en TCP?
El control de congestión es una serie de comportamientos determinados por algoritmos que cada
entidad TCP implementa en un intento de prevenir que la red sea sobrecargada debido a que la
cantidad de paquetes que se inyectan en ella es mayor al troughput o capacidad de procesamiento
de datos de los nodos que la componen. Esto genera toda una serie de problemas tales como
subida de la latencia, dropeo de paquetes en routers debido a que sus buffers (colas
generalmente) se llenan e incluso bloqueo de las conexiones. Cuando la carga de la red llega a
niveles criticos de congestión ocurre un fenomeo llamado colapso de la red en la que a medida que
la carga que se pone en ella aumenta, disminuye enormemente el “goodput” (tráfico útil en la red,
througput de información relevante a los usuarios de la red).
Dicho esto, el control de congestión tiene como objetivo que la congestión en una red dada no
aumente a niveles donde potencialmente la red puede colapsar y en lo posible disminuirla. Esto se
logra en esencia bajando la velocidad en la que los nodos de la red se comunican.
Cuatro algoritmos para el control de congestión en TCP se especifican en el RFC 5681. A saber:

• slow start

• congestion avoidance

• fast retransmit

• fast recovery
Estos algoritmos trabajan ajustando el límite de datos que cualquier entidad TCP puede inyectar a
la red en un momento dado. La cantidad de datos que puede enviar una entidad TCP se actualiza
dinamicamente en un campo llamado “Ventana de congestión” y “Ventana de receptor”, la cantidad
máxima de datos a enviar esta determinado por el mínimo entre los valores de estos dos campos.
● ¿Qué es el control de flujos TCP?
El control de flujos en TCP es la comunación entre las distintas entidades TCP de sus respectivas
capacidades de procesamiento de datos a fin de disminuir o aumentar (si es posible) la cantidad de
datos que se intercambian de forma tal que no se produzca una sobrecarga que lleve a la perdida
de paquetes y a su vez aumentar lo más posible el througput. Esto se logra mediante el ajuste
dinámico y el intercambio de información relativa al tamaño de la ventana deslizante de cada host.
● Describir AIMD.
AIMD es una ley de control de asignación de ancho de banda a distintos usuarios de una red que
teoricamente garantiza o converge hacia una asignación equitativa (todos los usuarios
eventualmente terminan con un ancho de banda aproximadamente igual) y eficiente (el canal
eventualmente se aprovecha en su casi totalidad, evitando así desperdiciar los recursos de la red).
Sus siglas AIMD provienen del ingés Additive Increase / Multiplicative Decrease es decir,
incremento aditivo, decremento multiplicativo. Esto describe en esencia lo que esta ley hace a la
hora de establecer el aumento o la reducción del ancho de banda de distintos hosts en una red.

P á g i n a 7 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

La figura muestra como la asignación del ancho de banda a los hosts/usuarios 1 y 2 varia a lo largo
del tiempo siguiendo la ley de control AIMD y como su distribución converge hacia la interseccion
entre la asignación equitativa y eficiente.
Si no se ha alcanzado la máxima utilización del ancho de banda disponible, ambos hosts
incrementan linealmente (esto es en cantidades fijas) su ancho de banda.
Cuando el ancho de banda de ambos supera la linea de eficiencia quiere decir que se esta
generando congestión, para subsanar este problema y a la vez buscar equidad en la asignación del
ancho de banda ambos hosts reducen en una cantidad multiplicativa su ancho de banda (así si por
ejemplo, el host 2 tiene asignado 4 unidades de ancho de banda y el host 1 solo tiene 2 al
momento de generar congestón. El host 2 verá reducido su ancho de banda en dos unidades,
mientras que el host 1 solo en una, en el caso de que el factor multiplicativo sea 1/2.)
Hecha la reducción de la asignación se vuelve a incrementar linealmente el ancho de banda de
ambos y el ciclo se repite.
Este patrón ciclico dictado por esta ley produce un gráfico de ancho de banda en función del
tiempo para un host dado que evoca a los dientes de una sierra y que oscila alrededor de la recta
que representa el ancho de banda máximo disponible en la red para ese host.

P á g i n a 8 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

● ¿Cuáles son las causas de congestión? ¿Cómo se

manifiestan?

Sea esta figura donde:

Ancho de banda de enlace A→R1 = 1mbps
Ancho de banda de enlace B→R1 = 1mbps
Ancho de banda de enlace R1→R2 = 2 mbps
Ancho de banda de enlace R2→C = 0,5 mbps
Velocidad de procesamiento de R1 = 1mbps
Velocidad de procesamiento de R2 = 1mbps

Las causas de congestión en una red se dan por diferentes motivos:

• Velocidad de procesamiento insuficiente en los nodos. e.g. R1 recibe de A y B datos a 1

mpbs que tienen como destino a C, por lo que en total recibe 2mbps que debe procesar y
retransmitir a R2; como su velocidad de procesamiento es de 1 mbps, por cada segundo el
espacio libre en su buffer interno se reduce en un mb, si las transimisiones de A y B son lo
sufientemente largas, el buffer de R1 se sobregargara produciendo perdida de paquetes y
congestión

• Velocidad del enlace insuficiente: Veamos el caso del enlace de R2 a C. Digamos que R2
recibe a una tasa constante de 1mbps informacion desde R1 que tiene como destino a C,
como R2 puede 1mbps su bufer no esta sujeto a un eventual overflow por velocidad de
procesamiento insuficiente. Sin embargo la velocidad del enlace de R2 a C es de 0.5mbps
por lo que si el flujo de datos que R2 recibe de R1 es lo sufientemente grande,
eventualmente el buffer de R2 se llenará ya que no puede retransmitir la información a una
tasa mayor o igual a la que ingresa produciendo overflow, perdida de paquetes y
congestión.
La congestión como efecto no deseable en las redes se manifiesta a través de perdida de paquetes
(cuando ocurre un overflow) y por el aumento de la latencia (cuando los paquetes terminan
encolados en nodos intermedios).

P á g i n a 9 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

● ¿Qué es la ventana de congestión? ¿Cómo se calcula?

En las primeras versiones de TCP usadas en ARPANET se utilizaba un tamaño de ventana
deslizante fijo para el control de flujo. A medida que esta red crecía en tamaño empezó a
observarse un curioso fenomeno:
Los enlaces se mantenian ocupados enviando información a través de la red pero la tasa de
tranferencia se reducía notablemente. Así se dislumbró por primera vez lo que conocemos como
congestión.Dicho fenomeno amenazaba seriamente al futuro de la red completa ya que a medida
que el tráfico aumenta por la adición de nodos también lo hace la carga, aumentando la frecuencia
con la que la congestión y el eventual colapso de la red ocurrían.
No es sino hasta fines de los años 80 que, de la mano de Van Jacobson, se introducen los
principios de control de congestión y soluciones prácticas cuyas especificaciones se dan las
versiones Tahoe y Reno de TCP, en 1988 y 1990 respectivamente.
La ventana de congestión (cwnd) es una solución que se implementa sobre la ventana deslizante
previamente definida en versiones anteriores de TCP y que permite el ajuste dinamico de esta para
que cada entidad TCP pueda regular su propio uso de la red y así evitar la congestión. Limita
desde el lado del emisor la cantidad de datos que este puede inyectar a la red antes de recibir un
ACK. La cantidad de datos que pueda inyectar finalmente estará dada por el mínimo entre la
ventana de congestion y la ventana definida por el receptor.
Su calculo inicial, tal como se detalla en el RFC 5681 se da de la siguiente forma:
El valor inicial (IW) de la ventana de congestión (esto es el valor que toma luego de establecer la
conexión mediante un three-way handshake) debe tener como límite superior el siguiente:

Si SMSS > 2190 bytes:

IW = 2 * SMSS bytes y no puede ser más de 2 segmentos

Si (SMSS > 1095 bytes) y (SMSS <= 2190 bytes):

IW = 3 * SMSS bytes y no puede ser más de 3 segmentos

Si SMSS <= 1095 bytes:

IW = 4 * SMSS bytes y no puede ser más de 4 segmentos

SMSS: Sender maximum segment size (tamaño maximo de segmento del emisor)

● ¿Qué es Slow Start?

Slow Start es un algoritmo usado por un emisor TCP para controlar la cantidad de datos que estan
siendo inyectados en la red. Slow Start se utiliza en el incremento inicial del tamaño de la ventana
de congestión o cuando se produce un reinicio de la conexión.
Este algoritmo incrementa exponecialmente el tamaño de la ventanda inicial con cada ACK recibido
hasta llegar al valor declarado en otra variable de estado llamada slow start threshold (ssthresh).
Cuando cwnd > ssthresh se pasa a un incremento lineal del tamaño de cwnd por RTT usando un
algoritmo de congestion avoidance (evitación de congestión) (basado en AIMD, sin embargo cabe
destacar que no realiza un decremento multiplicativo sino que siempre vuelve al tamaño de la
ventana inicial).
● Describir las diferencias existentes entre Fast Retransmit y Fast Recovery.
Fast Retransmit es un algoritmo heurístico que infiere la perdida de segmentos mediante la llegada
de ACKs duplicados sucesivos. Cuando detecta 3 ACKs duplicados sucesivos infiere que el

P á g i n a 10 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

segmento siguiente al ACK se perdió y lo retransmite y espera a que los ACKs duplicados dejen de
llegar o se produzca un timeout para volver a transmitir.
Por otro lado Fast Recovery es un algoritmo heurístico que infiere la llegada de segmentos al
receptor debido a la llegada de ACKs duplicados sucesivos. Cada vez que un ACK llega al emisor
quiere decir que un segmento abandono la red y ha llegado efectivamente al receptor. Valiendose
de este hecho, el algoritmo Fast Retransmit aumenta el tamaño de la ventana dezlizante en
cwnd/2 artificialmente e inyecta tantos segmentos nuevos a la red como la nueva ventana de
congestión le permite. Esto lo hace durante el tiempo en el que el algoritmo de Fast Retransmit se
encuentra a la espera de un ACK no duplicado. Cuando finalmente llega un ACK no duplicado y si
las perdidas de paquetes son generalmente raras, el uso de Fast Recovery habrá permitido
recuperar el flujo de la transimisión sin tiempos muertos.
● Describir las diferencias entre TCP Tahoe, TCP Reno y TCP Vegas.

• TCP Tahoe: Se refiere al algoritmo de control de congestión propuesto por Van Jacobson,
Utiliza Slow Start para iniciar la transmisión y el decrementa el tamaño de ventana de
congestion al valor de tamaño inicial cada vez que un timeout ocurre, lo que no es
deseable ya que disminuye en exceso la tasa de envio de datos y produce una sobrecarga
de la red.
Para congestion avoidance Tahoe usa AIMD. La perdida de un segmento se toma como un
signo de congestión y entonces Tahoe asigna como nuevo ssthresh a cwnd/2, decrementa
el tamaño de cwnd al tamaño inicial, lo aumenta exponecialmente usando slow start y
luego crece linealmente hasta volver a detectar congestión.
Tahoe no envía ACKs inmediatos sino acumulativos, debe esperar un RTT completo para
detectar perdida de segmentos. TCP Tahoe involucra al RFC 1122.

• TCP Reno: Reno mantiene los principios de Tahoe pero incorpora ACK inmediato y los
algoritmos Fast Retransmit y Fast Recovery, esto le permite detectar perdidas de
segmentos antes de un RTT y no detener el envío de paquetes totalmente sino
simplemente bajar la tasa de envio. TCP Reno involucra al RFC 2001
• TCP Vegas: Vegas se basa en Reno pero introduce modificaciones en fast retransmission,
congestion avoidance y slow start.
Para fast restransmit no espera a que se produzca una perdida de paquetes (y por lo tanto
congestión) para reenviar segmentos sino que usa una técnica que infiere el RTT para
cada segmento y por lo tanto su timeout. Cuando recibe un ACK duplicado Vegas compara
si el RTT real esta dentro del timeout calculado o lo supera. Si lo supera inmediatamente
retransmite el segmento que cree perdido.
Para congestion avoidance, Vegas estima el trhougput de la red y solo incrementa el
tamaño de la ventana de congestion cuando este es aproximadamente igual al medido en
la red. Si el througput real es significativemente menor lo toma como una señal de
congestión incipiente y no incrementa el tamaño cgwnd.
Con respecto a Slow Start, Vegas incorpora su mecanismo de deteccion de congestion a
slow-start con pequeñas modificaciones. Para detectar y evitar congestión durante slow
start Vegas solo permite el crecimiento exponencial de cwnd 1 vez por cada RTT. Entre
medio la ventana de congestión se mantiene fija así una comparación válida de las tasas
de envío estimadas y las actuales pueden ser hechas. Cuando la tasa de envio acutal cae
por debajo de la tasa esperada en una cierta cantidad (lo que los autores del paper llaman
el “límite”) Vegas cambia de Slow Start a AIMD.
TCP Vegas involucra al RFC1323 y es anunciado en el paper TCP Vegas: New techniques
for congestion detection and avoidance (1994), no se haya en un RFC propiamente dicho.

P á g i n a 11 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

● ¿Qué es RSVP (RFC 2205)?

RSVP es un protocolo de reservación de recursos diseñado para permitir a las aplicaciones de
internet obtener diferentes calidades de servicio (QoS) para sus flujos de datos reconociendo que
diferentes aplicaciones requieren distintas capacidades de rendimiento por parte de la red. e.g.
Ciertas aplicaciones requieren confiabilidad a la hora de recibir los datos mas no hace falta que la
entrega sea inmediata. Por otro lado aplicaciones de streaming requerirán entrega inmediata pero
no necesariamente confiable. RSVP fue pensado para proveer a las redes IP con la capacidad de
soportar requerimientos de rendimiento heterogeneos de diversas aplicaciones.
Para lograr este cometido RSVP solicita recursos para flujos de datos unidireccionales a todos los
nodos en la ruta entre emisor y receptor.
Emisor y receptor son tratados lógicamente de forma distinta más a alla de que una misma
aplicación puede ser emisora y receptora a la vez.
Se trata de un protocolo auxiliar de Internet que opera sobre la capa IP. No transporta datos sino
que prepara la ruta entre emisor y receptor para asegurar QoS.

P á g i n a 12 | 13
 Redes y sistemas operativos I | Trabajo Práctico 2

Bibliografía

 TCP/IP illustrated.—2nd ed. / Kevin R. Fall, W. Richard Stevens.

 Redes de computadoras, 5ta edición / Andrew S. Tanenbaum & David J. Wetherall.

 RFC 793 Transmission control Protocol - https://tools.ietf.org/html/rfc793

 RFC 1122 Requirements for Internet Hosts - Communication Layers -

https://tools.ietf.org/html/rfc1122

 RFC 1323 TCP Extensions for High Performance - https://tools.ietf.org/html/rfc1323

 RFC 2001 TCP Slow Start, Congestion Avoidance, Fat Retransmit, and Fast Recovery
Algorithms - https://tools.ietf.org/html/rfc2001

 RFC 5681 TCP Congestion Control https://tools.ietf.org/html/rfc5681

 TCP Vegas: New techniques for congestion detection and avoidance (1994)
http://pages.cs.wisc.edu/~akella/CS740/S08/740-Papers/BOP94.pdf

 RFC 2205 Resource ReSerVation Protocol - https://tools.ietf.org/html/rfc2205

 RSVP ReSource ReserVation Protocol -

http://docwiki.cisco.com/wiki/Resource_Reservation_Protocol

 TCP/IP guide http://www.tcpipguide.com

 Curso Online Redes de computadoras por David J. Wetherall. https://www.youtube.com/playlist?

list=PLkHsKoi6eZnzJl1qTzmvBwTxrSJW4D2Jj

P á g i n a 13 | 13