TCP es un protocolo de redes de la capa de transporte, el cual ofrece un servicio estable de flujo de datos, orientado a connexiones [19]. Es un protocolo duplex-completo, lo que significa que cada connexión de TCP le presta apoyo a un par de corrientes de datos (byte streams), moviendose en direcciones opuestas. El TCP acepta control de corrientes de datos ( flow control) , lo que le impide al mensajero exceder la capacidad de la memoria intermedia (Buffer) del destinatario. Aún más, el TCP ejecuta control de congestiones ( congestion control), lo que previene que el mensajero injecte demasiado trafico en la red. El TCP es un protocolo de punta-a-punta ( end-to-end). Esto es, el TCP convierte el servicio de entrega de anfitrión-a-anfitrión, proveido por el IP, a un canal de comunicaciones de proceso-a-proceso [19]. Para instrucción mas en detalle del TCP, vaya a [19] y [22].
Desde 1981, cuando el TCP primero fue introducido [20 ], la Internet ha experimentado cambios dramáticos. Desde los inicios cuando un valor de banda de 1440 bitios por segundo (bps) se consideraba de pasmo, a la liberación de los 1990s; desde aplicaciones para redes basadas en carácteres, como correo electrónico y telnet, al mundo rico en estímulos visuales de la Web Mundial. Y ahora, la nueva frontera, aparatos inalámbricos de mano(portables).
El TCP ha evolucionado para satisfacer las demandas de las nuevas technologias, durante estas transiciones. Los ingenieros quienes trabajaron en mejorar el TCP, lograron diseñar un protocolo robusto, tolerante, eficiente, y escalable. Por esta razón, el TCP se mantiene como la capa de transporte predominante en la Internet. Tecnologias consideradas competitivas a principios de los '80, como el Programa de Copia Unix-a-Unix (UUCP), y sistemas de redes como BITNET [6], ya son obsoletas. En la decada de los 1990s, un Modo de Transferencia Asíncrono (ATM) fue introducida como la última en soluciones para unificar redes. Con la ATM se conseguia Calidad de Servicio (QoS), y otras habilidades en extremo deseables, que no se consiguen con la pila de protocolo de TCP/IP. En consecuencia, la prensa la proclamó "el final del TCP." Muchos ingenieros se dejaron influenciar por estos rumores, y se apuraron a crear una variedad de tecnologias relacionadas a la ATM, tales como Sistemas de Redes ATM de Area Amplia, y applicaciones como "de la ATM al Escritorio", y "ATM nativa". Sin embargo, por un número de razones, la ATM no consiguió desempeñar un rol principal en la historia de la Internet. Hoy en día, es vista como otra infraestructura de sistemas, encima de la cual corre la pila de TCP/IP [19 ].
Aunque el TCP ha sobrevivido la ATM, ahora enfrenta nuevos desafios con el surgimiento de la informática inalambrica y portable. Podra el TCP permanecer como la capa de transporte preferida para un mundo alámbrico-inalámbrico (esto es, una Internet que incluye anfitriones que usan tanto connexiones de cables como inalámbricas)?
El Protocolo de Internet, el cual es el protocolo de inter-red en que el TCP confía, experimentó cambios importantes, en años recientes. Su nuevo diseño, IPv6, resuelve el problema de acomodar el número creciente de anfitriones que conectan a la Internet. Este nuevo estandar deja que aproximadamente 3x1038 aparatos sean IP-permitidos. Mas información acerca de IPv6 es provista en el sitio de web oficial de IPv6 a http://www.ipv6.org/.
IP Movible ha sido desarrollado para proveer "apoyo de encaminamiento...[a] nodulos de IP (anfitriones y encaminadores) usando ya sea IPv4 o IPv6 para 'rondar' sin problemas subredes de IP y medios" [11]. Esta infraestructura de IP es esencial para proveer a todos los anfitriones portables conectados, la misma facilidad de función que los dispositvos de mesa han gozado. Es natural que el TCP sea preferido para ser la capa de transporte para trabajar con el IP Movible. Sin embargo, el TCP no ha experimentado reajustes que le permintan enfrentar las demandas de la informática movible.
A mediados de los '90s, un grupo de trabajo llamado TCP Siguiente Generacion (TCPng) fue formado. Desafortunadamente, este grupo nunca publicó ningún RFCs o standars. Sin embargo, han habido esfuerzos considerables para mejorar el TCP, los cuales son el tema de este artículo. Para una lista considerable, pero no total, de cambios propuestos, vaya a http://www.aciri.org/floyd/tcp_small.html. Además de esto, [15] presenta un resumen de mejoras propuestas al TCP.
La heterogenidad es un atributo que más caracteriza la evolución de las comunicaciones modernas. El TCP puede ser utilizado en una variedad de redes, incluyendo Ethernet, FDDI, y la ATM. Puede ser ejecutado sobre una variedad de medios físicos, incluyendo alambres, fibras ópticas, ondas de radio, o señales infra-rojas. Una connexión de TCP puede, y generalmente ejecuta, funciones en todos estos medios y redes.
Sin embargo, el TCP no fue diseñado con esta heterogenidad en mente. La tabla No 1 presenta la Rata de Error por Bítulo (BER) como función de un medio. La BER (o la probabilidad que un bítulo cualquiera se corrompa) es pequeña sobre los medios alámbricos. En consequencia, no se usa Corrección de Errores en Encaminamiento (FEC) [12, 19] . FEC significa que un esquema código para transmiciones que corrige errores es usado en vez de uno para detectar errores. Esto es, información redundante es incluida en cada paquete que va a ser utilizado por el receptor, para determinar y corregir bítulos corruptos. FEC es comunmente utilizado en transmisiones inalámbricas por el alto numero de BERs.
| Medios Alámbricos | |
|---|---|
| Cable de Cobre | 10-6 to 10-7 |
| Fibra Optica | 10-12 to 10-14 |
| Medios Inalámbricos | |
| Corrección sin error de transmisión de radio | up to 10-1 |
| Corrección con error de transmisión de radio | 10-6 |
El TCP ha sido usado principalmente para redes alámbricas, asi que ha sido afinado con ciertas suposiciones en mente. Por ejemplo, cuando un segmento de data se pierde, en una red alámbrica, es relativamente seguro suponer que se debe a congestión de la red (esto es, muchos segmentos están tratando de utilizar la red) [2, 19 ]. Pero, si se trata de un vínculo inalámbrico o subred, la causa pudiera ser mala recepción en donde se encuentra el usuario.
No es raro, y se vera aún mas en el futuro, que una connexión de TCP viajará a traves de redes con latencia alta/banda baja(esto es, WAN inalámbrico), y a traves de redes de latencia baja/banda ancha(alámbrica), y después a traves de redes banda completa/latencia alta(esto es, redes gordas y largas [15]). Esto complica mas las cosas, porque el desempeño del TCP no depende en la rata de transferencia de por sí, pero mas bien en el producto de la rata de transmisión y la demora en el viaje de ida-y-vuelta [10].
Por otra parte, el TCP sobrevivió los días de banda corta, latencia alta, y ratas de error altas. Asi que uno se podria preguntar porque las versiones existentes del TCP no pueden con el nuevo medio. Por ejemplo, el TCP podria tambien ser utilizado en el nuevo medio, donde los BER's altos rigen, las bandas son limitadas, y latencias son obviamente majores, debido a la propagación de diferentes medios. Por ejemplo, en redes inalámbricas, la banda puede ser tan baja como 19.2kbps [21]. El TCP funcionó bien antes en medios con condiciones similares(esto es, connexiones de marcado directo), entonces, cual es el problema?
Las versiones de TCP corrientes interpretan un segmento ausente como congestion en la red, lo que significa que el remitente debe reducir la velocidad de su transmisión, porque la red esta a capacidad. Esta interpretación es a menudo correcta para las redes inalámbricas. Desafortunadamente, si tambien encontramos vínculos inalambricos en una ruta de comunicación, esta interpretacion podria ser erronea. En estos casos, la interpretacion del TCP es incorrecta, y lleva a un mal desempeño [4, 5, 7, 23]. Como nos gustaría que el TCP funcionara bien en medios alámbricos-inalámbricos, es necessario que descubramos una estrategia para decidir, de manera inteligente, lo que puede estar pasando, esto es, que el TCP pueda adivinar correctamente, cada vez. En otras palabras, el TCP debe funcionar bien con toda las infraestructuras, ya sean homogéneas o heterogéneas.
Otra meta importante is el uso eficiente de energia. Las implementaciones corrientes del TCP no se tienen que preocupar de si el protocolo hase uso eficiente de energia; todos los anfitriones tienen acceso ilimitado a energia, en el mundo del TCP. Este no es el caso para las computadora portables y de mano, asistentes digitales (PDAs), y telefonos inalámbricos que se conforman al protocolo, los cuales dependen en el poder limitado de una bateria. Un número de parametros, como el tiempo de conexion total y el maximo número de bítulos, TCP inducido, el potencial de union con la capa vinculo de datos (LL), y otros, tendran que ser estudiados. Por ejemplo, algunos protocolos de la capa de vínculos de datos implementan un esquema onfiable de transmisiones (esto es, ARQ [19]). Al mismo tiempo, el TCP tambien provee una transmision de punta-a-punta confiable. Este traslapo, el cual trata de asegurar que la transmision es confiable, ha demostrado que conduce a un desempeño de menos calidad [7]. La idea principal es evitar hacer las cosas dos veces, en la capa de vínculos de datos, y despues en la capa de transporte.
| Applicacion | Anfitriones desean acceso a servicions como WWW, correo electronico, FTP, mensajes, etc. |
|---|---|
| Transporte | TCP variantes, I-TCP, UDP, protocolos experimentales |
| Red | Todos anfritiones deben apoyar IP. (IPv6 y IP Movible si necesario) |
| Vinculo de Datos | TCP noalerta (TULIP), TCP-alerta (Snoop) |
| Fisica | FEC |
La tabla No. 2 nos presenta los diferentes angulos que los investigadores han perseguido para poder resolver los problemas mencionados anteriormente. Algunos sugieren que la capa de vínculos de datos (LL) debiera ser encargada de proveer una red de ambiente homogéneo. Otros, favorecen una solución al nivel de la capa de transporte. En los parrafos siquientes, presentamos un resumen de los diferentes angulos junto con sus ventajas y desventajas.
Propuestas en esta categoría poseen bastante mérito. La Capa de Vínculos de Datos (LL) tiene mas control sobre la Capa Física que ninguna otra capa. Como el problema resta en la Capa Física (ratas de error altas para vínculos en ambientes inalámbricos), un protocolo de LL puede percibir problemas mas rápido. Entonces, debieramos resolver el problema al LL y proveer un buen canal de comunicación - similar a uno alámbrico - a las capas de encima, en particular el TCP. Esto no permite dejar las versiones corrientes de TCP como están. La manera de hacer esto es asegurarse de una entrega confiable de paquetes todo el tiempo, por ejemplo usando un esquema Repetidor de Peticion Automatico (ARQ). Sin embargo, estudios han demostrado que esto puede conducir a desempeño de baja calidad [7]. Esto es debido a que el TCP tambien trata de asegurarse de una transmision confiable, y por ende crea esfuerzos duplicados. Los autores en [5 ] sugieren que si dicha solucion fuera aceptada, tendría que ser bien coordinada con el TCP. No obstante, los diseñadores de TULIPAN (TULIP, Protocolo de Mejoras al Vínculo No-Alerta de Transporte) demuestran que para canales de mas de la mitad duplex, una solucion "no coordinada" es posible, y puede conducir a un mejor desempeño [17].
La propuesta mas importante en esta categoria es el protocolo snoop [5 ]. Esta propuesta descanza entre las propuestas de LL y las propuestas de connexiones de TCP split. Utiliza la abilidad de un protocolo de LL para responder rápidamente y para usar informacion existente para mantener al TCP "contento" con la conexion de red existente. Por ejemplo, el snoop favorecerá retransmisiones locales de LL en vez de las de TCP. Esto se puede lograr porque un agente de snoop notará recibos en duplicado (dupacks) viajando desde el destinatario al remitente y los suprimirá, localmente, re-transmitiendo el (posiblemente)segmento perdido, en vez. Sin snoop, el recibo de un cierto numero de dupacks hubiera causado una retransmision de segmento TCP [2].
Propuestas de TCP Split, tales como TCP Indirecto(I-TCP) [3], fueron primero propuestas a mediados de los 90s. La idea detras del I-TCP se basa en el hecho que una conexion de TCP puede ser establecida sobre dos clases completamente distantas de subredes como, alámbricas e inalámbricas. Entonces, cada conexion de TCP puede ser partida (split) en dos conexiones al punto en donde las dos subredes se unen. Por ejemplo, supongamos que tenemos un usuario movible el cual ronda un sitio de web (convensional) usando su laptop (computadora compacta portable). La conexion de TCP sera partida (repartida)en dos: una entre el anfitrion movible y la base and otra entre la estación de base y el servidor de web. La ventaja es que podemos utilizar el protocolo de transporte para cada tipo de red. Esto es muy similar a usar un servidor proxy (próximo) de HTTP. Partír la conexion de TCP es básicamente la técnica usada por la architectura Protocolo de Aplicaciones Inalámbricas (WAP). El sitio de web oficial para el Foro de WAP, http://www.wapforum.com/ , provee mas información sobre el stack de protocolos WAP.
Al partir las conexiones de TCP perdemos semanticas de TCP de punta-a-punta. En consequencia, no tenemos un canal de comunicacion de proceso-a-proceso. Nodos intermedios actuan como proxys, inspeccionando y modificando cada segmento. Adicionalmente, el desempeño puede decaer partiendo una conexion particular varias veces. Las entregas tampoco se llevan a cabo tan eficientemente, y crisis (crash) en la estación de base resultan en el final de la conexión de TCP [15].
La naturaleza sutil, altamente modular, y altamente independiente de la capa de transporte le hace un lugar ideal para remediar los problemas introducidos por la movilidad. Por otra parte, la mayoría de los internets actuales proporcionan un servicio de mejor-esfuerzo: la infraestructura subyacente de la red puede dejar, reordenar, y duplicar segmentos, introducir variaciones en el retardo (inquietud), y limitar mensajes a una cierta talla finita. Al mismo tiempo, protocolos de la Capa de Aplicaciones necesitan la salida garantizada de mensajes en-orden, contar con la ayuda para los mensajes arbitrariamente grandes, y requiere la disponibilidad de los servicios de red para los procesos múltiples. Por lo tanto, el " argumento punta-a-punta " [ 19 ] favorece el uso de un protocolo eficiente de transporte. El TCP es probablemente el mejor candidato. El TCP hace mantener compatibilidad con el resto de la Internet más fácil; gran cantidad de investigación se ha invertido; y los años de la experiencia con el TCP podrían ser provechosos. Además, con IPv6 listo para este valiente mundo nuevo, el TCP es su protocolo natural de transporte. Después de todo, el Internet ha sido tan acertado debido a la robustez que el TCP ha mostrado.
Según lo observado anteriormente, el TCP interpreta un segmento ausente como congestión, y por lo tanto retrasa su tarifa de la transmisión. Las propuestas de modificación del TCP procuran hacer el TCP más agresivo, sosteniendo la tarifa de la transmisión por un cierto período de tiempo. Dependiendo de la naturaleza, distribución, y de la persistencia de las entregas, las tres versiones más comunes del TCP, es decir Tahoe, Reno [2] y Nuevo Reno [9 ], parecen superarse entre si [8, 23]. No se ha mostrado que ninguna de las versiones comunes de estos tres TCP son superior a través de todas las configuraciones de prueba. Además, el TCP Reno con el snoop ha demostrado superar el TCP estándar Reno. Valdrá la pena buscar mejores versiones del TCP?
Las numerosas propuestas de modificación al TCP implican que hay mérito en la búsqueda para una versión de la generación siguiente del TCP. Cada tentativa trata de hacer lo siguiente:
Agregar intelligencia a los algoritmos de control de la congestión del TCP como el de recibo selecto (SACK TCP) [13 ], recibo encaminadoTCP (FACK TCP) [14], and sondeo de TCP [24]. En el último, la intención es tratar de determinar si el segmento ausente es debido a condiciones de error relativamente persistentes (esto es, congestión, errores de impulsos inalámbricos prolongados) o los puramente transitorios (e.g. los errores al azar inalámbricos). En el caso anterior, el remitente debe retroceder y retrasar su tarifa de la transmisión; en el último él debe continuar en la misma tarifa
Aíslar el camino delantero (donde los datos flujen) del camino reverso (donde fluyen ACKs), de tal manera, proporcionando mejor funcionamiento en distintos escenarios, incluyendo conexiones asimétricas. Un tal ejemplo es TCP Santa Cruz [18], el cual también propone el desemparejamiento del margen de crecimiento de la congestión del número de ACKs devueltos.Es absolutamente claro que el TCP introduce muchos de los gastos indirectos, lo que siempre es no deseable, en principio, pero a veces altamente necesario en la práctica. Un número de investigadores han propuesto protocolos de capa de transporte experimentales, altamente afinados, mejor preparados que el TCP para las redes alámbricas-inalámbricas. Por ejemplo, el Protocolo de Control de Transmisiones inalámbrico (WTCP [21] fue diseñado para redes de area amplia con input limitado y output variable, y latencias altas y variables. Nuevos, cuidadosamente afinados, protocolos de transporte pueden tambien ser combinados con las propuestas de TCP Split para mejor desempeño. Mas aún, nuevos protocolos de la Capa de Transporte pueden ser diseñados con eficiencia en mente, y en consecuencia son mejores soluciones para los dispositivos movibles. El Foro de WAP ha perseguido este angulo en la versión corriente de los estandards que han presentado. Teléfonos y servicios basados en WAP ya son realidad en muchos paises alrededor del mundo. Pero ya hay rumores que la siguiente generacion de standards va a incorporar el TCP. Asi que, para que molestarse?
Primero que todo, quisiéramos que todos los anfitriones principales conectados, sin importar talla, movilidad, y potencia de cómputo, sean iguales. Quisiéramos que los dispositivos móviles obraran recíprocamente con los ordenadores principales existentes y utilizaran servicios comunes como el Web y el E-mail directamente. En términos de la confiabilidad, usar un protocolo experimental en una escala ancha no puede ser tan robusto como usar el TCP. Todos los nuevos protocolos deben mostrar su robustez y capacidad de escalar.
Si un nuevo protocolo de capa de transporte tuviera que ser utilizado en los nodos móviles, entonces para permitirles que operen recíprocamente con el resto del Internet una cierta clase de servicio de poder se requiere. Sin embargo, las características especifícas-a-dispositivos, como una pantalla mas pequeña, memoria limitada, y restringiones de input, dictan que los servicios convencionales deben primero " ser ajustados " antes de que se proporcionen, por ejemplo, un usuario de PDA. Un servicio de aproximacion (proxy) puede realizar este "ajuste " en la capa de aplicación, y además, podría utilizar otro protocolo de capa de transporte para entregar el contenido modificado al usuario del extremo. Por otra parte, el uso de una aproximación limita el número de los servicios Internet gozados por el usuario móvible a los que son utilizadas por la aproximacion, e introduce un punto de error en la red.
Todavia no se a determinado si es mejor resolved los problemas anteriormente mencionados al nivel de la Capa de Transporte, o en las capas debajo de esta, en vez. Si se prefiere el segundo ángulo, es mejor modificar el TCP o a lo mejor debieramos introducir protocolos de transporte completament nuevos? Adicionalmente, no es claro cual de las propuestas anteriormente mencionadas serán incluidas en la siguientes especificaciones del estandard del TCP. Sin embargo, como este es un estudio muy activo en el área de redes, es razonable suponer que habáa algun tipo de resolución pronto. En conclusión, dado que el IP ya a evolucionado, y que la majoría de las propuestas corrientes asumen un servicio de datagramas de IP, el TCP parece tener una ventaja sobre las otras soluciones.
Last Modified:
Location:
www.acm.org/crossroads/xrds7-2/tcp21.html