Fragmentar paquetes

[Aldrin Martoq]

On Mon, 2008-12-15 at 17:34 +0100, Miguel Oyarzo O. wrote:
> Aldrin Martoq escribió:
> > 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.
> 
> Una red con MTU de 200 o 500 no trabajará. Hay paquetes que son 
> indivisibles y no saldrán de la interfaz.
> En redes wifi se prefiere usar Fragmentation Threshold, opera en capa 2 
> y no en la cabecera IP, FT revisa estado de los paquetes indivisibles y 
> es mas eficiente que cambiar MTU. Pueden haber combinaciones de ambos, 
> pero sería demencia.

Una red con MTU de 200 si debe funcionar, recibes un ICMP de respuesta y
debes fragmentar a nivel IP; me parece que configurar MTU es mejor que
FT ya que es parte de la negociacion y no necesitas fragmentar o que
alguien fragmente "a escondidas".

> Tampoco me sirve pues yo necesito para una conexion en particular, no 
> para todos los nodos conectados al AP.

Sorry, no estoy dandote la solucion. Solo estoy discutiendo que no estoy
seguro que mejores la comunicacion de la red/conexion disminuyendo el
taman~o del paquete como Ricardo dijo, hice una prueba rapida para ver y
en mi caso obtuve mas errores (aparte de ser horriblemente lento).

Por eso te pedi que corras la prueba y nos cuentes como te va, el
escenario tuyo es muy distinto respecto donde corri la prueba y seria
muy interesante saber cuanto cambia y en que punto.



Para escribir rapido la prueba de un paquete con distinto taman~o lo
hice modificando MTU y min_adv_mss, pero eres libre de cambiar el
taman~o del paquete como puedas ;) [eso si, asegurate de poder sacar
estadisticas para saber si es mejor o peor!]



> >> 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.

> OUTPUT?, no creo,  TCPMSS  trabaja en la tabla mangle (OUTPUT no existe 
> alli). Tu quieres decir POSTROUTING?

Hace rato que mangle esta en los 5 targets, compruebalo con "iptables -t
mangle -nvL". Por orden prefiero OUTPUT (o FORWARD para un router)
versus POSTROUTING, pero en ambos funcionaria.

> Volviendo a lo mio yo necesito que un equipo intermedio (ruteador Linux 
> entre el AP ubicado a 10 kmt y mi PC) pueda reducir la venta TCP del 
> stream *downloaded* que viene desde el AP. Por eso pienso en un 
> PREROUTING (mangle desde luego), pero parece que no existe esa 
> implementacion ... o si?.

TCPMSS no corta un paquete, sino que interfiere en la negociacion del
MSS: tu PC le informa al servidor remoto cual es el taman~o deseado; por
eso tienes que modificar la salida de tu PC. A la entrada de tu PC no
tiene sentido pues el servidor remoto que envia los paquetes no se
entera del cambio.

Asi que puedes configurar TCPMSS a la salida de tu PC (no necesitas un
equipo intermedio) y nos cuentas como anda.

-- 
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/f6b17b56/attachment.bin