Serviço de Internet L4S para baixa latência, baixa perda e throughput escalável: RFC 9330
(datatracker.ietf.org)- A RFC 9330 define a arquitetura L4S para reduzir o atraso de enfileiramento e as perdas por congestionamento em aplicações de Internet, e identifica a causa fundamental da latência mais no controle de congestionamento exploratório de capacidade do emissor do que na fila em si
- O L4S combina controle de congestionamento escalável no host emissor, AQM no gargalo da rede e protocolos baseados em ECN, usando o codepoint ECT(1) no campo IP-ECN para identificar pacotes L4S
- O objetivo de atraso de enfileiramento é média abaixo de 1 ms e percentil 99 abaixo de cerca de 2 ms; em exemplos com DCTCP e Dual-Queue Coupled AQM, o atraso de enfileiramento no percentil 99 fica em torno de 1 a 2 ms mesmo sob sobrecarga
- Para coexistir com o controle de congestionamento Classic da família Reno/CUBIC, o L4S separa a latência do tráfego Classic e do tráfego L4S, mas foi projetado para compartilhar a largura de banda no longo prazo, sem divisão fixa
- O L4S complementa, em vez de substituir, Diffserv, FQ-CoDel, PIE e BBR; no TCP, é necessário feedback mais preciso como o AccECN, enquanto QUIC e DCCP já oferecem o feedback ECN necessário para L4S
O problema de latência que o L4S busca resolver
- Situações em que tráfego que prefere baixa latência — como web, voz, videoconferência, jogos, desktop remoto, aplicações em nuvem, AR/VR e controle remoto — preenche links de gargalo estão se tornando mais comuns
- Embora caches e servidores mais próximos do usuário tenham reduzido a latência de propagação, o enfileiramento continua sendo um componente importante e intermitente da latência
- Mesmo com AQM moderno, picos de latência de centenas de ms não são raros
- O AQM Classic costuma ser configurado para amortecer a variação em dente de serra da fila de um único fluxo de longa duração, de modo que, durante esses fluxos, o pico de latência de rede total pode chegar a cerca de duas vezes a latência básica do caminho
- O objetivo do L4S é atraso de enfileiramento muito baixo, perda muito baixa e throughput escalável
- Atraso de enfileiramento muito baixo significa média abaixo de 1 ms e percentil 99 abaixo de cerca de 2 ms
- Aplicações interativas mais exigentes começam a parecer artificiais quando a latência fim a fim ultrapassa 50 ms ou 20 ms
- Como perda leva a atraso de retransmissão em aplicações interativas, baixa perda também é um objetivo central
A causa da latência: controle de congestionamento Classic, não a fila
- O L4S identifica a causa fundamental do atraso de enfileiramento mais no controle de congestionamento exploratório de capacidade do emissor do que na fila em si
- Controles de congestionamento Classic como Reno e CUBIC fazem a ocupação da fila variar em grandes padrões de dente de serra
- Se o AQM mantiver a fila rasa demais, o controle de congestionamento Classic pode não utilizar bem o link nos vales do dente de serra
- À medida que a taxa do fluxo aumenta, o tempo de recuperação do controle Classic cresce, deixando mais frouxo o controle da fila e da utilização
- O controle de congestionamento escalável mantém constante o tempo médio entre sinais de congestionamento — isto é, o tempo de recuperação — mesmo quando a taxa do fluxo cresce
- O DCTCP é um exemplo amplamente usado em ambientes controlados
- Já foi implementado e distribuído em Windows Server Editions, Linux e FreeBSD
- Prague sobre TCP/QUIC, SCReAM para L4S e a parte de ECN L4S do BBRv2 também entram como exemplos de controle de congestionamento escalável
Os três componentes da arquitetura L4S
- O L4S é composto por três elementos
- Controle de congestionamento escalável no host emissor
- AQM no gargalo da rede
- Protocolos baseados em ECN para identificação de pacotes e sinalização de congestionamento entre os dois
- A baixa latência não é fornecida diretamente pela rede, mas pelo comportamento cuidadoso do controle de congestionamento escalável do emissor L4S
- O papel principal da rede é isolar a baixa latência do tráfego L4S do atraso de enfileiramento maior exigido pelo tráfego Classic
- A rede usa ECN para avisar imediatamente a camada de transporte dos primeiros sinais de crescimento da fila
- Não espera amortecer fortemente a variação da fila antes de sinalizar, como no AQM Classic
- Suporte a ECN é essencial para L4S
- O emissor usa o campo ECN para permitir que a rede diferencie pacotes L4S de pacotes Classic
ECN e o codepoint ECT(1)
- O L4S precisa de sinalização de congestionamento mais refinada do que a do ECN Classic, que impõe a restrição de “tratar sinal ECN como equivalente a drop”
- O sinal precisa poder ocorrer com mais frequência
- Precisa poder ser emitido imediatamente, sem grande atraso para amortecer a variação da fila
- RFC8311 relaxa alguns requisitos da RFC3168, permitindo experimentos com L4S
- A RFC9331 especifica o uso de ECT(1) como identificador de pacotes L4S
- O codepoint CE é usado para indicar Congestion Experienced tanto no tratamento L4S quanto no Classic
- Se um AQM Classic no início do caminho marcar pacotes ECT(0) com CE, existe risco de classificação incorreta para a fila L4S
- Segundo o Apêndice B da RFC9331, para haver efeito prejudicial é preciso que cinco condições raras ocorram ao mesmo tempo, e mesmo assim a chance de retransmissão incorreta é extremamente pequena
- Operadores podem querer colocar na fila L4S tráfego não L4S que seja tão baixo e estável que não forme fila
- Exemplos incluem VoIP, datagramas de baixa taxa para sincronização de jogos online, DNS e LDAP
- Nesse caso, é necessária uma marcação separada, como EF, NQB ou um identificador específico do operador
Dual-Queue Coupled AQM
- O L4S busca oferecer baixa latência sem exigir necessariamente tratamento por fluxo nos componentes da rede
- O desenho representativo, Dual-Queue Coupled AQM, usa duas filas
- A fila L4S mantém baixa latência
- A fila Classic pode ter uma fila maior, necessária para que o tráfego Classic mantenha a utilização do link
- O DualQ foi projetado para agir como uma membrana semipermeável: separa a latência, mas não divide a largura de banda de forma fixa
- O AQM Classic cria sua própria probabilidade de drop/marcação baseada no congestionamento da fila e a acopla à sinalização das filas Classic e L4S
- O sinal de congestionamento acoplado faz os fluxos L4S reduzirem a velocidade para deixar capacidade para os fluxos Classic
- O scheduler pode dar prioridade à fila L4S
- Em escalas curtas de tempo, remove rapidamente bursts L4S para proteger a baixa latência
- Em escalas mais longas do que o RTT, o acoplamento do sinal de congestionamento da fila Classic compensa a prioridade de largura de banda e produz uma justiça aproximada por fluxo
- Quando há apenas tráfego L4S, o AQM da fila L4S começa a marcar congestionamento com uma fila muito rasa, preservando atraso de enfileiramento baixo
Diferença entre filas por fluxo e DualQ
- Filas por fluxo como FQ-CoDel e FQ-PIE também podem ser usadas com L4S
- No Linux, elas foram modificadas para aplicar limiares rasos de marcação ECN apenas a pacotes ECT(1)
- Fluxos Not-ECT ou ECT(0) recebem AQM Classic, enquanto fluxos ECT(1) recebem em geral um limiar raso abaixo de 1 ms
- A abordagem por fluxo separa as filas de cada fluxo, mas não elimina o enfileiramento criado pelo próprio fluxo
- A abordagem DualQ não exige inspeção além da camada IP, pois o identificador L4S está no campo IP-ECN
- Isso permite uso mesmo quando identificadores da camada de transporte estão criptografados, como em IPsec ou túneis VPN criptografados
- Na abordagem por fluxo, a rede passa a controlar a velocidade relativa entre fluxos de aplicação
- O DualQ separa o problema de oferecer baixa latência do problema de controlar a taxa dos fluxos, permitindo adicionar policiamento de taxa por fluxo separadamente, se necessário
Requisitos do lado do host
- O emissor deve implementar controle de congestionamento escalável
- DCTCP é o exemplo mais difundido, mas precisa de melhorias de segurança e desempenho para uso na Internet pública
- As partes dos requisitos Prague L4S relacionadas ao risco de causar dano a terceiros foram incorporadas como requisitos normativos na RFC9331
- O TCP Prague foi implementado no Linux como implementação de referência
- Protocolos de transporte além de TCP também precisam implementar resposta escalável a congestionamento e sinalizá-la com o codepoint ECT(1) para usar o serviço L4S
- Variantes escaláveis para QUIC estão em análise
- A parte de ECN L4S do BBRv2 é apresentada como controle de congestionamento escalável para TCP, QUIC e outros
- Uma variante L4S do SCReAM para mídia RTP também foi implementada
- O estado do feedback ECN varia conforme o protocolo
- DCCP e QUIC fornecem feedback ECN com granularidade suficiente para L4S
- O feedback ECN existente no TCP parte da premissa de que marcas ECN equivalem a drop, então não serve para TCP escalável
- Receptores TCP precisam suportar AccECN, um feedback ECN mais preciso
- O SCTP precisaria de implementação e implantação de um novo desenho ECN para suportar L4S
- Para RTP, o feedback ECN suficiente está definido nas RFC6679 e RFC8888
Por que é necessário sinal explícito de congestionamento
- O L4S usa sinal explícito de congestionamento como mecanismo central, em vez de perda
- Drops são ao mesmo tempo degradação de desempenho e sinalização, criando uma tensão entre “dano que deve ser minimizado” e “sinal que seria útil ocorrer com mais frequência”
- Sinalização explícita baseada em ECN pode ser usada várias vezes por RTT sem dano, o que ajuda a manter filas curtas
- O L4S transfere o amortecimento da rede para o host
- Como a rede não conhece o RTT de cada fluxo, na abordagem Classic ela precisa assumir o pior RTT
- Por isso, o sinal Classic de congestionamento pode atrasar de 100 a 200 ms
- Cada host conhece seu próprio RTT e, portanto, pode amortecer só o necessário, normalmente na ordem de alguns ms
- A fila L4S usa uma nova variante de ECN L4S que não é equivalente a drop, enquanto a fila Classic usa ECN Classic ou drop
Base da escalabilidade de throughput
- O controle de congestionamento Reno Classic tem tempo de recuperação cada vez maior em ambientes com alto produto banda-latência
- O exemplo considera RTT máximo de 30 ms no pico do dente de serra
- Se a taxa de pacotes do Reno sobe 8 vezes, de 1.250 packet/s para 10.000 packet/s, isso equivale a cerca de 15 Mb/s para 120 Mb/s com pacotes de 1500 B, e o tempo de recuperação cresce de 422 ms para 3,38 s
- O CUBIC, a 120 Mb/s, opera em modo Reno-friendly e leva cerca de 4,3 s para recuperar
- A 960 Mb/s, entra no modo true CUBIC e o tempo de recuperação vai para 12,2 s
- A 7,68 Gb/s, o tempo de recuperação chega a 24,3 s
- Controles de congestionamento escaláveis como DCTCP e Prague induzem em média 2 sinais de congestionamento por RTT, e essa característica se mantém independentemente da taxa do fluxo
- Em 2020, a capacidade média global de acesso fixo era de 103 Mb/s, e em 2019 o RTT básico médio até CDNs era de 25 a 34 ms
- Um único fluxo de download CUBIC pode precisar, no melhor caso, de cerca de 200 RTTs — ou seja, 5 s — para se recuperar após uma redução da janela de congestionamento
Relação com tecnologias existentes
- O Diffserv trata da alocação de largura de banda para tráfego importante e do atraso de enfileiramento para tráfego sensível à latência, enquanto o L4S trata apenas do problema de atraso de enfileiramento
- O Diffserv funciona bem quando apenas parte do tráfego no gargalo exige baixa latência
- Se todo o tráfego no gargalo quiser baixa latência, a vantagem da diferenciação do Diffserv desaparece
- O identificador L4S não representa exigência de qualidade, mas um compromisso comportamental de resposta escalável a congestionamento
- AQMs Classic como PIE e FQ-CoDel reduzem bastante o atraso de enfileiramento em comparação com não usar AQM
- O L4S os complementa e não substitui a necessidade de ampla implantação deles
- Só o AQM tem dificuldade para eliminar a tensão entre latência e utilização do link por causa do grande dente de serra do controle de congestionamento Classic
- O ABE muda a reação do host à marcação ECN para aumentar a utilização do link e o throughput de fluxos ECN, mas ainda assume que a rede trata ECN e drop da mesma forma
- O BBR controla o atraso de enfileiramento ponta a ponta sem lógica especial na rede
- O BBR mantém o atraso de enfileiramento em nível razoavelmente baixo, mas não tão baixo quanto o L4S
- O BBRv2 pode usar ECN L4S e comportamento escalável de congestionamento L4S quando possível
Aplicações possíveis
- O L4S pode melhorar bastante a qualidade de aplicações existentes sob carga
- Jogos e cloud gaming
- VoIP
- Videoconferência
- Navegação web
- Streaming de vídeo adaptativo
- Mensageria instantânea
- Atraso de enfileiramento menor também viabiliza recursos como vídeo interativo baseado em nuvem e VR/AR baseado em nuvem
- Em uma demonstração de L4S, vídeo interativo em nuvem e VR funcionaram juntos em um link de acesso banda larga de 40 Mb/s, compartilhando o mesmo gargalo com vários aplicativos sensíveis à latência e downloads
- Com latência básica fim a fim de 7 ms, o atraso adicional de enfileiramento ficou em cerca de 1 ms
- Com AQM alternativo, o vídeo ficava visivelmente atrasado em relação a gestos dos dedos e movimentos da cabeça
- Fazer pan do vídeo com swipe do dedo ou movimento da cabeça tem exigências de latência muito mais rígidas do que VoIP
- Presença remota interativa e controle remoto assistido por vídeo de máquinas e processos industriais são difíceis de tornar confiáveis sem atraso de enfileiramento muito baixo
Modelo de implantação e adoção gradual
- O AQM L4S não depende de implantação em toda a Internet para trazer benefícios
- Redes públicas de acesso à Internet normalmente são projetadas de modo que o gargalo ocorra em um único link lógico conhecido por site
- Site inclui residências, dispositivos móveis e redes de campus ou empresariais de pequeno e médio porte
- Isso vale de forma geral para xDSL, cabo, PON, celular, sem fio, satélite e outras tecnologias de acesso
- No downstream, implantar AQM L4S na entrada do link de gargalo já traz a maior parte dos benefícios; no upstream, vale o mesmo na entrada do link upstream
- Para que um fluxo L4S obtenha benefício, normalmente são necessários três elementos
- Controle de congestionamento no emissor
- AQM no gargalo
- Em transportes mais antigos, como TCP, feedback atualizado no receptor
- A ordem de implantação pode variar
- O DCTCP já existente pode ser usado em ambientes de teste controlados
- A implantação de TCP Prague e AccECN permite usar L4S na Internet pública
- O QUIC já suporta desde o início o feedback ECN necessário para L4S, então a implantação do controle de congestionamento Prague no emissor é mais simples
Restrições por tecnologia de enlace
- Wi‑Fi, PON e cabo agregam dados de vários pacotes em bursts e armazenam em buffer os pacotes que chegam enquanto o burst é montado
- Ethernet e DSL não fazem essa agregação de pacotes
- Como esse buffering para agregação não pode ser reduzido pelo emissor, ele não deve ser contado como fila controlada por AQM
- Links sem fio como celular, Wi‑Fi e satélite podem ter variações rápidas e grandes de capacidade, então costuma-se considerar desejável uma fila residente para aproveitar aumentos repentinos de capacidade
- Redes celulares são mais complexas por exigirem buffering para tornar handovers imperceptíveis
- O L4S não elimina todas essas necessidades de buffering
- Ao remover “a coluna mais longa” — o buffering para o grande dente de serra do controle Classic — surge incentivo para reduzir também outros componentes de buffering, como tamanho do burst agregado de pacotes ou intervalo de escalonamento do MAC
Gargalos não L4S e tratamento de perdas
- Mesmo que L4S esteja ativado entre dois hosts, se o gargalo não suportar ECN, o emissor L4S deve coexistir com segurança com Reno diante de drops
- Essa regra protege o tráfego Classic, mas degrada o serviço L4S quando há perdas
- Perdas transitórias de gargalo causadas por bursts em filas rasas
- Erros de transmissão, como interferência elétrica
- Policiamento de taxa
- Três abordagens para lidar com isso ainda são tema de pesquisa
- Ignorar no congestionamento Prague algumas perdas pouco prováveis de terem sido causadas por congestionamento
- Recuperar erros de transmissão com a combinação de RACK, L4S e retransmissão no enlace sem reordenação
- Policiadores híbridos de taxa com ECN/drop
- Cenários de implantação com menos desses problemas, como redes cabeadas, podem avançar em paralelo a essa pesquisa
Segurança e policiamento de tráfego
- A Internet atual normalmente lida com separação de capacidade em links compartilhados entre sites por meio de scheduler, sem policiamento generalizado da taxa de fluxos individuais de aplicação
- O L4S foi projetado para não romper esse modelo
- O DualQ foi desenhado para não dar a fluxos não responsivos vantagem de taxa maior do que um AQM de fila única
- Se policiamento de taxa por fluxo for necessário, ele pode ser adicionado separadamente da distinção L4S/Classic
- O L4S foi projetado para reduzir latência sem prejudicar a latência nem a velocidade do tráfego Classic, então não é necessário policiar a taxa de acesso ao serviço L4S apenas para proteger o Classic
- Alguns operadores podem oferecer serviço L4S apenas a grupos limitados, como clientes premium
- Nesse caso, além do campo ECN, podem usar identificadores locais como faixas de endereço de origem
- Se o identificador local não corresponder, mesmo com ECT(1) o pacote pode ser enviado para a fila Classic
- O serviço L4S exige moderação não só na taxa, mas também na explosividade dos bursts
- A função de proteção de fila de baixa latência para DOCSIS preserva a baixa latência redirecionando parcialmente para a fila Classic os fluxos que criam fila
- Funções de proteção em fila única não são parte obrigatória da arquitetura L4S, e parte dos experimentos com L4S busca verificar se elas são necessárias
Túneis e privacidade
- O AQM L4S sinaliza congestionamento pelo campo ECN, então, ao operar dentro de túneis ou em camadas inferiores, o campo ECN precisa ser propagado entre camadas conforme os padrões
- A arquitetura L4S não exclui abordagens que inspecionam identificadores da camada de transporte
- Um exemplo é o FQ-CoDel com suporte adicional a L4S
- A inovação central, o DualQ AQM, não exige inspeção além do cabeçalho IP mais externo
- Mesmo que o usuário criptografe identificadores de fluxo de aplicação com IPsec ou túneis VPN criptografados, não precisa abrir mão da baixa latência
- Como o L4S pode oferecer baixa latência a um amplo conjunto de aplicações, diminui a necessidade de distinguir aplicações individuais ou classes detalhadas enquanto atravessam a rede
1 comentários
Opiniões no Hacker News
Isso é muito legal. No mês passado, vi uma demonstração ao vivo na IETF 118 em Praga, e parecia excelente para chats por vídeo, eliminando completamente o bufferbloat
Parece que é preciso colocar bits adicionais nos pacotes IP para carregar informações como se o buffer está cheio, mas funcionou de verdade e deu aquela sensação de “não sabia que isso era possível”
Para quem não conseguir abrir no tempo certo, é por volta de 1h21. Correção: não era isso; esse era um resumo do hackathon, e a apresentação não é fácil de encontrar
Fiquei curioso sobre como o receptor sinaliza congestionamento ao emissor e fui pesquisar, mas foi mais difícil de achar do que eu esperava. O essencial está documentado em https://www.rfc-editor.org/info/rfc3168
Simplificando, não há apenas uma flag, mas umas três. Há uma flag para o emissor informar aos roteadores que suporta ECN, uma flag para o roteador informar o congestionamento ao receptor, e uma flag que o receptor define ao enviar pacotes ACK
O emissor indica suporte a ECN com o codepoint ECT; um roteador compatível com ECN, em vez de descartar o pacote, define o codepoint CE no cabeçalho IP e o encaminha. O receptor define ECN-Echo no próximo ACK TCP, e o emissor reage ao congestionamento como se fosse perda de pacote, depois define a flag CWR no cabeçalho TCP do próximo pacote
Bob Briscoe pensa nessa direção há muito tempo. Recomendo estes clássicos relacionados
http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A...
https://dl.acm.org/doi/pdf/10.1145/1080091.1080124
Alguns testes foram feitos na rede a cabo da Comcast, e os slides abaixo explicam
https://datatracker.ietf.org/meeting/118/materials/slides-11...
Não sei aonde isso vai levar, mas me faz pensar que ISPs podem começar a cobrar pedágio por uma via expressa
Opinião pessoal, mas trabalho na Comcast
Se quiser saber mais sobre L4S, uma série de webinars começa hoje em understandinglatency.com. Participam alguns autores do L4S, a pessoa responsável pelo teste de campo de L4S da Comcast e também vozes críticas
Encontrei uma demonstração curta em uso real com feed de vídeo de carrinho RC: https://www.youtube.com/watch?v=RZmS10djDEg
É um avanço na direção certa, mas surge um problema se houver mesmo um único participante mal-intencionado que ignore o feedback de congestionamento e queira apenas uma fatia maior da largura de banda. Nesse caso, os outros participantes recuam, e o lado injusto pega o que quer
Para os bons participantes é difícil saber se os outros estão seguindo as regras, e eles precisam saber que há fair queueing para confiar que o L4S os tratará de forma justa
Esse problema pode ser resolvido complementando o L4S com fair queueing como fq_codel e fazendo o controle de congestionamento conseguir detectar a presença de fair queueing: https://github.com/muxamilian/fair-queuing-aware-congestion-...
A discussão sobre fair queueing faz parte de um debate maior. Sem fair queueing, independentemente do L4S, a justiça já é implementada pelos hosts de ponta, e hosts de ponta como servidores podem ignorar a reação ao congestionamento e pegar mais do que sua fatia justa. Esse não é um problema criado pelo L4S, embora alguns vejam que o L4S facilita pegar uma fatia maior
Defensores de fair queueing acham que a rede deve garantir o compartilhamento justo, mas nem todos concordam com a métrica de justiça que eles escolheram. Em especial, um dos principais defensores do L4S não concorda, como se pode ver no artigo linkado aqui: https://news.ycombinator.com/item?id=38598023
Do ponto de vista do usuário, fico curioso sobre o que realmente muda. Por exemplo, chamadas de vídeo ficam mais próximas do tempo real? Normalmente há uma latência de cerca de 0,5 a 1 segundo, então há muitas interrupções e pessoas falando por cima umas das outras. Que outras aplicações melhorariam bastante?
Para ficar abaixo de 3 Mbps de bitrate, é preciso fazer compromissos difíceis entre qualidade, bitrate, tempo de CPU e latência. Notebooks comuns têm CPUs lentas ou, mesmo com CPUs de 6 núcleos, mantêm clocks baixos quando estão na bateria. Codificação de vídeo acelerada por hardware também não é universal, então qualidade e latência são sacrificadas
Wi-Fi também acrescenta latência, especialmente quando o notebook está na bateria. Para lidar com NAT, muitos serviços de chat por vídeo usam servidores na nuvem como intermediários, o que adiciona latência
https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
Recursos altamente interativos, como jogos e videoconferência, também ficam muito melhores sem latência. Hoje, renderizar páginas web, fazer streaming de vídeo ou processar interações com assistentes de IA como a Alexa exige muitas idas e vindas, então praticamente tudo em que o usuário e o dispositivo interagem pode melhorar
Em essência, L4S é uma tecnologia que reduz o loop de feedback de latência. A parte final deste vídeo explica isso muito bem: https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp