PFC - La Neutralidad de Red: Gestión de tráfico mediante DPI/DFI

En los siguientes enlaces se puede acceder a la culminación de mi Proyecto Final de Carrera, en el que se abarcan varios aspectos sobre la Neutralidad de Red.

Memoria final: https://www.dropbox.com/s/acl09cgzi0qx9s0/pfc_memoria.pdf

Diapositivas lectura: https://www.dropbox.com/s/t5g44n3pqt8gdl6/pfc_presentacion.pdf


Índice



Capítulo I – Introducción ............................................................................................................. 15


Capítulo II – Conceptos básicos sobre Internet ........................................................................... 17
1 Estructura de Internet ..................................................................................................... 18
1.1 Núcleo de Internet .................................................................................................. 18
1.1.1 Modelo inicial de Internet ............................................................................... 19
1.1.2 Modelo actual de Internet .............................................................................. 19
1.2 Red de acceso .......................................................................................................... 21
2 El modelo OSI & TCP/IP ................................................................................................... 23
3 El principio ‘end-to-end’ .................................................................................................. 25
4 Factores económicos ....................................................................................................... 26
4.1 Cadena de valor ....................................................................................................... 26
4.2 El mercado bilateral ................................................................................................ 29
4.3 El mercado de acceso e interconexión IP ................................................................ 30


Capítulo III – Neutralidad de Red ................................................................................................ 34
1 Origen del debate ............................................................................................................ 35
2 Casos destacados ............................................................................................................ 36
3 Aspectos de la Neutralidad de Red ................................................................................. 39
4 Contexto internacional .................................................................................................... 42


Capítulo IV - Gestión de tráfico ................................................................................................... 44
1 Antecedentes de la gestión de tráfico ............................................................................ 46
2 Prácticas de gestión de tráfico ........................................................................................ 48
3 Tipos de tráfico y QoS ..................................................................................................... 50
4 Gestión de tráfico basada en QoS y ‘policing’ ................................................................. 52
4.1 Gestión de tráfico en redes móviles ........................................................................ 54
4.1.1 GSM/GPRS/EDGE, UMTS/HSPA - GPRS Core Network .................................... 56
4.1.1.1 Arquitectura de red ..................................................................................... 56
4.1.1.2 Niveles de QoS ............................................................................................. 57
4.1.1.3 Políticas de control ...................................................................................... 57
4.1.1.4 Análisis de tráfico en 2G/3G ........................................................................ 57
4.1.2 LTE/SAE – Evolved Packet Core ....................................................................... 58
4.1.2.1 Arquitectura de red ..................................................................................... 59
4.1.2.2 Niveles de QoS ............................................................................................. 61
4.1.2.3 Políticas de control ...................................................................................... 64
4.1.2.4 Análisis de tráfico en SAE/LTE ..................................................................... 65
4.2 Gestión de tráfico en redes fijas.............................................................................. 66
4.2.1 Cable - DOCSIS ................................................................................................. 66
4.2.1.1 Arquitectura de red ..................................................................................... 67
4.2.1.2 Niveles de QoS ............................................................................................. 68
4.2.1.3 Políticas de control ...................................................................................... 69
4.2.1.3.1 IPDR ....................................................................................................... 69
4.2.1.3.2 PCMM .................................................................................................... 70
4.2.1.4 Análisis de tráfico en Cable ......................................................................... 71
4.2.2 Acceso fijo - TISPAN ......................................................................................... 72
4.2.2.1 Arquitectura de red ..................................................................................... 72
4.2.2.2 Niveles de QoS ............................................................................................. 73
4.2.2.3 Políticas de control ...................................................................................... 74
4.2.2.4 Análisis de tráfico en accesos fijos .............................................................. 76
4.3 Comparativa de arquitecturas de gestión QoS y Policy .......................................... 76


Capítulo V - Análisis del tráfico.................................................................................................... 79
1 Técnicas de análisis: SPI, DPI y DFI .................................................................................. 80
1.1 Aplicaciones de DPI/DFI .......................................................................................... 83
2 Implantación de sistemas DPI/DFI para la gestión de tráfico ......................................... 85
2.1 Ubicación de sistemas DPI/DFI ................................................................................ 85
2.2 Integración de sistemas DPI/DFI ............................................................................. 87
2.2.1 DPI/DFI dedicado ............................................................................................. 87
2.2.2 DPI/DFI integrado ............................................................................................ 87
2.2.3 Comparativa entre soluciones dedicadas e integradas................................... 89
3 Mercado DPI/DFI ............................................................................................................. 90
3.1 Fabricantes y soluciones relevantes ........................................................................ 90
3.1.1 Fabricantes puros ............................................................................................ 91
3.1.1.1 Sandvine ...................................................................................................... 91
3.1.1.2 Allot ............................................................................................................. 91
3.1.1.3 Procera ........................................................................................................ 92
3.1.1.4 Ipoque ......................................................................................................... 93
3.1.2 Fabricantes clásicos ......................................................................................... 93
3.1.2.1 Cisco ............................................................................................................ 93
3.1.2.2 Ericsson ........................................................................................................ 94
3.2 Valor de mercado .................................................................................................... 95
4 Aspectos técnicos de DPI/DFI .......................................................................................... 97
4.1 Arquitectura de sistemas DPI/DFI ........................................................................... 97
4.1.1 Interconexión: ATCA ........................................................................................ 97
4.1.2 Procesado de datos ......................................................................................... 98
4.1.2.1 Plano de datos y plano de control ............................................................... 99
4.1.2.2 Tipos de procesadores para comunicaciones ............................................. 99
4.1.2.2.1 ASIC & NPU .......................................................................................... 100
4.1.2.2.2 Communication Processor .................................................................. 100
4.1.2.2.3 CPU multi-núcleo ................................................................................ 101
4.1.2.2.4 Procesador de flujo ............................................................................. 103
4.2 Clasificación de paquetes en flujos ....................................................................... 107
4.3 Análisis DPI ............................................................................................................ 111
4.3.1 Algoritmos de búsqueda DPI ......................................................................... 113
4.3.1.1 ‘String Matching’ ....................................................................................... 114
4.3.1.2 Regular Expression (RegEx) ....................................................................... 115
4.3.1.2.1 Teoría de autómatas ........................................................................... 116
4.3.1.2.1.1 NFA: Non-deterministic Finite Automata ..................................... 117
4.3.1.2.1.2 DFA: Deterministic Finite Automata ............................................ 118
4.4 Análisis DFI ............................................................................................................ 119
5 Análisis de tráfico real: Ejercicio práctico ..................................................................... 123
5.1 P2P (Peer-To-Peer) ................................................................................................ 123
5.1.1 BitTorrent ...................................................................................................... 123
5.1.2 eDonkey ......................................................................................................... 125
5.2 VoIP (SIP + RTP) ..................................................................................................... 125
5.3 Email (SMTP + IMAP) ............................................................................................. 127
5.4 Conclusiones del ejercicio ..................................................................................... 130


Capítulo VI – Implicaciones, conclusiones y recomendaciones ................................................ 131
1 Implicaciones ................................................................................................................. 132
1.1 Modelo ‘best effort’ .............................................................................................. 132
1.2 Modelo de tráfico gestionado ............................................................................... 133
1.3 Ventajas e inconvenientes .................................................................................... 135
2 Conclusiones.................................................................................................................. 137
3 Recomendaciones ......................................................................................................... 144


Anexo A – Contexto regulatorio internacional .......................................................................... 146
1 Unión Europea ............................................................................................................... 146
1.1 Marco Legislativo .................................................................................................. 146
1.2 Declaración de la Comisión Europea sobre la Neutralidad de Red ....................... 148
1.3 Consulta pública .................................................................................................... 148
1.4 Comunicado de la Comisión sobre la Neutralidad de Red .................................... 151
1.5 Recomendaciones del Parlamento Europeo ......................................................... 151
2 EEUU .............................................................................................................................. 153
2.1 Internet Policy Statements .................................................................................... 153
2.2 Report&Order : Preserving the Open Internet ..................................................... 154
3 Chile ............................................................................................................................... 156
3.1 Proyecto de Ley ..................................................................................................... 156
3.2 Requisitos de transparencia .................................................................................. 157
4 Holanda ......................................................................................................................... 160
4.1 Enmienda de Ley ................................................................................................... 160
5 Francia ........................................................................................................................... 162
5.1 Consulta pública sobre propuesta de directrices .................................................. 162
5.2 Propuestas y recomendaciones ............................................................................ 162
6 Reino Unido ................................................................................................................... 165
7 Suecia ............................................................................................................................ 166
8 Canadá ........................................................................................................................... 167
8.1 Telecom Decision 2008-108 .................................................................................. 167
8.2 Telecom Regulatory Policy CRTC 2009-657 ........................................................... 167
9 Noruega ......................................................................................................................... 169
10 Japón ......................................................................................................................... 170


Anexo B – Análisis de tráfico real .............................................................................................. 171
1 OpenDPI ........................................................................................................................ 171
2 Capturas de tráfico ........................................................................................................ 172
2.1 P2P (Peer-To-Peer) ................................................................................................ 172
2.1.1 BitTorrent ...................................................................................................... 172
2.1.2 eDonkey ......................................................................................................... 174
2.2 VoIP (SIP + RTP) ..................................................................................................... 176
2.3 Email (SMTP + IMAP) ............................................................................................. 177
Referéncias ............................................................................................................................... 179

Entendiendo DPI: Wireshark & OpenDPI

En posteriores posts se irá analizando como trabaja "Deep Packet Inspection (DPI)" en aspectos tanto software como hardware. Antes de ello es interesante ver, aunque sea de modo simplificado, un ejemplo del análisis que ofrece esta tecnología. Para ello se emplean dos versiones 'open source' de las varias que hay disponibles, una es la herramienta de captura de tráfico Wireshark, y la otra el codigo OpenDPI de Ipoque. Con ellas se puede ver como distinguen entre diferentes tipos de tráficos y de flujos.

Se ha hecho una captura del tráfico generado en una sesión estándar de usuario, tráfico web, tráfico P2P, cliente de mensajería, etc mediante el propio Wireshark. El tráfico capturado corresponde al uso de estas aplicaciones durante unos 5 minutos. Veamos como muestran los protocolos las dos herramientas empleadas.

Wireshark es una herramienta de análisis y captura de tráfico que emplea DPI, aunque a un nivel superficial (podríamos hablar más bien de SPI). Se suele emplear en entornos educativos y a nivel de usuario ya que no soportaría un análisis masivo de tráfico. Ofrece un entorno gráfico con algunas opciones interesantes que facilitan la visualización de las particularidades de cada protocolo. En la siguiente imagen se muestra una de las visualizaciones que permite esta herramienta.

Por otro lado, OpenDPI es una versión limitda de la que el proveedor de soluciones de gestión de ancho de banda Ipoque ofrece en sus productos, el motor PACE (Protocol and Applicaton Classification Engine). Por ello, el número de protocolos que es capaz de detectar es considerablemente inferior al de la versión comercial, así como la velocidad y rendimiento del análisis. No emplea análisis heurístico o de comportamiento, por lo que no es capaz de detectar conexiones cifradas o enmascaradas. La misma captura realizada con esta herramienta da el siguiente resultado que se muestra a continuación.

Como se puede observar el número de paquetes que considera la herramienta OpenDPI son los paquetes IP, que suman 31.468. A diferencia de la visualización que ofrece Wireshark, OpenDPI solo muestra la capa L7, que es la que contiene la información sobre el tipo de aplicación. Se puede observar que existe una mayor precisión en el análisis realizado por OpenDPI, aunque como ya se preveía por ser una versión reducida no ha logrado identificar alrededor de un 15% de los paquetes (esta cifra en el análisis de Wireshark es notablemente superior). 

Este mismo ejercicio se realizará cuando se hable de "Deep Flow Inspection (DFI)", pero habilitando la opción de cifrar el tráfico que poseen la mayoría de clientes P2P. Así se mostrará como responde la herramienta OpenDPI ante este tráfico cifrado, que en principio no puede ser detectado solo con DPI.

Deep Packet Inspection (DPI)

Como se ha venido diciendo en el blog, la capacidad de acceder a Internet se está viendo desbordada. El crecimiento del consumo de datos es mayor que el de la tecnología que se empela para su tratamiento, dando lugar la necesidad de "La Gestión de Tráfico". Esta gestión se lleva a cabo para solventar o prevenir problemas de congestión mediante el análisis y posterior clasificación del tráfico que atraviesa las redes. En principio, si no se hiciese una "Violación de recomendaciones y normas en Internet", bastaría con analizar a que puerto se dirige un paquete o flujo de paquetes para saber de que tipo de tráfico se trata, ya que existen una serie de asignaciones sobre que protocolo o aplicación debería emplear dicho puerto. 

Pero la realidad es bien distinta, muchas aplicaciones pretenden no ser descubiertas para que así su tráfico no se vea afectado por las medidas de gestión de la congestión. Para ello hacen uso de puertos indebidos, abren varias conexiones en paralelo (ver "Cómo funciona Internet? (II)"), o en el caso más extremo encriptan u ofuscan su tráfico para dificultar la identificación. Por este motivo, empresas como Sandvine, Ipoque, Allot o Procera e incluso grandes fabricantes de equipos de red como Cisco o Ericsson, han desarrollado en los últimos años elementos capaces de identificar de forma muy precisa el tráfico que atraviesa la red. Estos equipos se basan en DPI (Deep Packet Inspection) y en DFI (Deep Flow Inspection) o análisis heurístico.

La tecnología DPI es capaz de analizar los datos que contiene un paquete más allá de las cabeceras del L3 (que es la única necesaria para transmitir los paquetes) y la del L4 (que aunque no es necesaria, es dónde se encuentra información sobre el flujo de datos y el puerto conexión). Para comprender algo mejor el tema de las cabeceras ver "Cómo funciona Internet?". Esto supone que la información de la capa de aplicación (L7) e incluso el contenido del usuario puede ser analizado para buscar ciertos patrones característicos de la aplicación o protocolo en uso, o también para prevenir ataques o malware.

El hecho de que se pueda analizar la información de usuario es uno de los aspectos más críticos en el debate de "La Neturalidad de Red" debido a que según los detractores de DPI, este viola la privacidad de los usuarios. En su defensa, fabricantes e ISPs alegan que para nada se lee o comprende la información del usuario ya que tan solo se buscan palabras en concreto. Como todo, la peligrosidad depende del uso que se le dé.

Violación de recomendaciones y normas en Internet

En anteriores posts se ha hablado sobre "La Gestión de Tráfico" y sobre que se debería considerar un "Uso razonable de Gestión de Tráfico". Para llevarse a cabo esta dicha gestión, los administradores de red deben conocer que tipo de aplicación se está empelando para darle sus características necesarias, cómo por ejemplo el "Ancho de banda, latencia y jitter". Para conocer el tipo de aplicación debería bastar en la mayoría de ocasiones, en un escenario ideal, con conocer los números de puerto a los que se va a realizar la conexión, pero en la realidad esta información no es ni mucho menos suficiente. Recordemos que el puerto no es más un identificador que se emplea en la L4 (capa de transporte, ver "Cómo funciona Internet?") para identificar las diferentes aplicaciones que se pueden conectar a un equipo. 

Existe un listado de los números de puerto que se deberían utilizar para cada aplicación definidos por la  IANA (Internet Assigned Numbers Autority). Son llamados 'well-kwnon port' y su uso está en principio delimitado para procesos conocidos. En total suman 1024 y se pueden ver las asignaciones desde aquí. Además de los 'well-knwon port" existen más asignaciones entre los puertos 1024 y 49.151, aunque estos pueden ser utilizados por cualquier usuario. Del 49.152 al 65.535 son puertos dinámicos o privados.

Lo que es relevante es que muchas aplicaciones no respetan dichas asignaciones y emplean puertos que no son los que están especificados para tal efecto. Existen aplicaciones que utilizan estos 'well-known port' para poder colarse a través de firewalls sin más problemas ya que estos por norma general analizan el 5-tuple (dir. IP origen, dir. IP destino, puerto origen, puerto destino, protocolo) y según sus reglas deja o no pasar el paquete. Esto es lo que hacen muchas aplicaciones del tipo P2P (ver "El tráfico P2P"), emplean estos puertos para que no sean descubiertas. Los avances en técnicas de control ha llevado a los desarrolladores de este tipo de aplicaciones a realizar una asignación dinámica y al parecer aleatoria de puertos para así burlar estos firewall y evitar que un flujo de datos sea detectado. 


Para solventar este uso incorrecto de las numeraciones de puertos, además de para otras aplicaciones, la industria ha desarrollado los equipos de "Deep Packet Inspection (DPI)" y análisi heurístico que son capaces de desgranar en tiempo real hasta el último detalle no sólo de un paquete (que contiene una parte de la información), si no de todo un flujo de datos. Esto permite a los gestores de red identificar correctamente los datos de aplicación como lo que son para entonces decidir que hacer con ellos. 


Dicho todo esto cabe remarcar que en esta argumentación se apoyan los defensores de "La Gestión de Tráfico", entre muchas otras, de las que seguiremos hablando. El uso indebido de los 'well-known port' nos llevan a un modelo de Internet anárquico que se va al extremo del concepto de que Internet debe ser una red abierta y libre, y los extremos no son buenos.

Uso razonable de Gestión de Tráfico

Acerca de "La Gestión de Tráfico" se ha visto que su uso, teniendo en cuenta condiciones cómo "Ancho de banda, latencia y jitter" disponibles, puede resultar beneficiosa. Pero el problema está en determinar qué se considera una Gestión de Tráfico razonable y que no sea discriminatoria ni injusta. Los defensores de la Net Neutrality en su posición mas extrema abogan por un Internet en el que todos los paquetes sean tratados por igual, sin distinción de ningún tipo, no admitiendo ningún tipo de gestión. En el otro extremo se encuentra la Gestión de Tráfico en la que todo puede ser controlado y administrado sin ninguna condición (esto podría dar lugar a situaciones anticompetitivas donde, por ejemplo, un ISP pudiese llegar a bloquear el tráfico de otro ISP).

El esquema anterior muestra una buena aproximación de las posibles aplicaciones que se le puede dar a la Gestión de Tráfico. Cómo se puede apreciar, los usos posibles pueden ser beneficiosos cómo por ejemplo el bloqueo de aplicaciones maliciosas o prestación de mejor servicio para aplicaciones más vulnerables cómo VoIP, streaming, etc. No obstante, otras aplicaciones posibles serían degradación de tráfico P2P (ver "El tráfico P2P") o la priorización de algunos tipos de servicios según acuerdos comerciales (por ejemplo, el ISP A tiene un acuerdo con Skype y permite su tráfico sin problemas, mientras que el ISP B no lo tiene y lo degrada). Otro modelo podría ser el que se muestra en el post "La Neutralidad de Red", dónde se aplicacarían tarifas diferenciadas según los servicios consumidos. Cómo se puede apreciar las posibilidades que ofrece la Gestión de Tráfico son varias.

Ahora bien, qué es lo que se considera aceptable? Evidentemente esto dependerá de quien lo considere, no tendrá la misma opinión un usuario que un operador de red. Una buena aproximación de lo que debería ser una buena Gestión de Red debería cumplir con los siguientes criterios:

• Particularizada. Se debe adaptar a situaciones de la red teniendo en cuenta factores cómo picos de consumo, densidad de suscriptores, limitaciones propias del medio de acceso, etc.

• Proporcional. Debería aplicarse en la medida en que se produzca congestión en la red para evitar situaciones abusivas, llegando incluso al modelo 'best effort' si no exsite congestión.

• Equitativa. Se debería llevar a cabo de forma justa, sin llegar a privar a ningún cliente del servicio ni llegando a situaciones dónde un cliente tenga prioridad sobre otro.

• Necesidad técnica. Se debería planificar y diseñar una política de gestión en función de las necesidades técnicas que se den en la red en concreto.

• Transparente. El operador o ISP debería dar a conocer que medidas se toman y en que condiciones de modo que el cliente esté informado correctamente.

• Legítima. Evidentemente cualquier técnica de gestión debe cumplir con la legislación vigente en la zona geográfica en la que se aplique.

• Auditable. Para evitar problemas de cualquier índole los operadores e ISPs deberían de ser capaces de demostrar que la aplicación de Gestión de Tráfico responde a necesidades reales y que las medidas resultan efectivas.

El uso de técnicas de gestión bien llevado puede contribuir a un mejor Internet, siempre que esto no atente contra las bases sobre las que se ha sustentado su crecimiento. Internet ha llegado a ser lo que és precisamente gracias a estas bases que lo hacen libre y abierto, dónde todo tiene cabida. La tecnología disponible a día de hoy es capaz de detectar y gestionar el tráfico según las aplicaciones y necesidades asignando la calidad más apropiada y contribyendo a una mejora de la QoE (Quality of Experience), además de detectar posibles ataques e intrusiones.

Para ello muchas veces se hace uso de "Deep Packet Inspection (DPI)" y/o análisi heurístico precisamente porqué muchas apliaciones enmascaran el tipo de tráfico que se transporta y porqué violan algunas recomendaciones o normas de Internet. Pero esto ya es otro tema, que se analizará en el próximo post “Violación de recomendaciones y normas en Internet”.

El tráfico P2P

Se ha comentado brevemente que el tráfico P2P (peer-to-peer) ha sido y sigue siendo uno de los tipos de datos más conflictivos de Internet, veamos de que se trata. El tráfico P2P actualmente representa cerca de un 23% del tráfico de Internet, se lleva a cabo entre usuarios y en según que tipo de protocolo P2P esta totalmente descentralizado (en algunos otros si que se apoya algún servidor). A diferencia del modelo cliente-servidor dónde toda comunicación pasa por un punto centralizado (generalmente el proveedor de servicios o contenidos), en P2P el usuario es a la vez consumidor y proveedor. Recomiendo la lectura del post "La Gestión de Tráfico" dónde se habla de cómo este tipo de tráfico fue uno de los principales causantes de iniciar el debate de la Net Neutrality.

En P2P el ancho de banda disponible es la contribución de los anchos de banda de los diferentes usuarios. Esto implica que la computadora de un usuario realmente se comporta cómo un nodo de red más pudiendo actuar como cliente y servidor a la vez. Debido a la persecución contra los protocolos de P2P por parte de algunos ISPs o sistemas de seguridad de usuario ha llevado a sus diseñadores a tener que configurar protocolos muy complejos, con técnicas como tener un sistema dinámico de puertos o incluso cifrando el tráfico para no ser detectados. De aquí nace el análisis heurístico (ver "Análisis heurístico") que intenta detectar tráfico P2P a través de los patrones de la comunicación, ya que mediante DPI le es imposible determinarlo debido a las técnicas. Para una mejor comprensión de cómo actúa el tráfico P2P, leer el post "Cómo funciona Internet? (II)".

Sobre este tipo de estructura se han desarrollado diferentes tipos de aplicaciones que intentan aprovechar un modelo de red descentralizado que bien empelado ofrece una robustez y flexibilidad que no se da en el modelo cliente-servidor. Aplicaciones bien conocidas de intercambio de ficheros sobre P2P incluyen: eDonkey, BitTorrent, Ares o Napster. A estas se debe añadir Skype, el conocido servicio de VoIP y que también trabaja sobre P2P .

Los principales motivos que emplean los detractores de este tipo de red se fundamentan básicamente en que:

• la carga de tráfico suele ser elevada y constante, llevando a problemas de congestión

• los archivos que se comparten suelen violar derechos de copyright

En el asunto que nos ocupa el primer punto es el que causa problemas a los ISPs. El tipo de consumo que suele darse en P2P genera grandes volúmenes de tráfico que además suele ser constante. El hecho de que sean los propios usuarios los que generan tráfico hace que el enlace de subida UL (uplink) transporte mucha mas información que en el modelo cliente-servidor. El consumo de P2P se ve limitado por gran parte de las tecnologías de acceso ya que estas contienen al tráfico P2P gracias precisamente a que el ancho de banda de subida suele ser bastante menor que el de bajada, haciendo un cuello de botella. Los ISPs que mas congestión experimentan debido al P2P son los que tienen una enlace UL de gran capacidad (cosa que no suele suceder).

La Gestión de Tráfico

En los albores de la era Internet, cuando nos conectábamos con módem mediante Dial-Up (es una especie de llamada de datos, que hacía unos ruiditos muy raros y molestos al conectar), las limitaciones de Internet eran básicamente debidas a la propia tecnologia de acceso. No se daban problemas de congestión debido a cómo se trataban los datos y por lo tanto la Gestión de Tráfico no se hacía necesaria. Cuando aparecieron las primeras conexiones de banda ancha como el ADSL la cosa empezó a animarse un poco, y comenzaron a surgir novedosas aplicaciones y servicios en Internet. 

Hasta aquel momento Internet se basaba en un modelo cliente-servidor, lo cual quiere decir que los datos se descargaban mayormente desde la red hacia el usuario, tanto es así que en la tecnología xDSL se diseñaron los enlaces para tal fin: un pequeño enlace de subida (Uplink, UL) y uno mucho mayor de bajada (Downlink, DL). Pero apareció el P2P (peer-to-peer) a principios del milenio para cambiar un poco las cosas (una aplicación que tuvo mucho éxito fue Napster, el servicio para compartición-descarga de música). No se pretende explicar qué es el P2P en este post (ver "El tráfico P2P"), pero tan sólo comentar que es un tipo de red en la que la fuente de la información son los propios usuarios, y que en el caso más extremo está completamente descentralizado (sin servidores). Esto implicaba que los usuarios podían compartir datos en Internet, pero el diseño que se había hecho en las redes tipo cliente-servidor no la preparaba para este tráfico que a parte de utilizar mas DL también exigía más UL, siendo este último más crítico. 

Así, los ISPs comenzaron a experimentar problemas de congestión y algunos comenzaron a aplicar la Gestión de Tráfico, algo que hasta aquel entonces no se había hecho. Por abuso de lenguaje, con Gestión de Tráfico nos referimos a las técnicas que no tratan por igual a todos los paquetes, porqué Gestión de Tráfico cómo tal es cualquier estrategia que se siga para transferir datos. Esta técnica consiste en detectar que tipo de información contienen los paquetes IP y según lo que contenga darle mas o menos prioridad, retardarlo o incluso eliminarlo. Para saber que tipo de infromación lleva el paquete, en aquel entonces, se hacía una inpección "suave" de paquetes (SPI, Stateful/Shallow Packet Inspection), que consiste en identificar el 5-tuple (dir. IP origen, dir. IP destino, puerto origen, puerto destino, protocolo). Este tipo de análisis es el que suelen realizar los firewall y consiste en aplicar unas reglas de tratamiento de paquetes según unas listas de acciones permitidas. Si un paquete se quiere colar por un puerto que no esté definido para ello, o si el protocolo no esta permitido, por ejemplo, el paquete es descartado o retardado.

Además de otros que se han ido dando sin llegar a ser muy extremos, es conocido el caso Comcast que se dio en 2007 en EEUU debido a que esta compañía prestadora de acceso por cable fue procesada por aplicar Gestión de Tráfico en su tráfico P2P (ver "FCC vs. Comcast").

Por aquel entonces Internet ya formaba parte de nuestras vidas, y ya comenzaban a circular grandes contenidos multimedia por la red. Esta situación nos ha devuelto al modelo cliente-servidor (el vídeo - 26% del tráfico de Internet - ha superado al tráfico P2P - 24% del tráfico de Internet - por primera vez en 10 años, según Cisco), pero el problema sigue latente ya que se demanda mucha capacidad para este tipo de servicios. El problema se acentúa en los accesos móviles debido las limitaciones físicas que se dan en este medio.

La capacidad de burlar los sistemas de detección SPI ha llevado a muchos fabricantes a implementar sistemas capaces de realizar "Deep Packet Inspection (DPI)" y análisis heurístico (de comportamiento). Esto supone una forma nueva de Gestión de Tráfico ya que con estas tecnologías el contenido de nuestros paquetes puede ser investigado exhaustivamente sin que apenas se note en la calidad de la comunicación. Por otro lado, cabe decir también que gracias a esta herramienta se pueden detectar ataques o malware.

Lo cierto es que una buena Gestión de Tráfico puede ser beneficiosa para un gran conjunto de usuarios ya que no todas las aplicaciones que corren sobre Internet exigen el mismo ancho de banda, latencia o jitter (ver "Ancho de banda, latencia y jitter") y también puede hacer que se brinde una cierta QoE (Quality of Experience). No obstante, este tipo de prácticas abren también la puerta a ciertas conductas por parte de los ISPs que pueden considerarse anticompetitivas, discriminatorias e injustificadas. El problema al que se enfrentan las entidades regulatorias es precisamente determinar cual es el nivel de Gestión que se puede aceptar, si es que se debe aceptar, y bajo que condiciones (ver "Uso razonable de Gestión de Tráfico"). En próximos posts veremos las medidas que se han tomado en algunos países y algunas acciones que han tomado ISPs en contra de la Neutralidad de Red.

La Neutralidad de Red

En lo que va de blog se han visto algunos matices tecnológicos sobre "Qué es Internet?" y sobre "Cómo funciona Internet?", además se han introducido los algunos aspectos económicos en los posts el "Mercado bilateral en Internet" y el "El modelo económico de Internet". Con ello, a parte de lo que haya podido aportar a aquellos que no estuvieran puestos en el tema, se ha querido sentar la base sobre el tema del cual va a tratar fundamentalmente este blog: La Neutralidad de Red.

El debate se inició a mitad de década pasada, y se atribuye su definición a Tim Wu, profesor de la Columbia Law School y que aplicó este nombre retomando un concepto de las antiguas redes telegráficas, en las que no se podía controlar el contenido que se transportaba. El debate se puede considerar que se inició cuando la FCC (entidad reguladora de las comunicaciones electrónicas en EEUU) suprimió una ley que impedía a las compañías controlar el contenido que circulaba por sus redes.

Pero vayamos por partes. La gran penetración y éxito de Internet han elevado de forma abismal el consumo de datos, debido sobre todo al creciente uso de servicios multimedia que demandan un ancho de banda elevado para su correcto funcionamiento. Según un estudio de Cisco, el tráfico ha crecido 8x en los últimos cinco años, y se prevé que crezca 4x en los próximos cinco. Esto ha provocado o acabará provocando una saturación en las redes (sobre todo en los accesos) que ha iniciado una serie de debates sobre quién debe invertir en Internet o cómo se puede solucionar esta situación. El modelo surgido en los últimos años lleva a una situación en la que los operadores e ISPs se ven casi en la obligación de dar más capacidad a los usuarios o bien de gestionar los servicios de algún modo, para así brindar una buena QoE (Quality of Experience) a sus clientes.

La Neutralidad de Red (en realidad se debería decir la Neutralidad de Internet) es el principio por el cual todos los paquetes IP de Internet se deben tratar por igual, sin distinción de ningún tipo. De hecho, según el principio end-to-end sobre el diseño de Internet se afirma que la inteligencia de la red debe estar en los bordes, por lo que un análisis más allá del L3-L4 en un paquete o flujo de paquetes IP va en contra de dicho principio. Los nodos internos de Internet, según este principio, deberían direccionar los paquetes sin cuestionarse nada más que hacia donde debe enviarlos. Así, si se tratan los paquetes de forma distinta (se da más prioridad a uno que lleva tráfico HTTP frente a uno que lleva P2P, por ejemplo) es porqué se está empleando un análsisi profundo de los paquetes ya que dicha información está en la capa L7 y L7+. Este análisis es conocido como "Deep Packet Inspection (DPI)", y dará bastante que hablar en posteriores posts.

Lo contrario a la Neutralidad de Red es emplear la Gestión del Tráfico, que se suele hacer previa inspección DPI y que atenta, según su detractores, en contra de la privacidad de los usuarios. El caso es que en determinadas situaciones y condiciones (zonas geográficas, horas puntas, etc.) la gestión del tráfico puede resultar beneficiosa para la gran mayoría de usuarios finales. Entonces, si se acepta como una medida positiva, ¿dónde se deben poner los límites de que políticas de gestión son aceptables o no? De esto hablaré en mi próximo post: "La Gestión de Tráfico".

No hace falta decir quien se posiciona a cada lado del debate. Operadores e ISPs reclaman un modelo en el que los proveedores de servicios y contenidos paguen por emplear las redes en las que sustentan su negocio. Estos alegan que Internet es lo que es gracias a que todo aquel que lo desee puede utilizarlo para cualquier fin sin pagar por ello (salvo por el acceso) y que esto estimula una creatividad e innovación que está cambiado nuestros modos de vida y nuestra economía. Además de estos dos agentes, hay que añadir y tener en cuenta el papel de las entidades reguladoras, que en general se posicionan a favor de una Neutralidad de Red "a medias", tema del que se hablará en profundidad en posteriores posts.

Llegados a un extremo, podríamos imaginar un Internet en el que no hubiese ningún tipo de control del tráfico que circula por las redes, lo cual probablemente perjudicaría a la mayoría de usuarios en beneficio de unos pocos. El otro extremo sería aquel en el que tuviéramos una gama de tarifas por usos, por ejemplo:

1. Tarifa bronce:  (20€) ->  HTTP + Streaming
2. Tarifa plata:     (35€) ->  HTTP + Streaming+ P2P + VoIP 
3. Tarifa oro:       (50€) ->  HTTP + Streaming+ P2P + VoIP + VoD

Si las aguas llegaran a este cauce, lo que sí que se podría exigir es una cierta QoS (Quality of Service)  en los servicios por los que se está pagando de forma extra. Estaríais de acuerdo con este formato para contratar Internet?



HTTP : Navegación Web
Streaming: Youtube, Spotify, etc.
P2P (peer-to-peer): Compartición archivos como BitTorrent, Gnutella, etc (ver "El tráfico P2P")
VoIP (Voice over IP): Skype, Viber, etc.
VoD (Video on Demand): Netflix, etc.