El Viernes, 22 de Junio de 2007 05:41, Alejandro Vargas escribió: > El 22/06/07, Herr Groucho <[EMAIL PROTECTED]> escribió: > > Reglas para el tráfico que no se enruta a través de esta máquina, > > sino que es recibido o transmitido por esta máquina: > > Yo pondría algo directamente una pantalla especial para la máquina > local (puerto origen, puerto destino, orden de prioridad, ancho de > banda minimo y maximo) > > > 0) El tráfico originado en una máquina accesible a través de > > <eth0> y terminado en esta máquina, así como el tráfico originado > > en esta máquina y terminado en una máquina accesible a través de > > <eth0> no está sujeto a restricciones ni priorización. (Vista > > desde la red interna, esta máquina está tan libre de > > restricciones como entre sí lo están las demás máquinas de la red > > interna). > > Me suena complicado. Podría ser separarlo por placas. Algo así > como: restricciones de ancho de banda para la placa eth0: y ahí por > un lado el tráfico locales y por otro el tráfico ruteado. Así para > cada placa de red.
No estoy diseñando tu programa de configuración de traffic shaping: estoy explicando cuáles son las reglas que quiero para mí. > > - Es prioritario el tráfico de paquetes menores a 100 bytes > > (No queremos molestar a TCP cagándole sus ACKs, etc.) > > Es una buena idea mientras no le de a los que hacen programas P2P > por mandar todos paquetes chiquititos para engañar a eso también. Que lo hagan, no me interesa. Sería ridículamente ineficiente y nadie usaría ese sistema p2p tan lento... > > - Es prioritario el tráfico ICMP > > (No queremos cagarle nada al protocolo de control de Internet) > > - Es prioritario el tráfico UDP > > (El DNS tiene que andar bien) > > Para no preguntar demasiadas cosas lo bueno sería que se activara > todo esto junto con una sola opcion y que estubiera por defecto, > tal vez habiendo un botón de "avanzado" que permita cambiar > individualmente los valores. En realidad, yo creo que esto es > deseable siempre así que casi nadie lo tocaría. No se a quien pueda > interesarle no priorizar el DNS, por ejemplo. Pero hay que saber qué hace el botón mágico ese. > > - Es prioritario el tráfico TCP perteneciente o relacionado a > > conexiones originadas en esta máquina y dirigidas a los puertos > > <ssh, ftp, http, smtp, pop3, pop3s, imaps, imaps, xmpp, xmpps>. > > Esta lista es igual a la que se menciona en la regla 2. > > Me parece que con tantas opciones se vuelve a complicar. Pienso que > tal vez sería más práctico algo así como una lista ya predefinida > donde podamos cambiar las propiedades. Y quién predefinió la lista? > Esa lista podría ser > editable mediante configuraciones avanzadas o incluso podría ser > descargable automáticamente desde algún servidor en internet. Whatever. Quiero ese comportamiento! > > El tráfico prioritario tendrá disponible entre el <100%> y el > > <90%> > > No te olvides de que nunca hay que asignar el 100% del ancho de > banda de la interfaz entrante. Si no hay nada más que tráfico prioritario presente, quiero que el traáfico prioritario use todo el ancho de banda disponible! > Perderás un poquitito pero evitás > que los paquetes entrantes sean encolados por el proveedor. Mirá... sin traffic shaping activado, todo el tráfico tiene el 100% del ancho de banda disponible, así no tiene que ser problema. Además recordá que al tráfico no prioritario le asigné un mínimo garantizado de 10% de la capacidad del enlace, pero no quiere decir eso que el tráfico prioritario sólo puede usar hasta el 90% del enlace: en ausencia de tráfico no prioritario, el tráfico prooritario debe poder usar el 100% del enlace. > De esa > forma, si hay una cola esta se forma en tu maquina y podés > controlar el órden en que se da paso a los paquetes. Si se arma una > cola en el proveedor ya no podrás priorizar el ssh por ejemplo. No tiene por que armarse cola en el ISP, si el tráfico prioritario tiene garantizado el 90% del enlace y el no prioritario tiene garantizado el 10% del enlace. Tal vez no fui explícito antes: dije que el tráfico prioritario podía usar entre el 90% y el 100% del enlace, pero queda más claro diciendo que se le garantiza el 90% del enlace. Pero esos valores son míminos garantizados. Si hay más ancho de banda disponible, tanto el tráfico prioritario como el no prioritario tienen que poder usarlo, hasta saturar el enlace. > > - Si dejo bittorrent corriendo en el servidor/router: > > Cosa muy probable, ya que el router es la máquina chica (que > consume poco) que siempre está funcionando, así que es el lugar más > lógico para poner un mldonkey. Efectivamente y así es como lo uso, solo que no estoy todo el tiempo compartiendo cosas, sino de vez en cuando... > > - no repercute negativamente en la experiencia de usuario al > > usar la web, el mail, la mensajería instantánea, etc. desde la > > red interna. > > Bueno, se me ocurre que sería interesante facilitar aún más las > cosas para el usaurio. Preguntarle sólo qué servicios locales se > corren y cuál es el ancho de banda de subida y bajada y que "algo" > genere automáticamente las reglas más recomendables para ese caso. Vos hacé ese algo! Yo estoy hablando de lo que ese algo termine haciendo cuando se le pida que haga feliz al usuario! > De hecho, ese "algo" podría estar en internet o depender de algo > que se pueda descargar automáticamente desde internet para así > poder ir mejorando la cosa sin tener que actualizar software. Aburrido! > El programa también podría hacer una pureba para adivinar por sí > mismo el ancho de banda de la línea. Lo que tendría que hacer sería > suspender temporalmente el ruteo y los servicios locales y probar > una descarga y un envío a uno o más servidores en internet y medir > el ancho de banda conseguido. Ni en pedo dejo a un programa apagarme servicios! > > - Si me pongo a bajar descontroladamente en el servidor y en 2 de > > las máquinas de la red interna, cada una de esas 3 puede gozar de > > aproximadamente 1/3 del ancho de banda del enlace. > > - Si pongo una cuarta máquina máquina a bajar, se reacomoda > > todo y las cuatro disfrutan de 1/4 del ancho de banda del enlace > > a Internet. > > También sería interesante poder asignar a alguna máquina, mediante > IP o mediante MAC, una prioridad especial para la máquina del jefe. No, eso no me interesa. Que las cosas sean simples, todos iguales. > > Quién es el valiente que responde con las reglas que implementan > > ese comportamiento? > > Yo creo que esto es más que nada cosa de paciencia. Si está > orientado a una interfaz de usuario, primero habría que diseñar esa > interfaz. No. Primero díganme si las condiciones que plateé tienen sentido. Luego escriban por mí a mano o como les guste las reglas que implementen esas restricciones. Luego las pruebo y valido. Luego, si tenés ganas escribís tu GUI. > Planteados exactamente cuáles son los datos de que > disponemos la cosa es leer el LARTC y probar hasta que salga. Ese era el desfío! -- Herr Groucho ID Jabber: [EMAIL PROTECTED] Señal distintiva: LU5MJR - 144,550 MHz FM. Clave pública GPG: hkp://pks.lugmen.org.ar Fingerprint GPG: B7BD 0FC7 D9A2 66F3 4EFC 45EE 7DE2 3932 597B 6354
