¿Los switches sueñan con el aprendizaje automático? Clasificación Orientada Dentro de la Red

¿Los switches sueñan con el aprendizaje automático? Clasificación Orientada Dentro de la Red

Resumen

El aprendizaje automático está impulsando actualmente revoluciones tecnológicas y sociales. Si bien los interruptores programables han demostrado ser útiles para la informática en la red, el aprendizaje automático dentro de los interruptores programables ha tenido poco éxito hasta la fecha. Hacer aprendizaje automático sin equipo de red tiene un precio alto, ya que hacer el procesamiento dentro de la red tiene beneficios conocidos de rendimiento y eficiencia energética. En este documento, exploramos el potencial del uso de interruptores programables de propósito general para la clasificación dentro de la red mediante el mapeo de modelos de aprendizaje automático entrenados en una canalización de acción de coincidencia. Presentamos el prototipo IIsy basado en software y hardware y discutimos la aplicabilidad del mapeo a diferentes objetivos. Nuestra solución se puede generalizar a otros algoritmos de aprendizaje automático, utilizando el enfoque presentado en este documento.

Formato de referencia de ACM: Zhaoqi Xiong y Noa Zilberman. 2019. ¿Sueñan los conmutadores con el aprendizaje automático? Hacia la clasificación en la red. En el taller de ACM sobre temas candentes en redes (HotNets '19), del 13 al 15 de noviembre de 2019, Princeton, NJ, EE. UU. ACM, Nueva York, EE. UU., 9 págs. https://doi.org/10.1145/3365609.3365864

1. Introducción

El aprendizaje automático (ML) domina cada vez más los aspectos digitales de nuestra vida diaria, desde la personalización de las compras en línea hasta las redes sociales, las finanzas y las transacciones. La comunidad de sistemas está luchando para satisfacer las demandas de ML mientras enfrenta obstáculos cada vez mayores: desde el final de la Ley de Moore [33, 39] y el escalado de Dennard [19] hasta las limitaciones de memoria y costo [42]. Estos desafíos impulsan las innovaciones en el diseño de hardware de ML, incluidas las soluciones optimizadas para CPU (por ejemplo, [6, 53]), GPU (por ejemplo, [14]) y FPGA (por ejemplo, [18, 21, 51]), así como ASIC de procesamiento dedicado [ 12, 26]. Todas las formas de aceleración de ML han recibido una gran atención.

Las redes tampoco tienen tendencia a escapar de ML, que se utiliza para la optimización y la toma de decisiones (por ejemplo, [13, 23, 52]). Con el auge de los dispositivos de red programables, se esperaba que el aprendizaje automático dentro de la red fuera ampliamente utilizado. La computación en red no solo demuestra un rendimiento sobresaliente [24, 25], sino que también es energéticamente eficiente [50]. Sin embargo, el ML dentro de la red aún no se ha adoptado ampliamente en la comunidad en línea. De hecho, se ha demostrado que los dispositivos de red se pueden usar para mejorar el aprendizaje automático distribuido, como a través de la agregación en la red [45], pero no es así como se implementa el aprendizaje automático dentro de los dispositivos de red. Un posible primer paso hacia la inferencia dentro de las redes fue en N2Net [47] y BaNaNa Split [43], que discutieron formas de implementar redes neuronales dentro de dispositivos de red programables.

En este documento, nos enfocamos en la siguiente pregunta: ¿Podemos implementar el modelo entrenado en dispositivos de red programables cuando el entrenamiento de ML ya está en marcha? Al hacer esto, nos enfocamos en un aspecto específico de ML, a saber, la clasificación. Nos enfocamos en la clasificación de inferencia de ML basada en redes no neuronales y mostramos que un modelo de clasificación de paquetes entrenado se asigna sin problemas a un plano de datos programable. Este mapeo logra la clasificación del tráfico a tasas de flujo y encuentra un equilibrio entre recursos limitados, tasas de flujo y precisión de clasificación. Además, mostramos que mientras el conjunto de características sea estático, las actualizaciones del modelo de clasificación se pueden implementar solo a través del plano de control, sin necesidad de cambios en el plano de datos.

En este trabajo, nuestras contribuciones son las siguientes:

• Demostramos el mapeo de cuatro algoritmos de aprendizaje automático entrenados diferentes a la canalización de acción de coincidencia.

• Presentamos un marco de creación de prototipos basado en software y hardware que asigna automáticamente un modelo entrenado a una canalización de acción de coincidencia.

• Demostramos la clasificación dentro de la red en objetivos de hardware y cuantificamos los requisitos de recursos.

Nuestro campo de trabajo es limitado. No hemos explorado todos los algoritmos de ML, ni siquiera los más populares, como las redes neuronales, están fuera del alcance de este artículo. No reclamamos ninguna contribución en términos de algoritmos ML. Además, nuestro método tiene limitaciones de diseño en términos de precisión y tipos de características extraídas. Creemos que nuestra contribución taxonómica es el primer paso hacia una inferencia especializada más compleja dentro de los dispositivos de red. Nuestro código está disponible en [57].

1.1 Motivación

Ejecutar el aprendizaje automático (ML), es decir, ejecutar ML dentro del equipo de red, es una perspectiva emocionante, respaldada por varias razones. Primero, los interruptores tienen un rendimiento muy alto. La latencia a través de los conmutadores es del orden de unos pocos cientos de nanosegundos por paquete [3], mientras que la latencia de inferencia de los aceleradores de ML de gama alta está en el rango de decenas de microsegundos a milisegundos [26, 36]. El mismo acelerador logra 10-90 TOPS/seg [26], mientras que un switch de 16 Tb/seg admite aproximadamente 15 mil millones de paquetes por segundo [31]. Sin embargo, OPS/seg no se asigna directamente a la tasa de paquetes, por ejemplo, NVidia Tesla V100 puede inferir 10 000 imágenes por segundo [36], mientras que el mismo conjunto de datos de imágenes se puede transmitir a través de un conmutador a una tasa de más de 10 000 000 de imágenes por segundo. La eficiencia energética de los conmutadores de red les permite manejar decenas de miles de paquetes por vatio [50], mejor que la mayoría de los aceleradores, y los conmutadores programables [3] consumen menos energía absoluta que las alternativas actuales [26].

Los conmutadores también tienen otra ventaja: están en una posición ideal para ciertos casos de uso de ML. El rendimiento del aprendizaje automático distribuido está limitado por el tiempo que lleva transferir datos hacia y desde los nodos. Si un conmutador puede clasificar paquetes a la misma velocidad con la que transmite paquetes a los nodos en un sistema distribuido, podrá igualar o incluso superar el rendimiento de cualquier nodo individual. Fuera del centro de datos, los conmutadores tienen otras ventajas. Pueden terminar los datos antes de tiempo, reducir la carga de la red y permitir la escalabilidad con el tiempo. Terminar los datos cerca del borde ahorra energía, reduce la carga en la infraestructura y mejora la experiencia del usuario al reducir la latencia. Lo mejor de todo es que los conmutadores ya están implementados en la red y no es necesario instalar hardware adicional. Siempre que un solo conmutador pueda admitir operaciones de ML y de red, proporcionará una solución más económica que los sistemas mejorados con aceleradores de ML y liberará ciclos en la CPU que ejecuta aplicaciones de ML.

En este trabajo, solo nos enfocamos en la tarea de clasificación. A medida que el volumen de datos generados por los usuarios continúa aumentando, la red se convierte en nuestra primera línea de defensa contra el gran tamaño de los datos, que superan los 10 ZB por año [15]. Se espera que con la aplicación generalizada de Internet de las cosas (IoT), el tamaño de los datos se amplíe aún más y muchos de estos datos deberán clasificarse. Si bien los middleboxes aún pueden manejar la cantidad de procesamiento requerido en el borde hoy en día, es poco probable que continúen escalando a medida que crecen las demandas de datos. Pero, ¿y si pudiéramos ejecutar la clasificación dentro de la red antes de que los datos lleguen a su destino de procesamiento? No solo podemos descargar el procesamiento, sino que también podemos responder a los eventos antes, terminando el tráfico cerca del borde. Las aplicaciones como los automóviles autónomos y las fábricas automatizadas son algunas de las aplicaciones sensibles a la latencia [46] que se beneficiarían de esto.

Quizás el ejemplo más simple de una clasificación interna de red es Mirai Botnet, que utiliza dispositivos integrados y de IoT para lanzar ataques de denegación de servicio contra objetivos seleccionados [2]. ¿Sería posible detener un ataque antes de tiempo si el dispositivo de borde eliminara todo el tráfico relacionado con Mirai en función de los resultados de la inferencia basada en ML en lugar de usar listas de control de acceso "estándar"? Discutimos los casos de uso con más detalle en las Secciones 6.3 y 7.

2. Los interruptores como máquinas de clasificación

Las bolsas de productos básicos funcionan naturalmente como máquinas clasificadoras. Tomando como ejemplo un conmutador Ethernet de capa 2 estándar, mantenemos un modelo mental de un plano de datos programable, como el que utilizan P4 [8] o NPL [35], aunque es aplicable cualquier arquitectura de conmutador.

Cuando llega un nuevo objeto (paquete), el primer paso es extraer las características relevantes de él. En un conmutador, esto es similar a analizar el encabezado de un paquete. Cada campo de encabezado es en realidad una característica, y el analizador de encabezado es el extractor de características.

El siguiente paso en el proceso de clasificación es aplicar las características del objeto al modelo de aprendizaje automático entrenado. Para los conmutadores Ethernet de capa 2, el modelo toma la forma de un árbol de decisión no binario con una sola capa. La característica dividida de la raíz es la dirección MAC de destino. Al acceder a la tabla de direcciones MAC en el switch, se puede encontrar la rama correcta correspondiente a las características (dirección MAC de destino) del objeto (paquete). Una vez que se encuentra la rama adecuada, el objeto se asigna a una clase, lo que significa que el paquete se asigna a un puerto de salida. Ilustramos esta similitud en la Figura 1.

Un conmutador Ethernet de capa 2 también se puede representar mediante un árbol de decisión más complejo. Un ejemplo sería verificar si el puerto de origen es el mismo que el puerto de destino y, si el valor es el mismo, descartar el paquete. En un árbol de decisión, esto daría como resultado la adición de otra capa y una clase extra (caída).

¿Los switches sueñan con el aprendizaje automático?

​Figura 1: Similitud entre un árbol de decisión y una tubería de cambio simple. Los componentes similares están encerrados en un círculo. M/A significa operación de coincidencia. La salida de una canalización puede ser algo más que una asignación de puerto.

3. Puntos clave

Una de las razones por las que los algoritmos de aprendizaje automático no se han implementado en equipos de red hasta la fecha es la complejidad de implementación de las operaciones matemáticas requeridas. Las operaciones como la suma, XOR o los cambios de bits son fáciles de implementar en el hardware del conmutador, pero las operaciones como la multiplicación, los polinomios o los logaritmos no están bien canalizadas y pueden aumentar la latencia o afectar el rendimiento. Sin embargo, aunque los conmutadores no admiten operaciones como loä(x) o loä(y), operaciones como loä(x × y) se pueden realizar fácilmente una vez que se conocen loä(x) y loä(y).

No intentamos implementar operaciones matemáticas dentro del conmutador. En cambio, tomamos prestado de una práctica común en hardware programable (como FPGA) y computación de alto rendimiento: usar tablas de búsqueda para almacenar los resultados de los cálculos o equivalentes. La tabla de búsqueda encaja perfectamente con el paradigma de acción de emparejamiento utilizado por los interruptores programables.

En la práctica, la implementación no es tan fácil como parece. Los conmutadores de hardware tienen recursos limitados y no pueden almacenar tablas de tamaño infinito para admitir todos los valores posibles. La solución que adoptamos en este trabajo es no almacenar ningún valor subyacente en la tabla y estar dispuestos a perder algo de precisión a costa de la factibilidad. Además, ahorramos memoria al almacenar los resultados o códigos de clasificación (§5) en lugar de los resultados de los cálculos, lo que da como resultado un uso más eficiente de las tablas ternarias y de coincidencia de prefijo más largo (LPM).

El segundo punto ya mencionado es que el conmutador se configuró como una máquina de clasificación, el analizador actúa como un módulo de extracción de características y la canalización de acción de coincidencia se usa para realizar la clasificación.

En muchas arquitecturas de conmutadores, solo una parte de los paquetes atraviesa el plano de datos programable, mientras que el resto se almacena en búfer [8]. Para procesar todo el paquete, una solución es el procesamiento de paquetes en bucle, dividiendo el paquete (y las características) en unidades de datos del tamaño de un encabezado y avanzando paso a paso por la canalización. Este enfoque reduce el rendimiento y requiere ajustes para mantener los metadatos, pero aún puede funcionar bien con una baja utilización de la red o mejoras de velocidad suficientes.

4. Asignación real de recursos

Hasta ahora, hemos discutido las ideas clave para mapear un algoritmo de clasificación a una canalización de acción de coincidencia. En esta sección, adoptamos un enfoque más realista para considerar las limitaciones de los conmutadores básicos para la clasificación en las redes.

En primer lugar, observamos que los interruptores pueden no solo realizar la clasificación, sino también incluir importantes funciones de conmutación. Por lo tanto, se espera que las funciones básicas de red consuman recursos significativos antes de que consideremos el cambio y otras funciones de cambio como comportamientos de aprendizaje automático.

En segundo lugar, todas las soluciones de clasificación dentro de la red presentadas anteriormente comparten una propiedad importante: no requieren ninguna dependencia externa, es decir, ninguna funcionalidad específica de destino. Esta implementación pura de acción de coincidencia permite la portabilidad entre diferentes objetivos y significa que las soluciones no están bloqueadas en una sola plataforma.

Observamos que los interruptores programables de hoy en día admiten de 12 a 20 etapas por tubería, con múltiples (por ejemplo, cuatro) tuberías por dispositivo [3, 34], lo que limita las funciones admitidas. La memoria de la tabla puede ser del orden de cientos de megabits [9] y puede distribuirse a través de múltiples canalizaciones. Además, el analizador solo puede extraer una cantidad limitada de cabezas, posiblemente comparable a la profundidad de la canalización, por lo que en algunas implementaciones de clasificación, la cantidad de características será comparable a la cantidad de categorías. Por otro lado, el ancho de una característica puede ser bastante grande, por ejemplo, una dirección IPv6 tiene 128 bits de ancho. No es realista esperar que la profundidad de la tabla sea proporcional al ancho de las claves, sino al tamaño de la red (para conmutadores) o al problema de clasificación (para clasificación dentro de la red).

En la práctica, el uso de múltiples funciones como claves de tabla no será fácil de implementar: los proveedores de silicio han estado luchando para implementar tablas de búsqueda para las direcciones de 128 bits de IPv6, y las profundidades de memoria de última generación actuales solo alcanzan las entradas de 300K-400K [ 4, 5], por lo que cualquier cantidad significativamente mayor que esta cantidad (por ejemplo, más de un factor de 10) puede considerarse poco realista. Sin embargo, asumir que 128 bits es un ancho de clave factible abre oportunidades significativas: dado que los puertos TCP de origen y destino ocupan cada uno 16 bits, las banderas suelen tener solo unos pocos bits y el ethertype también tiene 16 bits, se pueden concatenar múltiples características en una sola clave sin alcanzar el ancho de una dirección IPv6.

Evitamos establecer límites en la cantidad de recursos necesarios para implementar diferentes algoritmos, ya que dichos límites se parecen poco a la realidad. Por ejemplo, si el ancho de la clave de la tabla es w, entonces la profundidad de la tabla será solo 2^w, y solo si la tabla está mapeada directamente, se puede implementar como una memoria simple y solo necesita almacenar acciones. El uso de tablas de coincidencia exacta, coincidencia de prefijo más largo y tipo de rango pretende evitar el requisito de profundidad de la tabla, pero da como resultado un mayor ancho de la tabla (ancho de clave más ancho de acción). Discutimos esto más adelante en la Sección 6.3.

Una forma de aumentar la cantidad de características (o categorías) utilizadas en la clasificación es encadenar múltiples canalizaciones, donde la salida de una canalización se usa como entrada para la siguiente canalización. Este enfoque enfrenta dos desafíos. Primero, reducirá el rendimiento máximo del dispositivo por un factor de la cantidad de tuberías conectadas. En segundo lugar, los metadatos que usamos entre etapas no se comparten entre canalizaciones [3], por lo que es posible que la información deba incorporarse en encabezados intermedios.

5. Del aprendizaje automático a la acción de emparejamiento

En este trabajo, adoptamos el enfoque P4 [8] del plano de datos programable, asumiendo un modelo de tubería genérico PISA o RMT [9]. Exploramos el uso de cuatro algoritmos para la clasificación de paquetes, incluido el aprendizaje supervisado y no supervisado: árboles de decisión, K-means, máquinas de vectores de soporte (SVM) y bayesiano ingenuo. Estos algoritmos fueron elegidos debido a sus diferencias y la generalización de los resultados. Las redes neuronales están más allá del alcance de este trabajo. La Tabla 1 resume nuestro enfoque.

5.1 Árbol de decisión

Los árboles de decisión se pueden mapear de manera intuitiva a canalizaciones de acción coincidente. En cada etapa, se aplica un conjunto de condiciones a una característica y sus resultados conducen a diferentes ramas del árbol. Dado que las condiciones son operaciones simples, se pueden implementar en P4. Sin embargo, este enfoque es un desperdicio porque la profundidad y la condición del árbol definen el número de etapas en la tubería. Proponemos un enfoque diferente, más adecuado para canalizaciones de acción coincidente: la cantidad de etapas implementadas en la canalización es igual a la cantidad de funciones utilizadas más una. En cada etapa, emparejamos una característica con todos sus valores posibles. El resultado (acción) se codifica en un campo de metadatos e indica la rama seleccionada en el árbol. La última etapa de la canalización obtiene los campos codificados de todas las características del bus de metadatos y asigna (coincide) los valores a los nodos hoja resultantes.

Los árboles de decisión se pueden implementar utilizando tablas de tipo de rango [37], pero estas tablas no están disponibles en muchos objetivos de hardware. Si el número de valores propios es conocido y limitado, en su lugar se puede utilizar una tabla de coincidencias exactas. Alternativamente, las tablas de triple valor y coincidencia de prefijo más largo (LPM) se pueden usar para dividir rangos en múltiples entradas, lo que aumenta el consumo de recursos (en comparación con las tablas de tipo de rango), pero proporciona rutas de uso viables.

5.2 Máquina de vectores de soporte (SVM)

El segundo algoritmo de aprendizaje supervisado es la máquina de vectores de soporte (SVM), que utiliza hiperplanos para separar diferentes clases. El resultado del proceso de entrenamiento toma la forma de múltiples ecuaciones, donde cada ecuación representa un hiperplano^5:

donde n es el número de características, k es el número de categorías y m = k * (k - 1) / 2.

Una forma de implementar una SVM (Tabla 1.2) es implementar m tablas, cada una dedicada a un hiperplano e indicando en qué lado del hiperplano se encuentra una entrada dada. Las claves que se utilizan para acceder a la tabla de coincidencias y acciones son colecciones de características y, para evitar operaciones complejas, las acciones son "votos". Un "voto" es un valor de un bit asignado al bus de metadatos que indica si la entrada pertenece dentro o fuera del hiperplano. Una vez que una entrada se compara con todas las m tablas, se cuentan todos los "votos" (la suma del bus de metadatos en todas las categorías), y la categoría con la mayor cantidad de "votos" es el resultado de la clasificación.

El segundo enfoque (Tabla 1.3) es dedicar una tabla para cada característica, y la salida de la tabla es un vector de la forma a1x1, a2x1, ...amx1. Al final de la tubería de acción de coincidencia, se calcula el valor de cada hiperplano, es decir, la suma de todos los vectores, y se toma una decisión. Este enfoque requiere tablas más pequeñas, pero tiene algunas limitaciones: los valores en el vector resultante tienen una precisión limitada (por ejemplo, no pueden representar números de punto flotante) y pueden requerir muchos bits. Además, es posible que se requieran operaciones lógicas significativas (operaciones de suma) al final de la canalización de acción de coincidencia.

​Tabla 1: Diferentes formas de implementar la clasificación dentro de la red en la canalización de acción de coincidencia. La lógica se refiere únicamente a las operaciones y condiciones de suma.

5.3 Bayesiano ingenuo

Exploramos clasificadores bayesianos ingenuos supervisados ​​[30] asumiendo distribuciones gaussianas independientes entre características [20]. Los enfoques relacionados con la clasificación del tráfico de red que pueden ser más precisos, como la estimación del kernel [32], seguirían conceptos de implementación similares. Bajo este supuesto, la probabilidad de la característica xi se expresa como:

y la regla de clasificación será:

Para un problema con k clases, usando n características, hay k × n (µy, σy) pares. Una implementación ingenua (Tabla 1.4) usaría k × (n + 1) tablas de acción de emparejamiento para calcular n probabilidades para k clases y el producto de todas las n probabilidades calculadas para esa clase. Este proceso no solo desperdicia recursos, sino que también es difícil de aproximar en hardware cuando el valor de probabilidad es pequeño.

El segundo enfoque (Tabla 1.5) utiliza una tabla por categoría con todas las características como claves. En lugar de valores de coma flotante como probabilidades para las clasificaciones, se devuelven valores enteros que representan las probabilidades. Este enfoque produce resultados precisos siempre que se utilicen valores similares en las tablas (diferentes clasificaciones) para representar probabilidades. La desventaja es el tamaño de la tabla requerida: utiliza claves muy anchas (que conectan todos los valores de características de entrada) y su profundidad es proporcional a este ancho.

5.4 K-medias

El agrupamiento de K-medias es un ejemplo de aprendizaje no supervisado. Para k categorías, proporciona k centros de conglomerados, cada centro de conglomerados consta de n valores de coordenadas y cada valor de coordenadas corresponde a una característica. La distancia desde una entrada dada x hasta el centro del grupo i se calcula de la siguiente manera:

donde x1 a xn son los valores de las características. La entrada se clasificará en el grupo con la distancia más pequeña.

Para seleccionar los conglomerados en función de la distancia más corta, solo se considera la distancia al cuadrado. Una opción es utilizar un enfoque de tabla por grupo (Tabla 1.7), donde las claves son todas las funciones. Este enfoque requiere menos tablas que el enfoque de una tabla por coordenada (Tabla 1.6), pero utiliza tablas más profundas y anchas. Otro enfoque (Tabla 1.8) es usar una tabla por característica cuya acción asigna un conjunto de valores de distancia a un solo eje del bus de metadatos, un valor por grupo. En este enfoque, la última etapa acumula simultáneamente vectores de distancia y clasifica al grupo con la distancia más pequeña.

Viabilidad: Según la Sección 4 y la Tabla 1, nuestra comprensión de los conmutadores reales muestra la viabilidad y las limitaciones de cada método de implementación. Lograr $4^6$ (Naive Bayes) y 6 (K-means) son ambos muy limitados. Incluso en un plano de datos dedicado a la clasificación, usar más de 4-5 funciones y 4-5 clases no es práctico y excedería la cantidad de etapas disponibles, o por el contrario, usar 2 clases y 10 funciones (viceversa). Otros métodos ofrecen más flexibilidad: se admiten hasta 20 categorías o funciones. Los clasificadores 1 (Árboles de decisión), 3 (Máquinas de vectores de soporte) y 8 (K-medias) tienen la mejor escalabilidad, que se puede lograr mediante una combinación del número de tablas, el ancho de las claves y el ancho de las acciones.

6 Prototipo y Evaluación

Implementamos un prototipo llamado IIsy (Inferencia en Redes Simplificadas) como validación de nuestras observaciones. Nuestro marco incluye una implementación basada en software que demuestra la capacidad de asignar automáticamente algoritmos de clasificación a dispositivos de red y una implementación basada en hardware que explora los requisitos de recursos y el rendimiento.

IIsy consta de tres componentes. El primero es un entorno de entrenamiento de aprendizaje automático. En segundo lugar, está el plano de datos programable dentro del equipo de red. El tercero es el plano de control utilizado para asignar el algoritmo entrenado a los dispositivos de red. El marco se muestra en la Figura 2.

Utilizamos Scikit-learn [40] como entorno de formación. Si bien la entrada para el entrenamiento puede ser cualquier conjunto de datos, usamos seguimientos de paquetes etiquetados como entrada para demostrar escenarios de tráfico realistas. Se eligió Scikit-learn por su facilidad de uso y se puede sustituir por otros entornos de capacitación siempre que su salida se pueda convertir a un formato de texto que coincida con nuestro plano de control.

​Figura 2: Arquitectura de alto nivel de IIsy. IIsy componentes son de color blanco. Las partes externas son grises.

6.1 Prototipos basados ​​en software

Nuestro prototipo basado en software implementa el plano de datos en la arquitectura v1model usando P4. El plano de control utiliza P4Runtime [38]. Usamos bmv2 y mininet para las pruebas. Escribimos un programa P4 para cada caso de uso. Un caso de uso se refiere a un par de parámetros: el algoritmo de aprendizaje automático utilizado y el tráfico de red esperado. El tráfico de red determina el diseño de los analizadores del plano de datos (es decir, qué encabezados deben analizarse), mientras que los algoritmos de aprendizaje automático definen el diseño de acción de coincidencia que debe implementarse.

Generamos el plano de control usando scripts de Python. Convertimos el resultado de la fase de entrenamiento de aprendizaje automático en escrituras de tabla en la canalización de acción de coincidencia, utilizando P4runtime. Si bien esta etapa es simple, es la etapa más importante: nos permite cambiar el funcionamiento de los dispositivos de red e implementar diferentes reglas de clasificación sin cambiar el programa P4, siempre y cuando el tipo de modelo de aprendizaje automático y el conjunto de funciones utilizado. sin cambios.

6.2 Prototipos basados ​​en hardware

Se implementó un prototipo de hardware de IIsy en NetFPGA SUME [59] usando el flujo de trabajo P4→NetFPGA [22]. Actualmente, P4→NetFPGA no es compatible con P4runtime, usamos la interfaz del plano de control P4→NetFPGA para implementar la configuración del plano de control. Nuestra implementación de hardware explora principalmente la viabilidad y la tasa de clasificación de la migración a objetivos de hardware. El programa P4 que usamos era muy similar al prototipo basado en software, pero con ligeras modificaciones para el objetivo de hardware: las tablas de tipo de rango se reemplazaron por tablas de coincidencia exacta o de valores triples, y la sintaxis se ajustó a los requisitos del P4. →Flujo de trabajo NetFPGA. Otra diferencia con nuestra implementación de software es que la arquitectura utilizada por P4→NetFPGA es SimpleSumeSwitch [22].

Para la evaluación del rendimiento, utilizamos OSNT, una herramienta de prueba de red de código abierto para generar tráfico y medir la latencia a velocidad de cable (4 × 10G) [1]. Dado que OSNT puede reproducir rastros de paquetes de tamaño limitado, se realizó una prueba funcional en una tarjeta de red X520 estándar usando tcpreplay para archivos de rastro grandes.

6.3 Ejemplo: Tráfico IoT

El Internet de las cosas es el escenario de aplicación impulsor para la clasificación en la red, como se describe en la Sección 1. Utilizamos los rastros de pcap de los dispositivos IoT publicados por Sivanathan y otros como nuestro conjunto de datos [48]. Nuestro objetivo es utilizar IIsy para clasificar el tráfico entrante según el tipo de dispositivo. Agrupamos los dispositivos monitoreados en cinco categorías: dispositivos domésticos inteligentes estáticos (p. ej., enchufes eléctricos), sensores (p. ej., sensores meteorológicos), audio (p. ej., asistentes inteligentes), video (p. ej., cámaras de seguridad) y “otros”. Seleccionamos categorías que se pueden asignar a diferentes grupos de QoS: desde ancho de banda alto (video) hasta mejor esfuerzo (categoría "otra"). Seleccionamos 11 características para la evaluación, como EtherType, protocolo IP y banderas, y puerto TCP. Todas las características se extraen directamente del encabezado del paquete. No utilizamos información de identificación, como direcciones MAC o IP, tanto para evitar resultados sesgados (dado que los dispositivos tienen direcciones fijas) como para demostrar la capacidad de clasificar implementaciones más allá de las prácticas de acción de coincidencia basadas en direcciones.

La Tabla 2 resume los atributos del conjunto de datos. Para seis de estas características, solo existe una pequeña cantidad de valores en el conjunto de datos, lo que significa que tablas muy pequeñas e incluso registros pueden ser suficientes para contener los valores calculados. La tabla que contiene el tamaño del paquete aún encajará en la tabla de búsqueda estándar [56]. Para los números de puerto TCP y UDP, es factible usar tablas de coincidencia exacta, pero a un alto costo en el objetivo de FPGA: cada una de estas tablas consumirá cerca de 2 Mb de memoria [56] y es posible que no cumpla con las restricciones de tiempo. Por lo tanto, utilizamos una tabla de tres valores, que permite hacer coincidir dentro de un rango de valores.

Seleccionamos 11 funciones, adecuadas para dispositivos como Barefoot Tofino, donde cada función usa una tabla y tiene una tabla de decisiones igual al número de etapas en la canalización [3, 34]. Esperamos que el trabajo futuro explore funciones más complejas, con una mayor cantidad de funciones (consulte la Sección 7) y la viabilidad de la implementación en la plataforma NetFPGA. Hacer coincidir las reglas de optimización con las tablas está fuera del alcance de este documento y se ha estudiado extensamente (por ejemplo, [10, 11, 27]).

Usamos Scikit-learn para entrenar el modelo y obtener las estadísticas del modelo. Validamos la clasificación contra mapeos de puertos. Nuestro objetivo es que la salida de clasificación del conmutador coincida con el resultado de clasificación del modelo.

Implementamos los cuatro modelos en IIsy, adoptando un enfoque por modelo, y evaluamos la funcionalidad y el consumo de recursos. Nuestras pruebas de rendimiento miden el rendimiento y la latencia, y se prueban solo con la implementación del árbol de decisiones.

La Tabla 3 proporciona una descripción general de los recursos necesarios para implementar estos modelos en la plataforma NetFPGA [59]. Las cifras de utilización se refieren a comparaciones relativas entre el uso de la FPGA Virtex-7 690T utilizada en esta placa. Usamos tablas pequeñas de 64 entradas, excepto la última tabla (de decisión), que usa coincidencias exactas y está configurada para la cantidad de opciones posibles. Una tabla de 512 entradas está bien para la FPGA, pero no puede cumplir con la sincronización a 200 MHz.

Los estudios de tablas pequeñas proporcionan información interesante. Por ejemplo, para un árbol de decisiones, cada función requiere de 2 a 7 rangos coincidentes, y estos rangos caben en una tabla con no más de 47 entradas, lo que es una diferencia significativa en comparación con los valores potenciales de 64K (como los puertos TCP) ahorros Por el contrario, los modelos que usan múltiples funciones como claves de tabla son más difíciles de asignar a las entradas de la tabla y requieren reordenar los bits entre las funciones (entrelazando primero los bits más significativos y luego los bits menos significativos) para lograr una coincidencia de rango cruzado. Como era de esperar, 64 entradas no son suficientes para un partido sin pérdidas.

La implementación más precisa utiliza árboles de decisión. El modelo entrenado en la profundidad 11 logra una precisión de 0,94, con puntuaciones similares de precisión, recuperación y F1. Reducir la profundidad del árbol de decisión reducirá la precisión de la predicción en un 1 %-2 % por nivel. En NetFPGA, implementamos una canalización con solo cinco niveles, con una precisión y una puntuación F1 de alrededor de 0,85. Por lo tanto, solo se requieren cinco características. Vale la pena recordar que nuestro objetivo no es encontrar el mejor modelo de clasificación de tráfico, sino realizar clasificaciones tan precisas como el modelo entrenado. Evaluamos la precisión de nuestra implementación reproduciendo los rastros de pcap del conjunto de datos y verificando que los paquetes lleguen a los puertos esperados por la clasificación. Nuestros resultados de clasificación están exactamente en línea con las predicciones del modelo entrenado. También evaluamos el rendimiento de la implementación mediante OSNT y verificamos que cumplimos con los requisitos de velocidad de cable completa. La latencia (según la versión de la cadena de herramientas) de nuestro diseño es de 2,62 µs (±30 ns), comparable a un diseño de referencia (sin aprendizaje automático) P4→NetFPGA con un número similar de etapas.

​Tabla 2: Propiedades seleccionadas del conjunto de datos de entrenamiento de IoT

​Tabla 3: Utilización de recursos de la implementación de clasificación en red en NetFPGA-SUME.

7 discusiones

Computación dentro de la red: la clasificación dentro de la red es una forma de computación dentro de la red. Aunque en este trabajo damos por sentada la computación dentro de la red, siguiendo algunos trabajos bien conocidos (por ejemplo, [24, 25, 44]), esta área de investigación todavía se considera controvertida e inmadura [7, 41]. Un desafío importante es que la computación dentro de la red consume los recursos necesarios para otros fines de la red. El uso de conmutadores como aceleradores conectados a la red mantiene la ventaja de rendimiento sin compartir recursos, pero consume energía y espacio casi nulos que son prácticamente gratuitos cuando se calculan como parte del recorrido de la red de un paquete.

Extracción de funciones: en nuestro prototipo, utilizamos principalmente funciones extraídas de los encabezados de los paquetes. Del mismo modo, se pueden extraer funciones como consultas de caché [50] o solicitudes de DNS [55]. Las características como el tamaño de la cola pueden estar disponibles a través del bus de metadatos de la canalización, pero estas características dependen de la arquitectura. La extracción de características que requieren estado, como el tamaño del flujo, es posible [29, 49] pero requiere el uso de contadores o componentes externos y puede ser específica del objetivo. Muchos modelos de aprendizaje automático requieren funciones complejas, que es posible que no se puedan extraer en los conmutadores.

Rendimiento y escalabilidad: nuestra implementación solo utiliza tablas de acción de coincidencia sin operaciones complejas. Por lo tanto, en un objetivo de hardware, el rendimiento de IIsy será similar a la tasa de procesamiento de paquetes de la plataforma. Si bien IIsy se escala con el rendimiento, es posible que no se escale con la cantidad de funciones o el valor de cada función. Esta es una propiedad que varía entre los objetivos de hardware (§4). La solución que brindamos tiene el costo de la precisión de la clasificación en términos de recursos, y se espera que las clases menos precisas se marquen para su posterior procesamiento por parte del host, similar a [54].

Conmutador ASIC: Portar IIsy a conmutadores básicos es un trabajo futuro. Las discusiones con los proveedores de interruptores han demostrado que esto es posible y que el rendimiento a la velocidad del cable es posible.

Escenarios de aplicación: los escenarios de aplicación más anticipados para IIsy son los relacionados con el tráfico de red, como la clasificación del tráfico [32], ya que IIsy proporciona un medio para manejar los desafíos de escalabilidad de la capacidad de tráfico [16]. Los escenarios de aplicación relevantes incluyen filtrado de tráfico y mitigación de ataques de denegación de servicio distribuidos. El control de congestión es otro posible escenario de aplicación en el que las características disponibles en ciertos objetivos de hardware, como el tamaño de la cola, se pueden usar para el control de congestión.

8 Trabajo relacionado y conclusiones

En los últimos años, la investigación en los campos del aprendizaje automático (ML) y las redes ha crecido rápidamente. Estos estudios abordan aspectos como la clasificación del tráfico de red [17, 32, 58], la programación y el control de la congestión mediante ML [23, 52]. Los marcos de ML utilizan dispositivos de red para la aceleración [18, 44], que pueden actuar como servidores de parámetros o para tráfico de agregación y multidifusión [28, 45].

La implementación de la inferencia dentro de los dispositivos de red aún está en pañales. N2Net [47] y BaNaNa Split [43] demostraron la implementación de redes neuronales binarias dentro de dispositivos de red y analizaron la sobrecarga de procesamiento y comunicación. Li [28] propuso un método para implementar el aprendizaje por refuerzo dentro de un interruptor, pero utilizando un módulo de aceleración personalizado. Este documento es complementario a estos trabajos y analiza los algoritmos de ML para redes no neuronales.

En este documento, presentamos un marco de clasificación dentro de la red llamado IIsy. Mapeamos algoritmos para aprendizaje supervisado y no supervisado para canalizaciones de acción coincidente y discutimos la aplicabilidad de estas implementaciones. Nuestro prototipo implementa versiones de software y hardware y puede clasificar paquetes del mundo real a velocidad de línea completa. Este es solo el primer paso hacia la implementación de ML dentro de los dispositivos de red, y el próximo desafío importante es implementar la capacitación dentro de la red.