Notificação explícita de congestionamento - Explicit Congestion Notification

Suíte de protocolo de Internet
Camada de aplicação
Camada de transporte
Camada de Internet
Camada de link

Notificação explícita de congestionamento ( ECN ) é uma extensão do protocolo da Internet e do protocolo de controle de transmissão e é definida na RFC 3168 (2001). ECN permite notificação ponta a ponta de congestionamento de rede sem perder pacotes. ECN é um recurso opcional que pode ser usado entre dois pontos de extremidade habilitados para ECN quando a infraestrutura de rede subjacente também oferece suporte.

Convencionalmente, as redes TCP / IP sinalizam congestionamento eliminando pacotes. Quando o ECN é negociado com êxito, um roteador que reconhece o ECN pode definir uma marca no cabeçalho IP em vez de descartar um pacote para sinalizar um congestionamento iminente. O receptor do pacote ecoa a indicação de congestionamento para o remetente, o que reduz sua taxa de transmissão como se tivesse detectado um pacote descartado.

Em vez de responder adequadamente ou ignorar os bits, algum equipamento de rede desatualizado ou defeituoso tem historicamente descartado ou mutilado pacotes com bits ECN configurados. Em 2015, as medições sugeriram que a fração de servidores web na Internet pública para a qual a configuração de ECN impede conexões de rede foi reduzida para menos de 1%.

O suporte passivo existe no Ubuntu Linux desde 12.04 e no Windows Server desde 2012. O suporte passivo nos sites mais populares aumentou de 8,5% em 2012 para mais de 70% em maio de 2017. A adoção pela Internet agora exige que os clientes solicitem ativamente ECN. Em junho de 2015, a Apple anunciou que o ECN será habilitado por padrão em seus produtos com suporte e futuros, para ajudar a impulsionar a adoção da sinalização ECN em todo o setor.

Operação

ECN requer suporte específico na camada de Internet e na camada de transporte pelos seguintes motivos:

  • No TCP / IP, os roteadores operam na camada da Internet, enquanto a taxa de transmissão é controlada pelos terminais na camada de transporte.
  • O congestionamento pode ser tratado apenas pelo transmissor, mas como se sabe que ocorreu apenas depois que um pacote foi enviado, deve haver um eco da indicação de congestionamento do receptor para o transmissor.

Sem ECN, o eco de indicação de congestionamento é obtido indiretamente pela detecção de pacotes perdidos. Com ECN, o congestionamento é indicado definindo o campo ECN dentro de um pacote IP para CE e é ecoado de volta pelo receptor para o transmissor, definindo os bits apropriados no cabeçalho do protocolo de transporte. Por exemplo, ao usar TCP, a indicação de congestionamento é ecoada pela definição do bit ECE.

Operação de ECN com IP

ECN usa os dois bits menos significativos (mais à direita) do campo Classe de tráfego no cabeçalho IPv4 ou IPv6 para codificar quatro pontos de código diferentes:

  • 00 - Transporte não compatível com ECN, sem ECT
  • 10 - Transporte capaz de ECN, ECT (0)
  • 01 - Transporte capaz de ECN, ECT (1)
  • 11 - Congestionamento encontrado, CE.

Quando ambos os terminais suportam ECN, eles marcam seus pacotes com ECT (0) ou ECT (1). Os roteadores tratam os pontos de código ECT (0) e ECT (1) como equivalentes. Se o pacote atravessa uma fila de gerenciamento de fila ativa (AQM) (por exemplo, uma fila que usa detecção precoce aleatória (RED)) que está enfrentando congestionamento e o roteador correspondente suporta ECN, ele pode alterar o ponto de código para em CEvez de descartar o pacote . Este ato é conhecido como “marcação” e seu objetivo é informar o ponto de extremidade de recebimento de congestionamento iminente . No ponto final de recepção, essa indicação de congestionamento é tratada pelo protocolo da camada superior (protocolo da camada de transporte ) e precisa ser ecoada de volta para o nó transmissor para sinalizá-lo para reduzir sua taxa de transmissão.

Como a indicação de CE só pode ser tratada de forma eficaz por um protocolo de camada superior que a suporta, ECN é usado apenas em conjunto com protocolos de camada superior, como TCP , que oferecem suporte ao controle de congestionamento e têm um método para ecoar a indicação de CE para o terminal de transmissão .

Operação de ECN com TCP

O TCP oferece suporte a ECN usando dois sinalizadores no cabeçalho TCP. O primeiro, ECN-Echo (ECE), é usado para ecoar a indicação de congestionamento (ou seja, sinalizar ao remetente para reduzir a taxa de transmissão). O segundo, Congestion Window Reduced (CWR), para reconhecer que o eco de indicação de congestionamento foi recebido. O uso de ECN em uma conexão TCP é opcional; para que o ECN seja usado, ele deve ser negociado no estabelecimento da conexão, incluindo opções adequadas nos segmentos SYN e SYN-ACK.

Quando ECN foi negociado em uma conexão TCP, o remetente indica que os pacotes IP que transportam segmentos TCP dessa conexão estão transportando tráfego de um transporte capaz de ECN, marcando-os com um ponto de código ECT. Isso permite que os roteadores intermediários que suportam ECN marquem esses pacotes IP com o ponto de código CE em vez de descartá-los para sinalizar um congestionamento iminente.

Ao receber um pacote IP com o ponto de código com experiência em congestionamento , o receptor TCP ecoa essa indicação de congestionamento usando o sinalizador ECE no cabeçalho TCP. Quando um ponto de extremidade recebe um segmento TCP com o bit ECE, ele reduz sua janela de congestionamento como para uma queda de pacote. Em seguida, ele reconhece a indicação de congestionamento, enviando um segmento com o conjunto de bits CWR.

Um nó continua transmitindo segmentos TCP com o conjunto de bits ECE até receber um segmento com o conjunto de bits CWR.

Para ver os pacotes afetados com tcpdump , use o predicado de filtro (tcp[13] & 0xc0 != 0).

Pacotes de controle ECN e TCP

Como o Transmission Control Protocol (TCP) não executa o controle de congestionamento nos pacotes de controle (segmentos ACKs, SYN, FIN puros), os pacotes de controle geralmente não são marcados como capazes de ECN.

Uma proposta de 2009 sugere a marcação de pacotes SYN-ACK como capazes de ECN. Esta melhoria, conhecida como ECN +, demonstrou fornecer melhorias dramáticas no desempenho de conexões TCP de curta duração.

Operação de ECN com outros protocolos de transporte

ECN também é definido para outros protocolos de camada de transporte que realizam controle de congestionamento, notavelmente DCCP e Stream Control Transmission Protocol (SCTP). O princípio geral é semelhante ao TCP, embora os detalhes da codificação durante a transmissão sejam diferentes.

É possível usar ECN com protocolos em camadas acima do UDP . No entanto, o UDP requer que o controle de congestionamento seja executado pelo aplicativo, e os primeiros protocolos baseados em UDP, como o DNS , não usavam ECN. Protocolos baseados em UDP mais recentes, como o QUIC, estão usando ECN para controle de congestionamento.

Efeitos no desempenho

Uma vez que o ECN só é eficaz em combinação com uma política Active Queue Management (AQM), os benefícios do ECN dependem do AQM preciso que está sendo usado. Algumas observações, no entanto, parecem valer para diferentes AQMs.

Como esperado, o ECN reduz o número de pacotes perdidos por uma conexão TCP, o que, ao evitar uma retransmissão, reduz a latência e principalmente o jitter. Este efeito é mais drástico quando a conexão TCP tem um único segmento pendente, quando é capaz de evitar um tempo limite de RTO ; esse costuma ser o caso de conexões interativas, como logins remotos e protocolos transacionais, como solicitações HTTP, a fase de conversação de SMTP ou solicitações SQL.

Os efeitos do ECN no throughput em massa são menos claros porque as implementações de TCP modernas são bastante boas no reenvio de segmentos descartados em tempo hábil quando a janela do remetente é grande.

Descobriu-se que o uso de ECN é prejudicial ao desempenho em redes altamente congestionadas ao usar algoritmos AQM que nunca descartam pacotes. As implementações modernas de AQM evitam essa armadilha descartando em vez de marcar os pacotes com carga muito alta.

Implementações

Muitas implementações modernas do conjunto de protocolos TCP / IP têm algum suporte para ECN; no entanto, eles geralmente são fornecidos com o ECN desativado.

Suporte ECN em TCP por hosts

Microsoft Windows

As versões do Windows desde o Windows Server 2008 e o Windows Vista oferecem suporte a ECN para TCP. Desde o Windows Server 2012, ele é habilitado por padrão nas versões do Windows Server, porque o Data Center Transmission Control Protocol (DCTCP) é usado. Em versões anteriores do Windows e versões sem servidor, ele é desabilitado por padrão.

O suporte ECN pode ser habilitado usando um comando shell, como netsh interface tcp set global ecncapability = enabled .

BSD

No FreeBSD , ECN para TCP pode ser configurado usando net.inet.tcp.ecn.enable sysctl . Por padrão, ele está habilitado apenas para conexões de entrada que o solicitem. Ele também pode ser ativado para todas as conexões ou totalmente desativado.

NetBSD  4.0 implementa suporte ECN para TCP; ele pode ser ativado por meio da interface sysctl definindo 1 como valor para o parâmetro sysctl net.inet.tcp.ecn.enable .

Da mesma forma, o sysctl net.inet.tcp.ecn pode ser usado no OpenBSD .

Linux

Desde a versão 2.4.20 do kernel do Linux , lançado em novembro de 2002, o Linux suporta três modos de trabalho do ECN para TCP, conforme configurado por meio da interface sysctl , definindo o parâmetro / proc / sys / net / ipv4 / tcp_ecn para um dos seguintes valores:

  • 0  - desativa ECN e não o inicia nem aceita
  • 1  - habilitar ECN quando solicitado por conexões de entrada, e também solicitar ECN em tentativas de conexão de saída
  • 2  - (padrão) ativa ECN quando solicitado por conexões de entrada, mas não solicita ECN em conexões de saída

Começando com a versão 4.1 do kernel Linux, lançado em junho de 2015, o mecanismo tcp_ecn_fallback , conforme especificado na RFC 3168 seção 6.1.1.1, é habilitado por padrão quando ECN está habilitado (o valor de 1). O mecanismo de fallback tenta a conectividade ECN na configuração inicial de conexões de saída, com um fallback elegante para transmissões sem capacidade ECN, atenuando problemas com hosts ou firewalls intolerantes a ECN.

Mac OS X

Mac OS X 10.5 e 10.6 implementam suporte ECN para TCP. É controlado usando as variáveis booleanas sysctl net.inet.tcp.ecn_negotiate_in e net.inet.tcp.ecn_initiate_out . A primeira variável habilita ECN em conexões de entrada que já têm sinalizadores ECN definidos; o segundo tenta iniciar conexões de saída com ECN habilitado. Ambas as variáveis ​​são padronizadas para 0 , mas podem ser definidas como 1 para habilitar o respectivo comportamento.

Em junho de 2015, a Apple Inc. anunciou que o OS X 10.11 teria o ECN ativado por padrão, mas o sistema operacional foi lançado sem esse comportamento padrão. No macOS Sierra, o ECN é habilitado para metade das sessões TCP.

iOS

Em junho de 2015, a Apple Inc. anunciou que o iOS 9 , sua próxima versão do iOS, suportaria ECN e o ativaria por padrão. A negociação TCP ECN está habilitada em 5% das conexões selecionadas aleatoriamente por Wi-Fi / Ethernet no iOS 9 e 50% das conexões selecionadas aleatoriamente por Wi-Fi / Ethernet e algumas operadoras de celular no iOS 10 e 100% no iOS 11

Solaris

O kernel Solaris oferece suporte a três estados de ECN para TCP:

  • nunca  - sem ECN
  • ativo  - usar ECN
  • passivo  - anuncia o suporte ECN apenas quando solicitado.

O comportamento padrão é passivo . A partir do Solaris 11, o uso ECN completo pode ser ativado via ipadm set-prop -p ecn = active tcp .

Suporte ECN em IP por roteadores

Como a marcação ECN em roteadores depende de alguma forma de gerenciamento de fila ativa , os roteadores devem ser configurados com uma disciplina de fila adequada para realizar a marcação ECN.

Os roteadores Cisco IOS executam a marcação ECN se configurados com a disciplina de enfileiramento WRED desde a versão 12.2 (8) T.

Routers Linux executar ECN marcação se configurado com uma das VERMELHOS disciplinas de fila ou GRED com um explícito ecn parâmetro, usando o SFB disciplina, usando o CODEL disciplina Feira filas (fq_codel), ou a disciplina BOLO filas.

Implementações BSD modernas, como FreeBSD , NetBSD e OpenBSD , têm suporte para marcação ECN na implementação de enfileiramento ALTQ para uma série de disciplinas de enfileiramento , notavelmente RED e Blue . O FreeBSD 11 incluiu a implementação de disciplinas de enfileiramento CoDel , PIE, FQ-CoDel e FQ-PIE no framework ipfw / dummynet com capacidade de marcação ECN.

Data Center TCP

O protocolo de controle de transmissão do data center ( Data Center TCP ou DCTCP ) utiliza ECN para aprimorar o algoritmo de controle de congestionamento do protocolo de controle de transmissão . É usado em redes de data center . Enquanto o algoritmo de controle de congestionamento TCP padrão só é capaz de detectar a presença de congestionamento, o DCTCP, usando ECN, é capaz de medir a extensão do congestionamento.

O DCTCP modifica o receptor TCP para sempre retransmitir a marcação ECN exata dos pacotes de entrada ao custo de ignorar uma função que visa preservar a confiabilidade da sinalização. Isso torna um remetente DCTCP vulnerável à perda de ACKs do receptor, que ele não tem mecanismo para detectar ou lidar com isso. Em julho de 2014, algoritmos que fornecem feedback de receptor equivalente ou melhor em uma abordagem mais confiável são um tópico de pesquisa ativo.

Veja também

Referências

links externos