SISTEMAS OPERATIVOS Y REDES I

Trabajo Prctico 2
Ao 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 Prctico 2

ndice
Introduccin . . . . . . . . . . . . . . . . . . . . . . . .3
Encabezado TCP . . . . . . . . . . . . . . . . . . . . . . .3
Handshake TCP . . . . . . . . . . . . . . . . . . . . . . . 5
Cierre de comunicacin . . . . . . . . . . . . . . . . . . .6
Control de congestin . . . . . . . . . . . . . . . . . . . 7
Control de flujo . . . . . . . . . . . . . . . . . . . . . .7
AIMD . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Causas de congestin . . . . . . . . . . . . . . . . . . . .9
Ventana de congestin . . . . . . . . . . . . . . . . . . .10
Slow Start . . . . . . . . . . . . . . . . . . . . . . . . 10
Fast Retransmit y Fast Recovery . . . . . . . . . . . . . .10
TCP Tahoe, Reno y Vegas . . . . . . . . . . . . . . . . . .11
RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Bibliografa . . . . . . . . . . . . . . . . . . . . . . . 13

P g i n a 2 | 13

Redes y sistemas operativos I | Trabajo Prctico 2

Introduccin:
El protocolo de control de transmisin (TCP, por sus siglas en ingles), cuya especificacin 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 aplicacin como un protocolo
orientado a la conexin, 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 caractersticas ms importantes se hallan las siguientes:

Orientado a la conexin: Ningn flujo de datos de aplicacin entre dos hosts se realiza
antes de establecer una conexin previa entre ambos. (Three way handshake TCP).

Entrega confiable: Nmeros de secuencia se utilizan para identificar los flujos de bytes
correctamente recibidos, cuales son los siguientes que se esperan recibir y cuales se estn
enviando en el otro sentido. Si se detecta un segmento de bytes no recibido, la entidad
TCP retransmitir ese segmento.

Adaptacin a la red: TCP se pens para funcionar sobre un servicio de datagramas no

confiable sobre redes heterogneas. TCP esta diseado para aprender dinmicamente las
caractersticas 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 tcnicas tericas tales como Max-Min fairness y AIMD.

Control de flujo: TCP administra buferes de datos y coordina el trafico para evitar
overflow. Tcnicas de ventana deslizante y ventana de congestin 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 Prctico 2

Source Port:

16 bits

El nmero 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 conexin, 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 tamao mnimo del encabezado es de 20 bytes (sin el campo opcional) y de un mximo
de 60 bytes en caso de contener campos opcionales(limitado por el mximo 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
clsico usan parte de los bits de este campo. A saber:

NS (1 bit): vase RFC 3540.

CWR (1 bit): Ventada de congestin reducida. vase RFC 3168

ECE (1 bit): Notificacin explicita de congestin. vase RFC 3168.

Control Bits:

6 bits (de izquierda a derecha):

Cuando los bits estn 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 funcin de push (pasar el flujo de bytes bufereado a la capa de
aplicacin).

RST: Reiniciar la conexin.

SYN: Sincronizar nmeros 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 verificacin de suma.

P g i n a 4 | 13

Redes y sistemas operativos I | Trabajo Prctico 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 cmo es el handshake TCP.

La figura muestra una linea de tiempo de lo que pasa durante el establecimiento de una conexin
TCP mediante el saludo de tres vas (Handshake TCP), generalmente toman lugar los siguientes
eventos:
1. El cliente enva 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 nmero 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 cuestin 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 conexin y es lo que se conoce como el saludo de tres vas TCP. Posteriomente cliente y
servidor pueden intercambiar datos. [TCP/IP Illustrated vol. 1 2a Ed. pg. 596].

P g i n a 5 | 13

Redes y sistemas operativos I | Trabajo Prctico 2

Describir cmo termina una comunicacin TCP.

La figura muestra como una conexin tcp es terminada en (tambien llamado cierre de conexin) en
este caso por el cliente. Cualquier host o terminal puden iniciar una operacin de cierre.
Tradicionalmente es ms comun que el cliente sea quien inicia el cierre de una conexin sin
embargo hay servidores que suelen iniciar el cirre de la conexin cuando completan una solicitud, a
su vez es posible que se de el caso de un cierre simultaneo de conexin. [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 nmero de secuencia). En este momento la aplicacin que hace uso de la conexin 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 conexin en el sentido
clienteservidor.
4. El servidor recibe el ACK y da por terminada la conexin en el sentido servidorcliente.
Si el FIN del servidor se pierde, el mismo se retransmite hasta recibir un ACK.
Y as es cmo finalmente termina una conexin TCP de forma normal.

P g i n a 6 | 13

Redes y sistemas operativos I | Trabajo Prctico 2

Qu es el control de congestin? Para qu sirve?
Cmo se utiliza en TCP?
El control de congestin 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 congestin 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 (trfico til en la red,
througput de informacin relevante a los usuarios de la red).
Dicho esto, el control de congestin tiene como objetivo que la congestin 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 congestin en TCP se especifican en el RFC 5681. A saber:

slow start

congestion avoidance

fast retransmit

fast recovery

Estos algoritmos trabajan ajustando el lmite 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 congestin y Ventana de receptor, la cantidad
mxima de datos a enviar esta determinado por el mnimo entre los valores de estos dos campos.
Qu es el control de flujos TCP?
El control de flujos en TCP es la comunacin 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 ms posible el througput. Esto se logra mediante el ajuste
dinmico y el intercambio de informacin relativa al tamao de la ventana deslizante de cada host.
Describir AIMD.
AIMD es una ley de control de asignacin de ancho de banda a distintos usuarios de una red que
teoricamente garantiza o converge hacia una asignacin 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 ings 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 reduccin del ancho de banda de distintos hosts en una red.

P g i n a 7 | 13

Redes y sistemas operativos I | Trabajo Prctico 2

La figura muestra como la asignacin 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 distribucin converge hacia la interseccion
entre la asignacin equitativa y eficiente.
Si no se ha alcanzado la mxima utilizacin 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 congestin, para subsanar este problema y a la vez buscar equidad en la asignacin 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 congestn. 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 reduccin de la asignacin se vuelve a incrementar linealmente el ancho de banda de
ambos y el ciclo se repite.
Este patrn ciclico dictado por esta ley produce un grfico de ancho de banda en funcin 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 mximo disponible en la red para ese host.

P g i n a 8 | 13

Redes y sistemas operativos I | Trabajo Prctico 2

Cules son las causas de congestin? Cmo se
manifiestan?

Sea esta figura donde:

Ancho de banda de enlace AR1 = 1mbps
Ancho de banda de enlace BR1 = 1mbps
Ancho de banda de enlace R1R2 = 2 mbps
Ancho de banda de enlace R2C = 0,5 mbps
Velocidad de procesamiento de R1 = 1mbps
Velocidad de procesamiento de R2 = 1mbps

Las causas de congestin 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
congestin

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 informacin a una
tasa mayor o igual a la que ingresa produciendo overflow, perdida de paquetes y
congestin.

La congestin como efecto no deseable en las redes se manifiesta a travs 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 Prctico 2

Qu es la ventana de congestin? Cmo se calcula?
En las primeras versiones de TCP usadas en ARPANET se utilizaba un tamao de ventana
deslizante fijo para el control de flujo. A medida que esta red creca en tamao empez a
observarse un curioso fenomeno:
Los enlaces se mantenian ocupados enviando informacin a travs de la red pero la tasa de
tranferencia se reduca notablemente. As se dislumbr por primera vez lo que conocemos como
congestin.Dicho fenomeno amenazaba seriamente al futuro de la red completa ya que a medida
que el trfico aumenta por la adicin de nodos tambin lo hace la carga, aumentando la frecuencia
con la que la congestin y el eventual colapso de la red ocurran.
No es sino hasta fines de los aos 80 que, de la mano de Van Jacobson, se introducen los
principios de control de congestin y soluciones prcticas cuyas especificaciones se dan las
versiones Tahoe y Reno de TCP, en 1988 y 1990 respectivamente.
La ventana de congestin (cwnd) es una solucin 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 congestin. 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 mnimo 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 congestin (esto es el valor que toma luego de establecer la
conexin mediante un three-way handshake) debe tener como lmite superior el siguiente:
Si SMSS > 2190 bytes:
IW = 2 * SMSS bytes y no puede ser ms de 2 segmentos
Si (SMSS > 1095 bytes) y (SMSS <= 2190 bytes):
IW = 3 * SMSS bytes y no puede ser ms de 3 segmentos
Si SMSS <= 1095 bytes:
IW = 4 * SMSS bytes y no puede ser ms de 4 segmentos
SMSS: Sender maximum segment size (tamao 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 tamao de la ventana
de congestin o cuando se produce un reinicio de la conexin.
Este algoritmo incrementa exponecialmente el tamao 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 tamao de cwnd por RTT usando un
algoritmo de congestion avoidance (evitacin de congestin) (basado en AIMD, sin embargo cabe
destacar que no realiza un decremento multiplicativo sino que siempre vuelve al tamao de la
ventana inicial).
Describir las diferencias existentes entre Fast Retransmit y Fast Recovery.
Fast Retransmit es un algoritmo heurstico 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 Prctico 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 heurstico 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 tamao de la ventana dezlizante en
cwnd/2 artificialmente e inyecta tantos segmentos nuevos a la red como la nueva ventana de
congestin 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 transimisin sin tiempos muertos.
Describir las diferencias entre TCP Tahoe, TCP Reno y TCP Vegas.

TCP Tahoe: Se refiere al algoritmo de control de congestin propuesto por Van Jacobson,
Utiliza Slow Start para iniciar la transmisin y el decrementa el tamao de ventana de
congestion al valor de tamao 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 congestin y entonces Tahoe asigna como nuevo ssthresh a cwnd/2, decrementa
el tamao de cwnd al tamao inicial, lo aumenta exponecialmente usando slow start y
luego crece linealmente hasta volver a detectar congestin.
Tahoe no enva 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 envo 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
congestin) para reenviar segmentos sino que usa una tcnica 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
tamao 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 seal de
congestin incipiente y no incrementa el tamao cgwnd.
Con respecto a Slow Start, Vegas incorpora su mecanismo de deteccion de congestion a
slow-start con pequeas modificaciones. Para detectar y evitar congestin durante slow
start Vegas solo permite el crecimiento exponencial de cwnd 1 vez por cada RTT. Entre
medio la ventana de congestin se mantiene fija as una comparacin vlida de las tasas
de envo 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 lmite) 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 Prctico 2

Qu es RSVP (RFC 2205)?

RSVP es un protocolo de reservacin de recursos diseado 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 requerirn 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 lgicamente de forma distinta ms a alla de que una misma
aplicacin 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 Prctico 2

Bibliografa

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

Redes de computadoras, 5ta edicin / 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