Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Notificación de congestión cuantificada del centro de datos (DCQCN)

El acceso directo remoto a memoria (RDMA) proporciona un alto rendimiento y una latencia ultrabaja, con una baja sobrecarga de CPU, necesarios para las aplicaciones de centros de datos modernos. RDMA se implementa mediante el protocolo RoCEv2, que se basa en el control de flujo basado en prioridades (PFC) para habilitar una red sin caídas. La notificación de congestión cuantificada del centro de datos (DCQCN) es un esquema de control de congestión de extremo a extremo para RoCEv2. Junos admite DCQCN combinando la notificación de congestión explícita (ECN) y PFC para superar las limitaciones de PFC y admitir Ethernet sin pérdidas de extremo a extremo.

Descripción de DCQCN

El control de flujo basado en prioridad (PFC) es una función de transporte sin pérdidas y alivio de congestión que funciona al proporcionar control de flujo a nivel de vínculo granular para cada punto de código IEEE 802.1p (prioridad) en un vínculo Ethernet dúplex completo. Cuando el búfer de recepción de una interfaz de conmutador se llena a un umbral, el conmutador transmite una trama de pausa al remitente (el par conectado) para impedir temporalmente que el remitente transmita más tramas. El umbral de búfer debe ser lo suficientemente bajo para que el emisor tenga tiempo de detener la transmisión de tramas y el receptor pueda aceptar las tramas que ya están en el cable antes de que el búfer se desborde. El conmutador establece automáticamente umbrales de búfer de cola para evitar la pérdida de tramas.

Cuando la congestión obliga a pausar una prioridad en un enlace, todas las demás prioridades en el enlace continúan enviando tramas. Sólo se transmiten tramas de la prioridad pausada. Cuando el búfer de recepción se vacía por debajo de otro umbral, el conmutador envía un mensaje que inicia de nuevo el flujo. Sin embargo, dependiendo de la cantidad de tráfico en un vínculo o asignado a una prioridad, pausar el tráfico puede causar congestión en el puerto de entrada y propagación de la congestión a través de la red.

La notificación de congestión explícita (ECN) permite la notificación de congestión de extremo a extremo entre dos puntos finales en redes basadas en TCP/IP. Los dos puntos de conexión son un emisor habilitado para ECN y un receptor habilitado para ECN. Debe habilitar ECN en ambos puntos de conexión y en todos los dispositivos intermedios entre los puntos de conexión para que ECN funcione correctamente. Cualquier dispositivo en la ruta de transmisión que no admita ECN interrumpe la funcionalidad ECN de extremo a extremo.

ECN notifica a las redes sobre la congestión con el objetivo de reducir la pérdida y el retraso de paquetes haciendo que el dispositivo de envío disminuya la velocidad de transmisión hasta que la congestión desaparezca, sin perder paquetes. RFC 3168, La adición de notificación de congestión explícita (ECN) a IP, define ECN.

La notificación de congestión cuantificada del centro de datos (DCQCN) es una combinación de ECN y PFC para admitir Ethernet sin pérdidas de extremo a extremo. ECN ayuda a superar las limitaciones de PFC para lograr Ethernet sin pérdidas. La idea detrás de DCQCN es permitir que ECN realice un control de flujo al disminuir la velocidad de transmisión cuando comienza la congestión, minimizando así el tiempo que se activa PFC, lo que detiene el flujo por completo.

El correcto funcionamiento de DCQCN requiere equilibrar dos requisitos en conflicto:

  1. Asegurarse de que el PFC no se active demasiado pronto, es decir, antes de dar a ECN la oportunidad de enviar comentarios sobre la congestión para ralentizar el flujo.

  2. Asegurarse de que PFC no se active demasiado tarde, lo que provoca la pérdida de paquetes debido al desbordamiento del búfer.

Hay tres parámetros importantes que debe calcular y configurar correctamente para lograr los requisitos clave anteriores:

  1. Headroom Buffers: un mensaje de pausa enviado a un dispositivo ascendente tarda algún tiempo en llegar y surtir efecto. Para evitar caídas de paquetes, el remitente de pausa debe reservar suficiente búfer para procesar cualquier paquete que pueda recibir durante este tiempo. Esto incluye los paquetes que estaban en vuelo cuando se envió la pausa y los paquetes enviados por el dispositivo ascendente mientras procesa el mensaje de pausa. Los búferes de espacio libre se asignan por puerto y por prioridad fuera del búfer compartido global. Puede controlar la cantidad de búferes de margen asignado para cada puerto y prioridad mediante los parámetros MRU y longitud de cable en el perfil de notificación de congestión. Si observa caídas menores de entrada incluso después de activar el PFC, puede eliminar esas caídas aumentando los búferes de margen para esa combinación de puerto y prioridad.

  2. PFC Threshold: es un umbral de entrada. Este es el tamaño máximo al que puede crecer un grupo de prioridad de entrada antes de que se envíe un mensaje de pausa al dispositivo ascendente. Cada prioridad PFC tiene su propio grupo de prioridades en cada puerto de entrada. Los umbrales de PFC se establecen por grupo de prioridad en cada puerto de entrada. Hay dos componentes en el umbral PFC: el PG MIN umbral y el PG shared umbral. Una vez PG MIN que se alcanzan los umbrales para PG shared un grupo de prioridad, se genera PFC para esa prioridad correspondiente. El conmutador envía un mensaje RESUME cuando la cola cae por debajo de los umbrales PFC.

  3. ECN Threshold: este es un umbral de salida. El umbral ECN es igual al valor de nivel de llenado inicial de WRED. Una vez que una cola de salida supera este umbral, el conmutador inicia el marcado ECN para los paquetes de esa cola. Para que DCQCN sea eficaz, este umbral debe ser inferior al umbral de PFC de entrada para garantizar que PFC no se active antes de que el conmutador tenga la oportunidad de marcar paquetes con ECN. Establecer un nivel de llenado WRED muy bajo aumenta la probabilidad de marcado ECN. Por ejemplo, con la configuración predeterminada de búfer compartido, un nivel de inicio y llenado WRED del 10 por ciento garantiza que los paquetes sin pérdida tengan la marca ECN. Pero con un nivel de llenado más alto, la probabilidad de marcado ECN es menor. Por ejemplo, con dos puertos de entrada con tráfico sin pérdidas al mismo puerto de salida y un nivel de inicio y llenado WRED del 50 por ciento, no se producirá ninguna marca ECN, ya que primero se cumplirán los umbrales PFC de entrada.

Configuración de DCQCN (Junos OS)

Para habilitar DCQCN, configure ECN y PFC para un flujo de tráfico.

  1. Configure clasificadores para el tráfico ROCEv2 y para los paquetes de notificación de congestión (CNP). Por ejemplo:
  2. Configure ECN en el puerto de salida para un flujo sin pérdidas. Por ejemplo:
  3. Configure PFC en el puerto de entrada para el mismo flujo sin pérdidas. Por ejemplo:
  4. Configure los búferes compartidos. Por ejemplo:
    Nota:

    Debe seguir estas reglas para confirmar la configuración en plataformas que ejecutan Junos OS:

    • Debe configurar las tres particiones de entrada o ninguna.

    • Debe configurar las tres particiones de salida o ninguna.

    • La suma de la configuración del búfer compartido de entrada para todas las particiones debe ser del 100 por ciento.

    • La suma de la configuración del búfer compartido de salida para todas las particiones debe ser del 100 por ciento.

  5. Configurar clases de reenvío y asignar colas. Por ejemplo:
  6. Compruebe su configuración. Por ejemplo:
  7. Confirme su configuración.

Configuración de DCQCN (Junos OS evolucionado)

Para habilitar DCQCN, configure ECN y PFC para un flujo de tráfico.

  1. Configure clasificadores para el tráfico ROCEv2 y para los paquetes de notificación de congestión (CNP). Por ejemplo:
  2. Configure ECN en el puerto de salida para un flujo sin pérdidas. Por ejemplo:
  3. Configure PFC en el puerto de entrada para el mismo flujo sin pérdidas. Por ejemplo:
  4. Configure los búferes compartidos. Por ejemplo:
    Nota:

    Debe seguir estas reglas para confirmar la configuración en plataformas que ejecutan Junos OS Evolved:

    • Debe configurar las tres particiones de entrada.

    • La suma de la configuración del búfer compartido de entrada para todas las particiones debe ser del 100 por ciento.

    • Para particiones de búfer con y sin pérdida, tanto los porcentajes de partición de búfer de entrada como de salida deben ser iguales.

    • QFX5000 conmutadores que ejecutan Junos OS Evolved no tienen un grupo de servicios dedicado para el tráfico de multidifusión debido a limitaciones de hardware, por lo que el tráfico de multidifusión utiliza búferes compartidos del grupo de servicios con pérdidas.

    La configuración dynamic-threshold de la partición de búfer de entrada sin pérdida es opcional. ECN utiliza esta opción para el cálculo del umbral en colas sin pérdida. Si no configura esta opción, dynamic-threshold usará su valor predeterminado de 7.

  5. Configurar clases de reenvío y asignar colas. Por ejemplo:
  6. Compruebe su configuración. Por ejemplo:
  7. Confirme su configuración.