Ajude-nos a melhorar a sua experiência.

Conte-nos a sua opinião.

Tem dois minutos para uma pesquisa?

close
keyboard_arrow_left
list Table of Contents

Esta tradução automática foi útil?

starstarstarstarstar
Go to English page
ISENÇÃO DE RESPONSABILIDADE:

Esta página será traduzida com software de tradução por máquina de terceiros. Embora esforços razoáveis tenham sido feitos para fornecer uma tradução de qualidade, a Juniper Networks não pode garantir sua exatidão. Se houver dúvidas sobre a exatidão das informações contidas nesta tradução, consulte a versão em inglês. O PDF para download está disponível apenas em inglês.

Notificação explícita de congestionamento cos

date_range 09-Jan-25

A notificação explícita de congestionamento (ECN) permite a notificação de congestionamento de ponta a ponta entre dois endpoints em redes baseadas em TCP/IP. Os dois endpoints são um remetente habilitado para ECN e um receptor habilitado para ECN. A ECN deve ser habilitada em endpoints e em todos os dispositivos intermediários entre os endpoints para que a ECN funcione corretamente. Qualquer dispositivo na caminho de transmissão que não ofereça suporte à ECN quebra a funcionalidade ECN de ponta a ponta.

A ECN notifica as redes sobre o congestionamento com o objetivo de reduzir a perda e o atraso de pacotes, fazendo com que o dispositivo de envio diminua a taxa de transmissão até que o congestionamento seja liberado, sem deixar cair os pacotes. RFC 3168, a adição de notificação explícita de congestionamento (ECN) ao IP, define ECN.

A ECN é desativada por padrão. Normalmente, você habilita a ECN apenas em filas que lidam com o tráfego de melhor esforço porque outros tipos de tráfego usam diferentes métodos de notificação de congestionamento — o tráfego sem perdas usa o controle de fluxo baseado em prioridade (PFC) e o tráfego de prioridade rigorosa recebe toda a largura de banda de porta que requer até o ponto de uma taxa máxima configurada.

Você habilita a ECN em filas de saída individuais (conforme representado pelas aulas de encaminhamento) permitindo a ECN na configuração do agendador de filas, mapeando o agendador para as aulas de encaminhamento (filas) e aplicando o agendador em interfaces.

Existem dois tipos de ECN: ECN estática e ECN dinâmica (D-ECN). A ECN estática exige que você configure manualmente os limiares que desencadeiam notificações de congestionamento, e os limites permanecem os mesmos até que você altere a configuração. A ECN dinâmica ajusta os limites automaticamente com base em condições em tempo real, como comprimento da fila e padrões de tráfego.

Em dispositivos suportados, ambas as versões ECN podem ser habilitadas em seu dispositivo ao mesmo tempo, mas apenas uma versão pode ser atribuída a uma fila específica de cada vez.

Nota:

Para que a ECN trabalhe em uma fila, você também deve aplicar um perfil ponderado de queda de pacotes de detecção antecipada aleatória (WRED) na fila.

Como a ECN funciona

Sem A ECN, os dispositivos respondem ao congestionamento da rede ao soltar pacotes TCP/IP. Pacotes perdidos sinalizam a rede de que o congestionamento está ocorrendo. Os dispositivos da rede IP respondem a quedas de pacotes de TCP reduzindo a taxa de transmissão de pacotes para permitir que o congestionamento se libere. No entanto, o método de queda de pacotes de notificação e gerenciamento de congestionamento tem algumas desvantagens. Por exemplo, os pacotes são descartados e precisam ser retransmitidos. Além disso, o tráfego estourado pode fazer com que a rede reduza demais a taxa de transmissão, resultando em utilização ineficiente de largura de banda.

Em vez de soltar pacotes para sinalizar congestionamento de rede, a ECN marca pacotes para sinalizar congestionamento da rede, sem deixar cair os pacotes. Para que a ECN funcione, todos os dispositivos no caminho entre dois endpoints habilitados para ECN devem ter a ECN habilitada. A ECN é negociada durante a criação da conexão TCP entre os endpoints.

Os dispositivos habilitados para ECN determinam o estado de congestionamento de fila com base na configuração de perfil de queda de pacotes WRED aplicada na fila, de modo que cada fila habilitada para ECN também deve ter um perfil de queda WRED. Se uma fila se encher até o nível em que o perfil de queda wred tem uma probabilidade de queda de pacote superior a zero (0), o dispositivo pode marcar um pacote como tendo congestionamento. Se um dispositivo marca ou não um pacote como congestionamento é a mesma probabilidade que a probabilidade de queda da fila nesse nível de preenchimento.

A ECN comunica se o congestionamento é experiente ou não, marcando os dois bits menos significativos no campo de serviços diferenciados (DiffServ) no cabeçalho IP. Os seis bits mais significativos no campo DiffServ contêm os bits de ponto de código de serviços diferenciados (DSCP). O estado dos dois bits ECN sinaliza se o pacote é ou não um pacote com capacidade de ECN e se o congestionamento foi ou não vivenciado.

Os stores com capacidade de ECN marcam pacotes como capazes de ECN. Se um remetente não for capaz de ECN, ele marca pacotes como não capazes de ECN. Se um pacote com capacidade de ECN experimentar congestionamento na fila de saída de um dispositivo, o dispositivo marca o pacote como tendo congestionamento. Quando o pacote chega ao receptor com capacidade de ECN (endpoint de destino), o receptor remete o indicador de congestionamento ao remetente (endpoint de origem) enviando um pacote marcado para indicar congestionamento.

Após receber o indicador de congestionamento do receptor, o endpoint de origem reduz a taxa de transmissão para aliviar o congestionamento. Isso é semelhante ao resultado da notificação e gerenciamento de congestionamento de TCP, mas em vez de soltar o pacote para sinalizar congestionamento da rede, a ECN marca o pacote e o receptor ecoa a notificação de congestionamento para o remetente. Como o pacote não está descartado, o pacote não precisa ser retransmitido.

Bits ECN no campo DiffServ

Os dois bits ECN no campo DiffServ fornecem quatro códigos que determinam se um pacote é marcado como um pacote de transporte (ECT) capaz de ECN, o que significa que ambos os endpoints do protocolo de transporte são capazes de ECN e se há congestionamento experiente (CE), como mostrado na Tabela 1:

Tabela 1: Códigos de bit ECN

Bits ECN (código)

Significado

00

Não-ECT — o pacote é marcado como não capaz de ECN

01

ECT(1)— Os endpoints do protocolo de transporte têm capacidade para ECN

10

ECT(0)— Os endpoints do protocolo de transporte são capazes de ECN

11

CE — Congestionamento experiente

Os códigos 01 e 10 têm o mesmo significado: os endpoints de envio e recebimento do protocolo de transporte são capazes de ECN. Não há diferença entre esses códigos.

Comportamento de ECN de ponta a ponta

Após o envio e o recebimento de endpoints negociarem a ECN, o envio de endpoint marca pacotes como capazes de ECN, configurando o campo DiffServ ECN para ECT(1) (01) ou ECT(0) (10). Todos os dispositivos intermediários entre os endpoints devem ter a ECN habilitada ou não funciona.

Quando um pacote atravessa um dispositivo e experimenta congestionamento em uma fila de saída que usa o mecanismo de queda de pacotes WRED, o dispositivo marca o pacote como tendo congestionamento ao definir o campo DiffServ ECN para CE (11). Em vez de soltar o pacote (como acontece com a notificação de congestionamento do TCP), o dispositivo encaminha o pacote.

Nota:

Na fila de saída, o algoritmo WRED determina se um pacote é ou não elegível para quedas com base no nível de preenchimento da fila (quão cheia está a fila). Se um pacote for elegível para quedas e marcado como capaz de ECN, o pacote pode ser marcado como CE e encaminhado. Se um pacote for elegível para quedas e não for marcado como capaz de ECN, ele pode ser descartado. Consulte o controle de perfil de queda WRED dos limiares de ECN para obter mais informações sobre o algoritmo WRED.

Quando o pacote chega ao endpoint do receptor, a marca CE diz ao receptor que há congestionamento de rede. O receptor então envia (reverbera) uma mensagem ao remetente que indica que há congestionamento na rede. O remetente reconhece a mensagem de notificação de congestionamento e reduz sua taxa de transmissão. A Figura 1 resume como a ECN funciona para mitigar o congestionamento da rede:

Figura 1: Notificação explícita de Explicit Congestion Notification congestionamento

O comportamento de ECN de ponta a ponta inclui:

  1. O remetente e o receptor com capacidade de ECN negociam a capacidade de ECN durante o estabelecimento de sua conexão.

  2. Após uma negociação bem-sucedida da capacidade de ECN, o remetente com capacidade de ECN envia pacotes DE IP com o conjunto de campo ECT para o receptor.

    Nota:

    Você deve habilitar a ECN em todos os dispositivos intermediários no caminho entre o remetente e o receptor.

  3. Se o algoritmo WRED em uma fila de saída de dispositivo determinar que a fila está passando por congestionamento e o pacote for elegível para queda, o dispositivo pode marcar o pacote como "congestionamento experiente" (CE) para indicar ao receptor que há congestionamento na rede. Se o pacote já tiver sido marcado como CE (o congestionamento já foi vivenciado na saída de outro dispositivo), o dispositivo encaminha o pacote com CE marcado.

    Se não houver congestionamento na fila de saída, o dispositivo encaminha o pacote e não altera a marcação habilitada para ECT dos bits ECN, de modo que o pacote ainda esteja marcado como capaz de ECN, mas não como um congestionamento.

  4. O receptor recebe um pacote marcado como CE para indicar que o congestionamento foi vivenciado ao longo do caminho de congestionamento.

  5. O receptor ecoa (envia) um pacote de volta ao remetente com o bit ECE (bit 9) marcado no campo de bandeira do cabeçalho TCP. O bit ECE é o bit de bandeira de eco ECN, que notifica o remetente de que há congestionamento na rede.

  6. O remetente reduz a taxa de transmissão de dados e envia um pacote para o receptor com o bit CWR (bit 8) marcado no campo de bandeira do cabeçalho TCP. A bit CWR é a broca de bandeira reduzida da janela de congestionamento, que reconhece ao receptor que a notificação de congestionamento experiente foi recebida.

  7. Quando o receptor recebe a bandeira CWR, o receptor para de definir o bit ECE em respostas ao remetente.

A Tabela 2 resume o comportamento do tráfego em filas habilitadas para ECN.

Tabela 2: Comportamento de tráfego em filas habilitadas para ECN

Marcação de pacotes IP de entrada de bits ECN

Configuração da ECN na fila de saída

Ação se algoritmo WRED determinar que pacote é elegível para quedas

Marcação de pacotes de saída de bits ECN

Não-ECT (00)

Não importa

Deixar cair.

Sem bits ECN marcados

ECT (10 ou 01)

ECN desabilitada

Deixar cair

Queda de pacote — sem bits ECN marcados

ECT (10 ou 01)

Habilitada para ECN

Não solte. Marque pacotes como congestionamento (CE, bits 11).

ECT marcada por pacote (11) para indicar congestionamento

CE (11)

ECN desabilitada

Deixar cair

Queda de pacote — sem bits ECN marcados

CE (11)

Habilitada para ECN

Não solte. O pacote já está marcado como congestionamento, pacote de encaminhamento sem alterar a marcação da ECN.

ECT marcada por pacote (11) para indicar congestionamento

Quando uma fila de saída não está enfrentando congestionamento conforme definido pelo perfil de queda wred mapeado para a fila, todos os pacotes são encaminhados e nenhum pacote é descartado.

ECN em comparação com PFC e Ethernet PAUSE

A ECN é um mecanismo de notificação de congestionamento de rede de ponta a ponta para tráfego IP. O controle de fluxo baseado em prioridade (PFC) (IEEE 802.1Qbb) e o Ethernet PAUSE (IEEE 802.3X) são diferentes tipos de mecanismos de gerenciamento de congestionamento.

A ECN exige que uma fila de saída também deve ter um perfil de queda de pacote WRED associado. As filas de saída usadas para tráfego no qual o PFC está habilitado não devem ter um perfil de queda WRED associado. As interfaces nas quais a Ethernet PAUSE está habilitada não devem ter um perfil de queda WRED associado.

O PFC é um mecanismo de controle de fluxo peer-to-peer para oferecer suporte a tráfego sem perdas. O PFC permite que dispositivos peer conectados interditem a transmissão de fluxo durante períodos de congestionamento. O PFC permite que você interdite o tráfego em um tipo de fluxo especificado em um link, em vez de todo o tráfego em um link. Por exemplo, você pode (e deve) habilitar o PFC em classes de tráfego sem perdas, como a fcoe classe de encaminhamento. O Ethernet PAUSE também é um mecanismo de controle de fluxo peer-to-peer, mas em vez de pausar apenas fluxos de tráfego especificados, o Ethernet PAUSE interrompe todo o tráfego em um link físico.

Com o PFC e a Ethernet PAUSE, os endpoints de envio e recebimento de um fluxo não comunicam informações de congestionamento entre si em todos os dispositivos intermediários. Em vez disso, o PFC controla fluxos entre dois dispositivos peer habilitados para PFC (por exemplo, dispositivos) que oferecem suporte aos padrões de ponte de data center (DCB). O PFC funciona enviando uma mensagem de pausa para o peer conectado quando a fila de saída de fluxo fica congestionada. A Ethernet PAUSE simplesmente interrompe todo o tráfego em um link durante períodos de congestionamento e não requer DCB.

O PFC funciona assim: se uma fila de saída de dispositivo for preenchido a um determinado limite, o dispositivo envia uma mensagem de pausa de PFC para o dispositivo peer conectado que está transmitindo dados. A mensagem de pausa diz ao dispositivo transmissor para interromper a transmissão do fluxo. Quando o congestionamento se dissipa, o dispositivo envia outra mensagem de PFC para dizer ao peer conectado para retomar a transmissão. (Se a fila de saída do dispositivo emissor também atingir um determinado limite, esse dispositivo pode, por sua vez, enviar uma mensagem de pausa de PFC para o peer conectado que está transmitindo a ele. Dessa forma, o PFC pode propagar uma pausa de transmissão de volta pela rede.)

Consulte Understanding CoS Flow Control (Ethernet PAUSE e PFC) para obter mais informações. Você também pode consultar a compreensão da funcionalidade PFC em interfaces de camada 3.

Controle de perfil de queda WRED dos limiares de ECN

Você aplica perfis de queda WRED em aulas de encaminhamento (que são mapeadas em filas de saída) para controlar como o dispositivo marca pacotes com capacidade de ECN. Um mapa de agendador associa um perfil de queda com um agendador e uma aula de encaminhamento, e então você aplica o mapa do agendador em interfaces para implementar as propriedades de agendamento para a classe de encaminhamento nessas interfaces.

Os perfis de queda definem o nível de preenchimento da fila (a porcentagem de plenitude da fila) e a probabilidade de queda (a probabilidade de queda de um pacote) em pares. Quando uma fila se preenche a um nível especificado, o tráfego que corresponde ao perfil de queda tem a probabilidade de queda pareada com esse nível de preenchimento. Ao configurar um perfil de queda, você configura pares de níveis de preenchimento e probabilidades de queda para controlar como os pacotes caem em diferentes níveis de plenitude da fila.

O primeiro par de probabilidade de preenchimento e queda é o ponto de partida de queda. Até que a fila atinja o primeiro nível de preenchimento, os pacotes não são descartados. Quando a fila chega ao primeiro nível de preenchimento, os pacotes que excedem o nível de preenchimento têm uma probabilidade de queda que é igual à probabilidade de queda emparelhada com o nível de preenchimento.

O último par de probabilidade de preenchimento e queda é o ponto final de queda. Quando a fila chega ao último nível de preenchimento, todos os pacotes são descartados a menos que estejam configurados para ECN.

Nota:

Filas sem perdas (classe de encaminhamento configurada com o no-loss atributo de queda de pacote) e filas de prioridade rigorosas não usam perfis de queda. Filas sem perdas usam PFC para controlar o fluxo de tráfego. As filas de alta prioridade rigorosa recebem toda a largura de banda de porta que exigem até o limite máximo de largura de banda configurado.

Diferentes dispositivos oferecem suporte a diferentes quantidades de pares de probabilidade de nível de preenchimento/queda em perfis de queda.

Nota:

Não configure o último nível de preenchimento como 100%.

A configuração do perfil de queda afeta os pacotes ECN da seguinte forma:

  • Ponto de partida de queda — os pacotes com capacidade de ECN podem ser marcados como congestionamento experiente (CE).

  • Ponto final de queda — os pacotes com capacidade de ECN são sempre marcados como CE.

À medida que uma fila se enche do ponto de partida de queda até o ponto final de queda, a probabilidade de um pacote ECN ser marcado COMO CE é a mesma da probabilidade de que um pacote não-ECN seja descartado se você aplicar o perfil de queda ao tráfego de melhor esforço. Conforme a fila se enche, a probabilidade de um pacote ECN ser marcado ce aumenta, assim como a probabilidade de um pacote não-ECN ser descartado aumenta quando você aplica o perfil de queda ao tráfego de melhor esforço.

No ponto de saída, todos os pacotes ECN estão marcados como CE, mas os pacotes ECN não são descartados. Quando o nível de preenchimento da fila excede o ponto final de queda, todos os pacotes ECN são marcados como CE. Neste ponto, todos os pacotes não-ECN são descartados. Os pacotes ECN (e todos os outros pacotes) são descartados se a fila for completamente preenchido.

Para configurar um perfil de queda de pacote WRED e aplicá-lo a uma fila de saída (usando agendamento hierárquico em dispositivos que oferecem suporte a ETS):

  1. Configure um perfil de queda usando a declaração set class-of-service drop-profiles profile-name interpolate fill-level drop-start-point fill-level drop-end-point drop-probability 0 drop-probability percentage.

  2. Mapeie o perfil de queda para um agendador de filas usando a declaração set class-of-service schedulers scheduler-name drop-profile-map loss-priority (low | medium-high | high) protocol any drop-profile profile-name. O nome do perfil de queda é o nome do perfil WRED configurado na Etapa 1.

  3. Mapeie o agendador, que a Etapa 2 associa com o perfil de queda, até a fila de saída usando a declaração set class-of-service scheduler-maps map-name forwarding-class forwarding-class-name scheduler scheduler-name. A classe de encaminhamento identifica a fila de saída. As aulas de encaminhamento são mapeadas em filas de saída por padrão, e podem ser remamatadas em diferentes filas pela configuração explícita do usuário. O nome do agendador é o agendador configurado na Etapa 2.

  4. Associe o mapa do agendador com um perfil de controle de tráfego usando a declaração set class-of-service traffic-control-profiles tcp-name scheduler-map map-name. O nome do mapa do agendador é o nome configurado na Etapa 3.

  5. Associe o perfil de controle de tráfego com uma interface usando a declaração set class-of-service interface interface-name forwarding-class-set forwarding-class-set-name output-traffic-control-profile tcp-name. O nome do perfil de controle de tráfego de saída é o nome do perfil de controle de tráfego configurado na Etapa 4.

    A interface usa o mapa do agendador no perfil de controle de tráfego para aplicar o perfil de queda (e outros atributos, incluindo o atributo Enable ECN) à fila de saída (classe de encaminhamento) nessa interface. Como você pode usar diferentes perfis de controle de tráfego para mapear diferentes agendadores para diferentes interfaces, o mesmo número de fila em diferentes interfaces pode lidar com o tráfego de maneiras diferentes.

Você pode configurar um perfil de queda de pacote WRED e aplicá-lo a uma fila de saída em dispositivos que oferecem suporte à agendamento de portas (a agendamento hierárquico do ETS não é suportado ou não é usado). Para configurar um perfil de queda de pacote WRED e aplicá-lo a uma fila de saída em dispositivos que oferecem suporte à agendamento de portas (a agendamento hierárquico do ETS não é suportado ou não é usado):

  1. Configure um perfil de queda usando a declaração set class-of-service drop-profiles profile-name interpolate fill-level level1 level2 ... level32 drop-probability probability1 probability2 ... probability32. Você pode especificar apenas dois pares de probabilidade de nível de preenchimento/queda ou até 32 pares.

  2. Mapeie o perfil de queda para um agendador de filas usando a declaração set class-of-service schedulers scheduler-name drop-profile-map loss-priority (low | medium-high | high) drop-profile profile-name. O nome do perfil de queda é o nome do perfil WRED configurado na Etapa 1.

  3. Mapeie o agendador, que a Etapa 2 associa com o perfil de queda, até a fila de saída usando a declaração set class-of-service scheduler-maps map-name forwarding-class forwarding-class-name scheduler scheduler-name. A classe de encaminhamento identifica a fila de saída. As aulas de encaminhamento são mapeadas em filas de saída por padrão, e podem ser remamatadas em diferentes filas pela configuração explícita do usuário. O nome do agendador é o agendador configurado na Etapa 2.

  4. Associe o mapa do agendador com uma interface usando a declaração set class-of-service interfaces interface-name scheduler-map scheduler-map-name.

    A interface usa o mapa do agendador para aplicar o perfil de queda (e outros atributos) na fila de saída mapeada para a classe de encaminhamento nessa interface. Como você pode usar diferentes mapas de agendador em diferentes interfaces, o mesmo número de fila em diferentes interfaces pode lidar com o tráfego de maneiras diferentes.

ECN dinâmica

A ECN dinâmica melhora o conjunto de recursos ECN, fornecendo uma maneira de automatizar os limites que desencadeiam um evento de notificação de congestionamento. O Junos OS Evolved monitora condições em tempo real, como comprimento da fila e padrões de tráfego para avaliar se um limite deve ou não ser ajustado. Isso resulta em uma resposta mais rápida a eventos de congestionamento do que a ECN estática, e melhora a eficiência do controle de congestionamento.

A D-ECN é mais difícil de implementar do que a ECN estática, e requer monitoramento ativo. Você deve avaliar suas condições e configuração de rede para decidir se a D-ECN é a melhor opção para sua rede.

Você pode verificar o Feature Explorer para ver se seu dispositivo oferece suporte a D-ECN.

Suporte, limitações e notas

Se o algoritmo WRED mapeado em uma fila não encontrar uma queda de pacote elegível, então a configuração ECN e a marcação de bits ECN não importam. O comportamento do transporte de pacotes é o mesmo de quando a ECN não está habilitada.

A ECN é desativada por padrão. Normalmente, você habilita a ECN apenas em filas que lidam com o tráfego de melhor esforço, e você não habilita a ECN em filas que lidam com tráfego sem perdas ou tráfego de alta prioridade rigorosa.

A ECN oferece suporte ao seguinte:

  • Pacotes IPv4 e IPv6

  • Pacotes não registrados, com marca única e com tag dupla

  • O cabeçalho IP externo de pacotes com túnel IP (mas não o cabeçalho IP interno)

A ECN não oferece suporte aos seguintes:

  • Pacotes IP com encapsulamento MPLS

  • O cabeçalho IP interno de pacotes com túnel IP (no entanto, a ECN funciona no cabeçalho IP externo)

  • Tráfego multicast, broadcast e de busca de destino (DLF)

  • Tráfego não IP

Nota:

Para aplicar um perfil de queda WRED ao tráfego não ECT, configure um classificador multicampo (MF) para atribuir tráfego não ECT a uma fila de saída diferente que não está habilitada para ECN e, em seguida, aplique o perfil de queda WRED nessa fila.

Comportamento específico da plataforma

Use o Feature Explorer para confirmar o suporte de plataforma e versão para a ECN.

Use a tabela a seguir para revisar comportamentos específicos da plataforma para este recurso.

Plataforma

Diferença

PTX10001-36MR, PTX10004, PTX10008, PTX10016

Você pode implementar ECN de baixo limite (inicie a marcação de ECN assim que o buffer começar a preencher) definindo uma taxa de buffer para um agendador e um perfil de queda de porcentagem baixo.

A taxa de buffer funciona como a taxa base para cálculo do tamanho do buffer. A taxa de buffer é a taxa-alvo de um VOQ, que é a taxa de fila de saída pretendida durante o congestionamento típico. Definir o buffer-rate nível de [edit class-of-service schedulers scheduler-name] hierarquia.

Você também pode definir porcentagens mais granulares (para os décimos de um por cento) e menores percentuais de nível de preenchimento para perfis de queda. Ou seja, você pode definir um nível de preenchimento tão baixo quanto 0,7%.

Nota:

Os roteadores PTX oferecem suporte apenas à Static ECN.

Série QFX5000

Nas plataformas QFX5K, a funcionalidade ECN é fortemente integrada com limites WRED. Os limiares WRED são estáticos, por isso a ECN também funciona com base em cálculos estáticos de limiares de buffer. No entanto, o uso real de buffer compartilhado de filas é dinâmico. A seguir, as fórmulas usadas para cálculos limiares de marcação de ECN no momento da configuração da ECN.

  • max buffer access eligibility for ECN enabled queue = (( shared pool size * hardware_alpha)/(1 + hardware_alpha)) + egress queue dedicated buffer

  • ECN marking start threshold = WRED start fill level percent * Max buffer access eligibility for ECN enabled queue

  • ECN 100% marking threshold = WRED end fill level percent * Max buffer access eligibility for ECN enabled queue

Durante o congestionamento para pacotes compatíveis com ECN, a marcação ECN CE começa após ECN marking start threshold ser alcançada. Os pacotes capazes de ECN são marcados probabilistamente como ECN CE até ECN 100% marking threshold que seja alcançado. Após esse limite, todos os pacotes capazes de ECN são marcados como ECN CE até que a fila chegue max buffer access eligibility for ECN enabled queue. Após esse limiar, ocorrem quedas de cauda.

No cálculo acima, max buffer access eligibility for ECN enabled queueassume-se o melhor cenário de uma única fila competindo por espaço buffer compartilhado. No entanto, o uso real de buffer compartilhado para uma fila congestionada pode diminuir dinamicamente com base no número de filas concorrentes para o buffer compartilhado a qualquer momento. A seguir está a fórmula para calcular o actual dynamic max buffer usage per queue.

  • actual max buffer usage for ECN enabled queue = (shared pool size * hw_alpha) / (1 + (hw_alpha * number of competing queues)) + egress queue dedicated buffer + ingress Pg dedicated buffer by the traffic flow

Dois parâmetros eingress Pg dedicated buffer by the traffic flow, usados no actual dynamic max buffer usage per queue cálculo, não podem ser considerados ao calcular o limiar de ECN, number of competing queues pois ambos esses parâmetros são dinâmicos de natureza. Isso cria uma possibilidade de que o uso de buffer máximo real para uma fila habilitada por ECN possa estar abaixo dos limiares de marcação estáticos calculados da ECN.

Portanto, com certas configurações compartilhadas de buffer e nível de preenchimento WRED, existe a possibilidade de quedas na cauda de pacotes devido ao esgotamento do buffer compartilhado que ocorre mesmo antes da marcação da ECN em filas de perda habilitadas para ECN. Para filas sem perdas, devido à limitação acima, o PFC pode começar de uma porta de entrada antes da marcação de ECN, já que o limiar PFC XOFF é dinâmico, ao contrário do limiar estático de ECN. Você pode determinar os limiares de marcação de ECN adequados monitorando o uso máximo de buffer de filas congestionadas e ajustando os limiares ECN/WRED de acordo.

Série QFX10000

  • Em QFX10000 switches, quando você habilita uma fila para ECN e aplica um perfil de queda WRED na fila, o perfil de queda do WRED define apenas os limites para marcar o tráfego ECN como congestionamento (CE, 11). Em filas habilitadas para ECN, o perfil de queda do WRED não define limites de queda para tráfego não ECT (00) (tráfego que não é capaz de ECN). Em vez disso, o switch usa o algoritmo de queda de cauda no tráfego é marcado como não-ECT em filas habilitadas para ECN durante períodos de congestionamento.

external-footer-nav