Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 09:56:29PM +0200, Raúl Alexis Betancor Santana dijo:
> Que da igual si es tu router, o el del operador .. TU no puedes
> controlar por donde va a pasar ese paquete ... y entre todos los
> routers/switches por los que pase, UNO habrá que borrarrá los campos,
> es que no hay ningún RFC que diga que esos campos se tengan que
> respetar extremo a extremo ... y como tál NADIE los respeta.
Vale. Zanjada la cuestión entonces. Paso de esos campos.
> TU no controlas lo que te llega a tu interfaz WAN, lo controla TU OPERADOR.
Sí, lo he pillado ahora: como los paquetes me han llegado ya a la
interfaz, ya no me sirve de mucho clasificarlo escrupulosamente. Es más
eficiente intentar evitar que me lleguen en demasía a ella actuando
sobre la salida gracias a...
> No lo has entendido ... los protocolos de control de flujo de TCP,
De todos modos, por redundar en esto, aunque vea la eficacía de
clasificar a la salida y ya está. Si a la entrada, jamás acepto más de
1Mbit/s de tráfico HTTP, precisamente por el control de flujo de TCP, el
envío acabará ralentizándose también ¿no?: acepto menos, eso acabará
suponiendo que reciba menos, que envíe menos paquete ACK de
confirmación y, por lo tanto, que los servidore web a los que pido me
acaben enviando a menor ritmo.
Lo que sí puede resultar absurdo es intentar montar una planificación
HTB.
> De hecho es el típico ejemplo de porque en la mayoría de los casos, no
> se puede aprovechar al 100% el ancho de banda de bajada de una
> ADSL/FTTH, porque sino eres capaz de enviar los ACK's de salida ... el
> servidor remoto irá reduciendo la tasa a la que te manda tráfico de
> entrada, hasta llegar a un equilibrio.
Pues me interesaría poder hacer una estimación a priori de qué tráfico
ACK de confirmación debo dejar salir, si quiero que me acabe llegando
"X" tráfico de entrada. Y sobre esta estimación, pulir un poco, probado
en la realidad.
A ver si voy desencaminado (suponiendo que el grueso mayor del tráfico
de salida es HTTP):
Un paquete ACK tiene unos 60-70 bytes de longitud, creo recordar. Los
paquetes de entrada, sin embargo serán bastante mayores, puesto que
contienen la información que he pedido (una página, una foto, un
archivo de vaya usted a saber qué. etc...). O sea, que habrá muchos que
ronden los 1400 bytes y algunos que sean algo más pequeños. Estimemos
que su tamaño medio es de 1300 bytes. Así pues, 65/1300 da el 5%. O sea
que el tráfico de salida ACK está sobre el 5% del tráfico que recibiré.
Por tanto, si tengo 10 Mb/s de ancho de banda de bajada, 500Kbit/s de
tráfico ACK de confirmación podrían consumirme todo ese ancho. Así pues,
tendré que asegurarme de que el tráfico de paquetes ACK sea menor para
que no se llegue a ese extremo, al menos cuando haya otro tráfico que
necesite hacer uso también de ese ancho de bajada.
¿Es así el cálculo, más o menos?
> Lás únicas reglas que tengo para el downlink .. en todo el script ... son:
>
> ########## downlink #############
> # s1ow downloads down to somewhat less than the real speed to prevent
> # queuing at our ISP. Tune to see how high you can set it.
> # ISPs tend to have *huge* queues to make sure big downloads are fast
Vale, y he visto que después tienes limitado el tráfico al 70% del ancho de
bajada. El hecho de que las colas de paquetes en el ISP sean grandes,
¿qué supone? ¿Mayor lantencia? ¿No acabo desaprovechando al final un 30%
del ancho haciendo esto?
Muchas gracias. Creo que voy aclarando conceptos..
--
La juventud es un defecto que se cura con el tiempo
--- Enrique Jardiel Poncela ---
Reply to: