ACK Ahora debemos lidiar con el problema principal de evitar que el emisor sature al receptor enviando tramas a una mayor velocidad de la que este último puede procesarlas. Esta situación puede ocurrir con facilidad en la práctica, por lo que es de extrema importancia evitarla. Sin embargo, aún existe el supuesto de que el canal está libre de errores y el tráfico de datos sigue siendo simplex. Una solución es construir un receptor lo suficientemente poderoso como para procesar un flujo continuo de tramas, una tras otra sin interrupción (lo equivalente sería definir la capa de enlace de modo que fuera lo bastante lenta como para que el receptor pudiera mantenerse a la par). Debe tener suficiente capacidad en el búfer y de procesamiento como para operar a la tasa de transmisión de la línea; asimismo debe ser capaz de pasar las tramas que se reciben en la capa de red con la rapidez suficiente. Sin embargo, ésta es una solución para el peor de los casos. Requiere hardware dedicado y se pueden desperdiciar recursos si el enlace se usa poco. Además, sólo cambia el problema de tratar con un emisor demasiado rápido a otra parte; en este caso, a la capa de red. Una solución más general para este dilema es hacer que el receptor proporcione retroalimentación al emisor. Tras haber pasado un paquete a su capa de red, el receptor regresa al emisor una pequeña trama ficticia que, de hecho, autoriza al emisor para que transmita la siguiente trama. Después de enviar una trama, el protocolo exige que el emisor espere hasta que llegue la pequeña trama ficticia (es decir, la confirmación de recepción). Este retraso es un ejemplo simple de un protocolo de control de flujo. Los protocolos en los que el emisor envía una trama y luego espera una confirmación de recepción antes de continuar se denominan de parada y espera. El canal de comunicación entre las dos capas de enlace de datos necesita tener capacidad de transferencia de información bidireccional. Sin embargo, este protocolo implica una alternancia estricta de flujo: primero el emisor envía una trama, después el receptor envía una trama, después el emisor envía otra trama, luego el receptor envía otra, y así sucesivamente. Aquí sería suficiente un canal físico semidúplex. Al igual que en el protocolo 1, el emisor comienza obteniendo un paquete de la capa de red, lo usa para construir una trama y enviarla a su destino. Sólo que ahora, a diferencia del protocolo 1, el emisor debe esperar hasta que llegue una trama de confirmación de recepción antes de reiniciar el ciclo y obtener el siguiente paquete de la capa de red. La capa de enlace de datos emisora ni siquiera necesita inspeccionar la trama entrante, ya que sólo hay una posibilidad. La trama entrante siempre es de confirmación de recepción. El protocolo 1 (utopía) provee la transmisión de datos en una sola dirección, del emisor al receptor. Se supone que el canal de comunicación está libre de errores, y que el receptor es capaz de procesar todas las entradas a una rapidez infinita. En consecuencia, el emisor se mantiene en un ciclo, enviando datos a la línea tan rápido como puede. El protocolo 2 (parada y espera) también provee un flujo unidireccional de datos del emisor al receptor. Se da por hecho nuevamente que el canal de comunicación está libre de errores, como en el protocolo 1. Sin embargo, esta vez el receptor tiene capacidad finita de búfer y capacidad finita de procesamiento, por lo que el protocolo debe evitar de manera explícita que el emisor sature al receptor con datos a una mayor velocidad de la que pueda manejar. NACK Ahora consideremos la situación normal de un canal de comunicación que comete errores. Las tramas pueden llegar dañadas o se pueden perder por completo. Sin embargo, suponemos que, si una trama se daña en tránsito, el hardware del receptor detectará esto cuando calcule la suma de verificación. Si la trama está dañada de tal manera que pese a ello la suma de verificación sea correcta (una ocurrencia muy poco probable), este protocolo (y todos los demás) puede fallar (es decir, tal vez entregue un paquete incorrecto a la capa de red). A primera vista puede parecer que funcionaría una variación del protocolo 2: agregar un temporizador. El emisor podría enviar una trama, pero el receptor sólo enviaría una trama de confirmación de recepción si los datos llegaran correctamente. Si llegara una trama dañada al receptor, se desecharía. Después de un tiempo el temporizador del emisor expiraría y éste enviaría la trama otra vez. Este proceso se repetiría hasta que la trama por fin llegara intacta. Pero el esquema anterior tiene un defecto fatal. Para ver lo que puede resultar mal, recuerde que el objetivo de la capa de enlace de datos es proporcionar una comunicación transparente y libre de errores entre los procesos de las capas de red. La capa de red de la máquina A pasa una serie de paquetes a su capa de enlace de datos, la cual debe asegurar que se entregue una serie de paquetes idénticos a la capa de red de la máquina B a través de su capa de enlace de datos. En particular, la capa de red en B no tiene manera de saber si el paquete se perdió o duplicó, por lo que la capa de enlace de datos debe garantizar que ninguna combinación de errores de transmisión, por improbables que sean, pudiera causar la entrega de un paquete duplicado a la capa de red. Sin duda, lo que se necesita es alguna manera de que el receptor sea capaz de distinguir entre una trama que está viendo por primera vez y una retransmisión. La forma evidente de lograr esto es hacer que el emisor ponga un número de secuencia en el encabezado de cada trama que envía. Como el protocolo debe ser correcto y es probable que el campo de número de secuencia en el encabezado sea pequeño como para poder usar el enlace en forma eficiente el encabezado podría proveer 1 bit, unos cuantos bits, 1 byte o varios bytes para un número de secuencia, dependiendo del protocolo. Si la trama m se pierde o se daña, el receptor no confirmará su recepción y el emisor seguirá tratando de enviarla. Una vez que la trama se reciba correctamente, el receptor regresará una confirmación de recepción al emisor. Es aquí donde surge el problema potencial. Dependiendo de si el emisor recibe correctamente la trama de confirmación de recepción o no. La única ambigüedad es entre una trama y su antecesor o sucesor inmediato, no entre el antecesor y el sucesor. Por lo tanto, basta con un número de secuencia de 1 bit (0 o 1). En cada instante, el receptor espera un número de secuencia en particular. Cuando llega una trama que contiene el número de secuencia correcto, se acepta y se pasa a la capa de red, para después confirmar su recepción. Luego, el número de secuencia esperado se incrementa módulo 2 (es decir, 0 se vuelve 1 y 1 se vuelve 0). Cualquier trama que llegue y que contenga el número de secuencia incorrecto se rechaza como duplicada. Sin embargo, la última confirmación de recepción válida se repite de modo que el emisor pueda descubrir en un momento dado que se recibió la trama. Los protocolos en los que el emisor espera una confirmación de recepción positiva antes de avanzar al siguiente elemento de datos se conocen comúnmente como ARQ (Solicitud Automática de Repetición)
