----- Mensaje original ----- > De: "José Miguel (sio2)" <sio2.sio2+lista.deb...@gmail.com> > Para: debian-user-spanish@lists.debian.org > Enviados: Jueves, 14 de Mayo 2015 0:23:58 > Asunto: Re: [OT] ¿Cambian los ISP el ToS?
> 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. Si, el envío se ralentiza ... pero de lo que se trata, es de no saturar el enlace, porque desde que el enlace se sature y tu operador te empiece a hacer queuing en su router ... verás como se te disparan las latencias, he incluso empezarán a fallar conexiones. Se trata de repartir el ancho de banda disponible, sin llegar a saturar el enlace. > 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? A groso modo ... (porque depende del protocolo), es entre un 5-8% del downlink De ahí que las operadoras les 'encate' la proporción 10:1 ... porque saben que sin un QoS a penas que empieces a usar la conexión no podrás aprovecharla al máximo. > 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? Es porque eso lo saqué de un enlace FTTH, que como sabes, es PPPoE, así que si te 'venden' 100M/10M, lo que mucha gente no sabe, es que eso es la velocidad del enlace WAN, si sobre ese WAN, vas a montar un enlace PPPoE sobre una VLAN ... haz los cálculos, te sale un 18-22% de perdidas por encapsulación ... y como hablamos de no llegar a saturar el enlace ... es preferible limitar a un 70%. Que ¡Ojo! ... se permite bursting ... lo que se busca es que el enlace funcione estable al 70% de carga. Saludos -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1267356968.342455.1431587936720.javamail.zim...@dimension-virtual.com