Fragmentar paquetes

[Aldrin Martoq]

On Mon, 2008-12-15 at 10:34 +0100, Miguel Oyarzo O. wrote: 
> Ricardo Utreras Estrella escribió:
> > Nope, mientras mas pequeño el paquete es menor la probabilidad de que 
> > tenga errores, es verdad que se aumenta el trafico debido a que como es 
> > mayor la cantidad de paquetes, se tienen que transportar mas 
> > encabezados, pero en caso de retransmision el tiempo sera menor. O sea, 
> > en conexiones con mucho ruido (perdida alta de paquetes) disminuir el 
> > mtu mejorara la comunicacion.
> Exactamente esa es la razon, se escapa un poco al objeto de la lista, 
> pero es un buen tema.
> Cuando administras redes grandes WIFI lo normal es que exitan muchas 
> retransmisiones en especial con paquetes grandes. Pero si el 
> administrador pudise acceder remotamente y recibir la info de cada 
> maquina con paquetes muy pequeños,   esa lectura o manipulacion de info 
> sera mas rapida pues pequeños paquetes tienen mas probabilidad de 
> atravezar la red.


> Respecto del aumento de paquetes, eso no tiene importancia, redes sobre 
> 2 GHz pueden haber muchisimos paquetes pequeños en el medio y el sistema 
> trabajará bien, el administrador de redes wireless piensa en los grandes 
> (de 1200  a 1440 bytes) y como evitar sus retransmisiones.

Esto es lo que pongo en duda, lo de menor probb de error es cierto para
un paquete en particular; PERO no necesariamente para el medio total,
digamos toda una transferencia o toda la red.

El problema de esta red es precisamente que el medio está compartido
(muy distinto a lo tipico en redes cableadas donde hay un switch aunque
sea picante). Luego si disminuyes el tamaño de paquetes aumentas la
cantidad de paquetes a transmitir, la cantidad de datos (RX/TX) a
transmitir y el tiempo necesario para completar la transferencia.
Entonces estas aumentando las posibilidades que ocurra un error _en toda
la red_, y por ende termines con mas retransmisiones.

Aca unas pruebas rapidas de mi tarro bajando un archivo de 80MiB con
wget:

MTU      rate tiempo          RX         TX   # errores
1500 1.78MiB/s   45 s   86482 KiB   1757 KiB   rx: 38 tx:  0
1500 1.98MiB/s   41 s   86481 KiB   1755 KiB   rx: 35 tx:  0
1500 1.90MiB/s   42 s   88268 KiB   1813 KiB   rx:  2 tx:  0
200  586KiB/s  141 s  105110 KiB  10314 KiB   rx: 61 tx:  0
200  487KiB/s  169 s  105221 KiB  10406 KiB   rx:160 tx:  0
200  520KiB/s  159 s  105143 KiB  10327 KiB   rx:141 tx:  0

Y viendo el resultado, el performance quedo horrible!

Tambien postulo que el efecto sera realmente peor si tienes mas clientes
con un MTU 200, ya que segun yo aumentaran las colisiones enormemente
contrario a lo que dices que la red trabaja bien con paquetes pequen~os.


Puedes ver el script y log en esta url, tal vez podrias repetir la
prueba en tu red que entiendo tiene mas errores que la mia y nos
muestres el resultado:

http://aldrin.martoq.cl/test/001/



> Algo como TCPMSS parece servirme, pero esta implementacion pareciera ser 
> POSTROUTING solamente, yo desearia algo PREROUTING, de forma que el host 
> remoto (sea quien sea) comience a bajar el tamaño de su ventana TCP y me 
> transmita paquetes chicos.

Los clientes/servidores no estan "ruteando", tienes que ponerlo en
OUTPUT. Tambien puedes modificar la aplicacion cliente y/o servidor (eso
de "negociacion") como mencione.

-- 
Aldrin Martoq <amartoq en dcc.uchile.cl>
http://aldrin.martoq.cl/videopodcast/
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 197 bytes
Descripción: This is a digitally signed message part
Url        : http://listas.inf.utfsm.cl/pipermail/linux/attachments/20081215/10c05cc8/attachment.bin