BandaAncha.eu

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 💬 foros ⏎
  • 🔍 en 👇 este 💬 foro ⏎
  • 🔍 en 👇 este 💬 tema ⏎
Regístrate Regístrate Identifícate Identifícate
ADSL/VDSL

Funcionamiento de los modos Fast Path e Interleaved Path

pacorrop

Saludos. Hace tiempo estuve buscando información técnica sobre el funcionamiento de los modos Fast e Interleaved Path, pero no pude enterarme muy bien.

Ahora que he crecido voy a intentar explicar el funcionamiento de estos modos, de forma que se entienda un poco mejor a todos los niveles (es mi propósito, otra cosa es que sea una realidad :P)

Si nos metemos en el módem-router para trastear un rato, normalmente (el que 'ofrece' ya.com, por ejemplo, lo tiene en ADSL Status) podremos observar un campo llamado modo de enlace. ¿Qué significa esto?

Cuando te conectas a Internet por el módem-router, lo haces por tu bucle de abonado (esto es una perogrullada, lo sé, pero es introductorio y necesario). Este cable llega a la central telefónica que te corresponda, y desde allí se te conecta con el mundo exterior.
Bien, hasta aquí nada nuevo. Pero, ¿por qué funciona? Y lo que es más, ¿cómo?
Cuando solicitas tener ADSL con cualquier ISP (entre varias otras cosas) lo que ocurre es que se te asigna, en tu central telefónica, otro módem ADSL.
Esto es, desde el extremo de tu casa, del par de cobre has conectado tu módem-router ADSL, y en el otro extremo está conectado el módem ADSL asignado a ti. Se dice entonces que hay un enlace punto a punto, porque tu módem-router se conecta única y exclusivamente al módem ADSL de la central. Este módem es único para cada usuario que la central tenga que dar acceso.
Bien, para este enlace punto a punto hay dos formas de comunicarse entre ambos módems: Interleaved Path y Fast Path.

Hay quien pueda pensar: "¡Joder, qué manera de dividir las cosas para complicar todo!". Hombre, sí y no. Sí porque, en efecto, cuanto más avanzamos, más queremos "configurar todo" conforme a las exigencias del mercado. No, porque los técnicos-ingenieros-etc necesitan innovar para ganarse el sueldo :P.

A lo nuestro: paso a comentar cómo se transmiten datos en el modo Fast Path:

Es, en cierto modo, una cola. El primer chorro de bytes que mi módem-router suelta hacia Internet es lo que le va llegando al módem de la central, con lo que simplemente el módem de la central hace de 'repetidor' hacia fuera (Internet). Pongámoslo con un ejemplito, que se entenderá mejor (espero):
Supongamos que transmitimos y recibimos tramas de 6 bytes. Entonces, si transmitimos 6 tramas por cualquier motivo, tendríamos estos datos a enviar por nuestro módem-router:

A1A2A3A4A5A6 B1B2B3B4B5B6 C1C2C3C4C5C6 D1D2D3D4D5D6 E1E2E3E4E5E6 F1F2F3F4F5F6

Con el modo Fast Path, lo que realmente saldría de nuestro módem-router es lo mismo que acabo de poner, esto es:

A1A2A3A4A5A6 B1B2B3B4B5B6 C1C2C3C4C5C6 D1D2D3D4D5D6 E1E2E3E4E5E6 F1F2F3F4F5F6

Pero, con el modo Interleaved Path, saldría algo parecido a esto:

A1B1C1D1E1F1 A2B2C2D2E2F2 A3B3C3D3E3F3 A4B4C4D4E4F4 A5B5C5D5E5F5 A6B6C6D6E6F6

Ahora bien, ¿qué tiene de ventaja el Interleaved Path?

Supón que tenemos un error de ráfaga (algo errr poco común, pero más frecuente que otros tipos de errores). Este error lo que me hace es cambiar algún bit durante un tiempo (por ejemplo, durante 50 microsegundos, lo que es aproximadamente el tiempo equivalente en enviar una trama de 6 bytes de este ejemplito por una línea de 1 megabit por segundo). Entonces, durante ese tiempo, todo lo que yo transmita (o reciba) será erróneo.

¿Cómo influye esto en nuestra transmisión?

Supón que tenemos el error de ráfaga de 50 microsegundos, y el cable nos produce ese error mientras enviamos, justamente, la cuarta trama de nuestro ejemplo. Así, yo transmitiría (en subrayado está la trama errónea):

Fast Path: A1A2A3A4A5A6 B1B2B3B4B5B6 C1C2C3C4C5C6 D1D2D3D4D5D6 E1E2E3E4E5E6 F1F2F3F4F5F6

Interleaved Path: A1B1C1D1E1F1 A2B2C2D2E2F2 A3B3C3D3E3F3 A4B4C4D4E4F4 A5B5C5D5E5F5 A6B6C6D6E6F6

Con lo que el módem de la central tendría estos datos, según el modo empleado:

Fast Path: A1A2A3A4A5A6 B1B2B3B4B5B6 C1C2C3C4C5C6 D1D2D3D4D5D6 E1E2E3E4E5E6 F1F2F3F4F5F6

Interleaved Path: A1A2A3A4A5A6 B1B2B3B4B5B6 C1C2C3C4C5C6 D1D2D3D4D5D6 E1E2E3E4E5E6 F1F2F3F4F5F6

¿Qué ha ocurrido? En Fast Path, el módem de la central deja pasar la información tal cual le llega, con lo que la trama D sería completamente errónea. En Interleaved Path, el módem reordena las tramas que le llegan de forma que las Ax estén todas juntas, las Bx igual, etc. Aquí ninguna trama llega completamente errónea, sino sólo un byte de los 6 que componen la trama. Esto tiene sus ventajas y sus inconvenientes.

La principal ventaja es que no hemos perdido ni una sola trama. Debido a la codificación del canal (este es otro tema que daría para largo), si de una trama de 6 bytes me llega uno mal, puedo corregir ese byte mal transmitido en el lado receptor. Ésta es una idea magnífica: aunque haya errores debido al cable de cobre de nuestra casa, en algunos casos no hará falta retransmitir los datos. Se aprovecha más eficientemente el canal, sin necesitar repetir el envío de datos.

Pero esto tiene su principal inconveniente: el tiempo de proceso de estas tramas es notoriamente largo en aplicaciones de tiempo real (como puede ser juegos online, videoconferencia, etc). Estas aplicaciones no requieren, además, que todos los datos que le lleguen lo hagan de manera óptima. Internet no es sólo la web, en la que sí importa que todos los datos lleguen perfectamente.

Ahora bien, por otro lado tenemos otro escenario: el de los protocolos de transporte de Internet, sobre los cuales se sustentan la gran mayoría de aplicaciones relacionadas con ella.

Los principales son dos: TCP y UDP.

TCP es el acrónimo de Transmission Control Protocol (hay quien en vez de Transmission lo llama Transport). Su funcionamiento (básico) es el siguiente: yo envío un paquete TCP y me quedo esperando a que el receptor me diga que ha entendido lo que le he enviado (es algo parecido a la recepción de confirmación, cuando enviamos un SMS a otra persona). Si pasa un tiempo sin recibir la respuesta, lo que yo hago es reenviarle la información hasta que la reciba y me envíe una confirmación.

UDP es el acrónimo de User Datagram Protocol. Con éste no hay posibilidad de saber si, una vez enviado, llegará al receptor (como cuando juega Gravesen, ¿llegará el balón a quien quiere Gravesen que llegue? ;)). Entonces, no hay mecanismo fiable de saber si cuando yo envío un mensaje, éste llegará a mi destinatario.
Aunque parezca pesimista la filosofía de UDP, hay que decir que estos paquetes se pierden bastantes pocas veces (cuando hay congestión en routers intermedios, por ejemplo).

He aquí mi reflexión final (puedo estar equivocado ojo):
La transmisión por Interleaved Path sólo tendría sentido para aplicaciones que usasen UDP, puesto que añadir una segunda capa de protección a las transmisiones TCP, no sería absurdo, pero yo creo que es innecesario. TCP es bastante robusto de por sí solo.
Ahora bien, paradójicamente, las aplicaciones que la mayoría de los usuarios de Internet hacen uso de UDP son, en su mayoría (exceptuando Emule cuando se hace uso del puerto UDP, y alguna otra) aplicaciones en tiempo real.
Una aplicación en tiempo real necesita que le llegue flujo constantemente. No le importa que no le llegue correctamente el 100% de la información.
Un ejemplo es la videoconferencia: en ella es necesario recibir un flujo constante de datos de audio y vídeo.
Lo principal es recibir información: si me llega un paquete de datos mal (o si, directamente, no me llega), todo lo peor que pueda pasar es oír un chasquido en la conversación o algún píxel 'chungo'.
Pero como dije antes, muy pocas veces ocurren fallos de este calibre.

Además, hay que tener en cuenta que el modo Interleaved Path consume más recursos: que haya que ordenar y desordenar las tramas implica que en algún lado de la central haya una CPU adicional encargada de procesar las tramas. CPU que podrían ahorrarse los ISP en caso de usar Fast Path.

Mi conclusión es que el modo Interleaved Path es una buena idea, pero NO tiene interés práctico en estos tiempos que corren. Tanto por el interés del usuario como por el lado del proveedor.
¿Por qué siguen usándolo? Pues... npi :P.

Hasta aquí queda mi intento de explicación. Espero que os haya interesado.
Cuando encontréis alguna errata(que las habrá xD), comunicádmelo y la subsano ipso-facto.

Saludos!

EDITADO: añadido el tema de TCP y UDP (gracias a ManiruIV!)

Este tema está cerrado a nuevas respuestas. Abre un nuevo tema para retomar la conversación.
ManiruIV

Muy bien explicado :-)

Ahora faltaria decir, que en aplicaciones donde es necesario obtener los datos de forma correcta, el protocolo TCP se encargaria de realizar de nuevo la peticion de los datos en caso de que estos hayan llegado de forma incorrecta. Por lo que el Interleaving de nuevo es inutil en estos casos (a menos que la linea sea de muy mala calidad, en cuyo caso ayudaria).

En otras aplicaciones como juegos online, se utiliza el protocolo UDP. Segun parece este protocolo no realiza la peticion de reenviar los datos en caso de que llegen mal (corregidme si no). Pero para solucionar esto, los juegos suelen enviar los paquetes por duplicado, con lo que si uno llega en malas condiciones, queda el siguiente.

Comprendo que no seria viable ponerlo en todas las lineas, pero si en aquellas que cumplan un minimo de calidad y el cliente este dispuesto a correr el "riesgo" que supone desactivar el Interleaving.

Para finalizar, opino que solo es necesario que una compañia con renombre de la posibilidad de ponerlo, para que las demas sigan el ejemplo.

rezze

Muy biec colega.Muy buena exposicion y sin ninguna falta ortografica xDD.
Ahora porque no envias esto por fax-email y carta certificada a todas las empresas de internet de este pais para que pongan el puñetero fastpath de una vez :-|

Ah el emule ha evolucionado bastante y trae un corrector de paquetes recibidios y suele revisar-recuperar paquetes perdidos o corruptos.