Hugo, No caben dudas que las políticas restrictivas como vía para gestionar el ancho de banda no solo son del tipo "paguen justos por pecadores", sino que la forma en que impactan en la calidad de servicio percibida por los usuarios es bien diferente que si se aplicaran otros mecanismos.
Los problemas con los delay pools del squid no acaban con los que menciona luis. El delay pools limita la razón a la cual es squid retorna información de cache misses. Como el squid no es quien envía o recibe los paquetes directamente (el kernel lo hace), el solo puede controlar la cantidad de bytes que son leídos del kernel. Los paquetes realmente son encolados en los buffers del kernel y ya han viajado a través del downlink con tu ISP, y por tanto ya han consumido el ancho de banda. Recuerda aquí que el tráfico web es asimétrico. Por acá por la CUJAE hace ya casi 4 años que realizamos gestión de ancho de banda usando las herramientas de control de tráfico que trae el kernel. La solución lleva una pc router justo en el medio del enlace de tu red con tu ISP para que sea efectiva. A esta solución hace un tiempo le añadimos la posibilidad de diferenciar el tráfico a nivel de usuarios empleando el tag tcp_outgoing_tos del squid. Esta opción te permite mediante acls colocarle marcas arbitrarias en el campo DSCP de la cabecera IP. La única desventaja que tiene es que no se pueden usar acls externas, o sea, que lleven lookups contra repositorios fuera de la memoria del squid. Esto quiere decir que el contenido de las acls es cargado en memoria. Ya con la marca hecha, en dependencia del usuario, el paquete puede luego ser tratado y enviado a una clase de servicio determinada en tu pc_gestor_de_trafico. Te puedo decir que hemos tenido muy buenas experiencias con esta solución. La escalabilidad o extensibilidad está solo en tu imaginación. Puedes diferenciar el tráfico no solo por la información presente en la cabecera de los paquetes sino también por el usuario que la generó. Por supuesto que esta última variante está limitada solo para el caso en que emplees un proxy http en tu red y aún así solo sería para el tráfico web. A los colegas de la uci les recomiendo revisen esta solución. Les permitiría clasificar el tráfico, en este caso basado en origen (cuba, no-cuba, etc), y luego aplicarle políticas de QoS sobre esta base. Para más información puedes remitirte: http://lartc.org/ http://www.squid-cache.org/Doc/config/tcp_outgoing_tos/ saludos, Evelio PD: usamos Ubuntu y el tag del squid que te menciono solo está disponible, creo recordar, a partir de la versión 2.6.1. Para la funcionalidad a nivel de usuario te hace falta un kernel superior a la versión 2.6.24. Luis Zarrabeitía escribió: >> Irving Leonard escribió: >>> Sobre Hugo: >>> Él plantea el problema de la administración del ancho de banda >>> mediante el >>> bloqueo de sitios para aligerar el tráfico (nada interesante que ver, >>> menos >>> tráfico); no creo que sea una gran solución aunque es la más común. >> >> Agreed. Mi experiencia en la UH es que la mayor parte del tráfico (un >> porciento >> asombrosamente alto) se consume en dominios de poco tráfico (varios >> miles de >> dominios distintos que cada uno de ellos transmite menos de 1 mega en >> el mes), >> por lo que bloquear sitios _para ahorrar ancho de banda_ es inútil. >> Por ejemplo, >> bloquear el sitio que más tráfico tenía (gmail) no nos reportó ninguna >> ganancia >> en velocidad, porque ese sitio de mayor tráfico consume un porciento >> bajísimo >> del total. >Por favor, nótese que jamás recomendé bloquear indiscriminadamente los >sitios de más tráfico (ese no fue el criterio), sino bloquear aquellos >sitios que consumen amplitud de banda innecesariamente, pues tienen poco >o nada que ver con la actividad de la institución. Yo no prohibo a >ninguno de los investigadores de mi centro de trabajo que usen yahoo, >gmail, o inlcuso hotmail, pues cuando viajan es la manera que tienen de >comunicarse, pero comprenderán que con un enlace conmutado sería una >locura permitir youtube, por ejemplo. Es una cuestión de simple >practicidad, y francamente me sorprende un poco que no le veas utilidad. >> Sería bueno que se exploraran alternativas, especialmente alternativas que no se >> presten para la "censura" bajo el pretexto de "ahorrar recursos" (que en el caso >> UH, es falso). Por ejemplo: >> >>> ¿Exite algún mecanismo en el squid para manejar QoS? ¿Hay otra >>> combinación para lograr la restricción del ancho de banda por >>> usuario? Algo así como "cada usuario solo puede utilizar 2kbps" o >>> similar. >> >> El squid tiene para controlar AB por _máquina_ y por _red_, pero no por usuario. >> Es decir, si tienes dos usuarios usando la misma máquina (caso "clientes >> diskless"), no puedes distinguir entre ellos. La opción que buscas se llama >> "delay pools". Otro problema que tiene es que no es dinámico: i.e, no se adapta >> para aumentar el canal de las máquinas en los momentos en que hay pocos clientes. >> >> Creo que hay unos parches (no recuerdo si están incluidos en debian, no los he >> usado) para modificar los campos QoS de los paquetes generados por el squid >> basados en las ACLs. >> >Por supuesto que lo ideal sería una herramienta que permitiera controlar >la amplitud de banda por usuarios dinámicamente. Pero yo francamente no >la he encontrado. Tengo pensado instalar el Varnish como alternativa al >Squid en una computadora que debo comenzar a montar en cuanto Tecun >finalmente decida reabastecerse (hace más de dos meses que espero un >disco duro y dos memorias que ya están pagados). Dicen que este software >es muy eficiente y su configuración muy flexible y potente, quiero >comprobar si de veras es capaz de ofrecer un rendimiento entre 10 y 20 >veces superior al Squid como dicen, eso vendría muy bien. >Pero en fin, si alguien tiene recomendaciones en cuanto a la gestión de >la amplitud de banda, se agradecería que compartiese cualquier experiencia. >Saludos, Hugo VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com _______________________________________________ Cancelar suscripción https://listas.softwarelibre.cu/mailman/listinfo/linux-l Buscar en el archivo http://listas.softwarelibre.cu/buscar/linux-l
