Barrapunto

No es que cada uno tenga su definicion de lo que considera tráfico importante, es que hay tráfico que tolera retrasos/retransmisiones (emule, ftps, https) y tráfico que no (sesiones ssh, conversaciones voip, videoconferencia).

Vamos, que a ti que te den menos preferencia en el emule te supondrá 1kb/s menos de bajada, pero a lo mejor a una conversación voip el no tener esa preferencia le supone cortes en la conversación, sonido a saltos etc... no se si me explico ;)

Y QoS, se implementa así, según el tipo de paquete, el tipo de tráfico, no es que se califiquen las ips como más o menos prioritarias

Por supuesto que hay tráfico al que la latencia le hace polvo (además de los retrasos por falta de qos)

Pero eso es desde el punto de vista técnico.

Y 40 millones de líneas de móviles enrutadas por ip sí pueden significar un problema.

Lo malo es que las definiciones de qos se hacen por parte del que vende el servicio (como ahora). Y simplificar y flexibilizar el qos sólo implica que los isps tengan más control que ahora.

Ahora mismo el qos ya se usa. Una línea empresarial de internet a 200 euros al mes es eso.
Una línea con mucha prioridad en los routers del operador.

O sea, que por una parte se puede imponer la prioridad de los operadores de telefonía (que sí, que el voip va mejor con prioridad y que a los operadores les encantará simplificar su ip-switching y poder pasar del circuit-swiich directamente por internet para problema de todos y beneficio suyo) que no veo porqué tiene que ser imponible o ni siquiera importante. Y por otra parte el criterio de pago influirá mucho más que ahora en lo que consigas ¡porque los criterios de qos tendrán efecto en todos los enrutamientos de tus paquetes ip, no sólo en los de tu proveedor!

"Y QoS, se implementa así, según el tipo de paquete, el tipo de tráfico, no es que se califiquen las ips como más o menos prioritaria"

Pero a la larga significa que sí se califica tu ip al asignarsele la "clase de tráfico" como les convenga. La más fácil por grupos de ip.
Por que el objetivo de la clase de tráfico es crear capas de prioridad de origen a destino.

Y tienen una enorme cantidad de capas para definir si quieren. ¿porqué crees que va a ser en función del tipo de flujo si es de dudosa verificación? Esa es la teoría. Flujos que necesitan garantía, flujos que se asegura la entrega y flujos que valoran esfuerzo.

La práctica será que habrá capas estancas con asignación arbitraria de prioridad. Tantas como hagan falta. Y casi seguro que las cabezeras ip de los paquetes las asignarán los isp's, por rangos y como les convenga.

.

Pero eso es inherente a los routers, dado que una comunicación siempre se puede identificar por la ip de destino o la de origen.

Por ello se puede filtrar y encolar con prioridad sobre las ip's. Lo difícil es que es por ip individual (y casi siempre puerto para identificar el servicio)

Ahora se podrá asignar un identificador a los paquetes de rangos enteros de ip's y ese identificador podrá ser utilizado por todos los routers sin necesidad de que conociesen tu ip para decidir tu prioridad. (normalmente será navegación-cutre-prioridad-nula)

Y ya se han preocupado de definir la prioridad máxima (y supongo que ya han pensado que todos los routers implemente esa prioridad al menos y alguna otra genérica y además también habrán pensado quién la usará).

Vamos, que todos como ovejas al drm de las ip's.

Claro, que al depender de la buena voluntad ¿existirán routers cambia-capa-de-prioridad-anónimos el día de mañana?

Aunque a nivel de ISP no les costará demasiado detectar un cambio en la clase de navegación (que ellos conocen por tu rango) e identificarte como infractor.

.