Estimado Pablo,
Gracias por la duda, creo que les puede ayudar a varios.
Primero voy a tratar de explicar con ideas intuitivas que repasan varios temas vistos, al final respondo sobre la situación que describis.
TPDU:
El enfoque con TPDU y número se secuencia por TPDU es un enfoque didáctico para el abordaje del problema.
Comenzar desde un caso más simple, para luego analizar las restricciones que introduce y resolverlas.
Modo Flujo vs Modo Mensaje:
En Telecomunicaciones es posible que la capa de transporte trabaje en modo flujo o modo mensaje.
En modo mensaje, la capa de transporte primero reconstruye el mensaje antes de entregarlo a la aplicación. Esto pasaba en redes ATM.
En modo flujo, la capa de transporte solo se preocupa de entrega a la capa de aplicación los bytes ordenados.
Unidades de Intercambio de tamaño fijo o tamaño variable:
Cuando el intercambio es de tamaño fijo, hay gran pérdida de eficiencia, por un byte envío varios de relleno.
Esto requiere, entre otras cosas, llevar adicionalmente información de si hay relleno. Esto pasaba en redes ATM, que decidió elegir unidades de intercambio de pequeño tamaño 53 bytes.
Libertad de envío TCP (Supuesto de diseño):
El supuesto de TCP es que tiene la libertad de elegir como transmitir la información, si los segmentos son de 1000 bytes o parte en segmentos de 500 bytes.
Si bien acuerda el mss al comienzo de la conexión TCP (elige el menor de ambas propuestas)
Secuenciar de a TPDU o de a bytes:
Es cierto que podrían haber decidido secuenciar de a segmento, pero a priori el receptor no sabe el tamaño que envía el transmisor.
Podrías confiar en que la verificación del checksum alcance para evitar errores. Lo usual es que en esos caso se envié en un campo especifico del header el largo como medida de verificación.
Está estrategia inhabilita otras alternativas como el Path MTU discovery, como la red puede tener cambios, la pérdida de un link hace que el camino sea diferente, si en ese camino la MTU es menor a lo negociado al comienzo. TCP ya no puede elegir repetir el envió con segmentos menores, debería cerrar la conexión.
Por otro lado, tanto el control de flujo como el control de congestión se basan en que controlando la ventana de transmisión, controlamos el ancho de banda,
si lo hiciera por TPDU o segmento, no es tan directo o no es "tan fino" el control que tenemos.
Resumen:
Cuando asumimos que el largo de TPDU es variable y libertad de envió/re-envío (no solo el primer envío, sino las retransmisiones), que trabaja en modo flujo, utilizar número de secuencia por bytes tiene sentido.
Consulta: Por ejemplo: supongamos que un segmento
tiene 10 bytes de carga útil y el número de secuencia del primero de
ellos (y por tanto el que aparece en el encabezado del segmento) es 25,
entonces los bytes del segmento tendrán los números de secuencia del 25
al 34. Hasta donde entendí el ACK corresponde al segmento, si todo se
transmitió OK volverá un ACK numerado en 35, siguiente número de
secuencia que se espera recibir. ¿Qué pasa por ejemplo si no se recibe
el byte 28, que forma parte de ese segmento? ¿cómo sabes que el número
de secuencia que no llegó es el 28 u otro del segmento?
Respuesta:
Si los 10 bytes están en el mismo segmento, debo reconocer todos los bytes. En tu ejemplo, ACK=35 (25+10).
No puede ocurrir un ACK=27.
Al tener TCP control de Flujo, nunca envía mas información de lo que el receptor pueda almacenar (hasta que lo lea la aplicación).
Esto garantiza que si envié 10 byte fue porque el receptor me informó que tiene ese espacio.
Con este enfoque, el ACK es =25 (por ejemplo un error de cheksum o no llegó) o =35 (recepción OK de los 10 bytes)
Espero no haberlos entreverado y haber respondido las inquietudes.
Saludos,
Alvaro