Controle de congestionamento

O congestionamento começa quando o tráfego chega a uma parte da rede mais rápido do que ela consegue transportá-lo por um período prolongado. Os pacotes esperam no buffer de saída de um roteador, chamado de fila. O gargalo é o enlace com a menor capacidade disponível para esse tráfego ao longo de seu caminho.

Acompanhe o excedente

Suponha que um roteador receba 12 Mbps para um enlace de saída capaz de enviar 10 Mbps. Ele não pode acelerar a saída para igualá-la à entrada. A cada segundo, 2 megabits ficam esperando, ou 250.000 bytes após a divisão por 8. Começando vazio, um buffer de 1.000.000 de bytes fica cheio em:

Um pacote que entra atrás dessa quantidade de dados enfileirados espera o enlace transmitir os dados à sua frente:

Quando o buffer permanece cheio, a saída continua transportando apenas 10 Mbps. Cerca de 2 Mbps dos 12 Mbps que chegam são descartados, um sexto do tráfego oferecido. Esses cálculos consideram taxas constantes de chegada e saída; o momento de cada pacote acrescenta pequenas variações.

Decida se a fila vai esvaziar

Uma rajada curta é diferente de uma sobrecarga sustentada. Uma fila pode absorver uma rajada e esvaziar quando as chegadas caem abaixo da taxa de saída. Se as chegadas constantes forem exatamente iguais à taxa de saída, uma fila existente persiste: cada saída é substituída por uma chegada. Chegadas sustentadas acima da taxa de saída fazem a fila crescer até o buffer ficar cheio.

O tráfego real é irregular. Mesmo abaixo da utilização média total, rajadas fazem os pacotes esperar. Perto da capacidade, há pouco tempo disponível para esvaziar essas rajadas, portanto o atraso médio aumenta rapidamente. O congestionamento aumenta principalmente a parcela de fila do atraso de pacote; processamento, transmissão e propagação são componentes separados.

Identifique a taxa em questão

Uma diferença de velocidades pode revelar o gargalo: uma rede local de 1 Gbps pode alimentar um enlace de acesso de 50 Mbps. A agregação tem o mesmo efeito quando várias entradas de roteador compartilham uma saída. Uma única entrada pode parecer modesta enquanto a soma delas sobrecarrega essa saída.

Escolha o limite correto

O controle de fluxo protege o buffer do receptor usando a janela de recepção anunciada por ele. O controle de congestionamento protege o caminho entre as extremidades. Um receptor pode ter bastante memória livre enquanto um roteador no caminho descarta pacotes.

Um buffer maior no roteador pode comportar uma rajada mais longa, mas uma sobrecarga sustentada preenche qualquer buffer finito e aumenta o tempo de espera. Um enlace de gargalo mais rápido elimina essa falta de capacidade. Outro enlace passa então a limitar o caminho; ele só fica congestionado quando o tráfego excede a capacidade disponível nesse ponto.

Um enlace totalmente ocupado só é útil quando seu tráfego ajuda a entregar dados novos. O congestionamento consome capacidade de maneiras que podem reduzir a entrega útil mesmo enquanto a rede permanece ocupada.

Conte os custos

O atraso de fila vem primeiro. Uma chamada de vídeo pode se tornar difícil de acompanhar antes que qualquer pacote seja descartado, porque a fala chega tarde demais. A confiabilidade, por si só, não consegue corrigir esse atraso.

Pacotes perdidos criam um segundo custo: um remetente confiável os retransmite. Se um enlace de 10 Mbps transporta pacotes de mesmo tamanho e 20% repetem dados já transportados nesse enlace, no máximo 8 Mbps transportam dados novos:

A vazão útil da aplicação é menor após considerar os cabeçalhos e eventuais perdas em outros pontos. A atividade do enlace, portanto, exagera o progresso feito pela aplicação.

Algumas retransmissões são desnecessárias. Um pacote pode estar esperando em uma fila longa quando o temporizador do remetente expira. Sua substituição entra então na mesma rede ocupada. As duas cópias podem chegar, mas o receptor mantém os dados apenas uma vez. A fila transformou um problema de atraso em carga oferecida adicional.

Observe os enlaces anteriores a um descarte

Um descarte perto do destino pode desperdiçar trabalho em vários enlaces anteriores. Imagine um pacote atravessando os enlaces A e B antes de ser descartado na fila para C. As transmissões em A e B usaram capacidade sem entregar esse pacote. Repetir esse padrão deixa menos capacidade nos enlaces anteriores para o tráfego que poderia ter chegado ao destino.

À medida que a carga oferecida aumenta, a vazão também aumenta inicialmente. Com descartes suficientes nos pontos seguintes, porém, o aumento da carga envia mais tráfego para um trabalho que será desperdiçado. A vazão fim a fim pode atingir um pico e depois cair. O colapso por congestionamento é o caso extremo: a carga oferecida permanece alta enquanto a vazão útil cai em direção a zero.

Em outubro de 1986, a vazão entre o Lawrence Berkeley Laboratory e a UC Berkeley caiu de 32 kbps para 40 bps, uma redução por um fator de 800. O trabalho de Jacobson e Karels em 1988 introduziu uma resposta coordenada: partida lenta, prevenção de congestionamento, uma estimativa melhor do tempo de ida e volta e recuo exponencial do temporizador. O controle de janela e temporizadores adequados tratam de partes diferentes do ciclo de retorno.

Encontre a faixa útil de operação

O joelho da curva e o precipício da curva de Raj Jain descrevem dois limites. Além do joelho, a carga adicional traz pouco ganho de vazão, mas muito mais atraso. Além do precipício, a vazão cai à medida que as perdas e o trabalho desperdiçado passam a predominar. O controle de congestionamento busca uma entrega eficiente perto do joelho, mantendo distância do colapso.

A internet não tem um controlador central que atribua uma taxa a cada remetente. Cada remetente precisa reagir às informações que observa. Se um deles continuar transmitindo a uma taxa alta e fixa enquanto os outros reduzem suas taxas, poderá tomar a capacidade deles e agravar a sobrecarga.

A retransmissão torna um fluxo de bytes confiável, mas não elimina o custo da perda. A recuperação consome capacidade e atrasa a entrega dos dados faltantes; esperar por um temporizador de retransmissão pode interromper a conexão por muito mais tempo que a recuperação rápida.

Um remetente não vê diretamente todas as filas dos roteadores em seu caminho. O controle de congestionamento é um processo de retorno: observar a entrega, decidir o que as observações significam e ajustar a quantidade ou a taxa do tráfego que entra na rede.

Localize a origem do retorno

No controle fim a fim, as extremidades inferem o congestionamento a partir de perda ou atraso, sem uma mensagem explícita do roteador. O Reno usa perda. O Vegas usa alterações no tempo de ida e volta. O BBR constrói um modelo do caminho a partir de medições da taxa de entrega e do RTT.

No controle assistido pela rede, um roteador fornece retorno explícito. A ECN marca um pacote que segue para o receptor, e este informa a marca em seu reconhecimento. Esquemas ATM mais antigos podiam informar uma taxa permitida explícita. Um roteador também pode enviar uma mensagem diretamente ao remetente, chamada de pacote de contenção. O ICMP Source Quench da internet usava essa abordagem e foi descontinuado em 2012.

Interprete os sinais com cuidado

Com filas de descarte na cauda, a perda normalmente ocorre depois que o buffer fica cheio. O gerenciamento ativo de filas pode descartar ou marcar pacotes antes. Isso altera o momento em que um sinal chega, sem mudar a necessidade de resposta do remetente.

O RTT mínimo observado é útil porque aproxima o RTT de um caminho com pouco enfileiramento. Um RTT acima desse mínimo sugere espera, mas uma extremidade precisa interpretar as medições ao longo do tempo. Nem uma única amostra imprecisa nem cada pacote perdido em um enlace sem fio identificam a causa com certeza.

Controle uma janela ou uma taxa

Um remetente baseado em janela limita os dados em trânsito ainda não reconhecidos. À medida que os reconhecimentos retornam, abre-se espaço para novos dados. Um remetente baseado em taxa define uma taxa-alvo e geralmente usa cadenciamento de pacotes, espaçando-os ao longo do tempo. Os controles estão relacionados:

Por exemplo, 100.000 bytes por 50 ms correspondem a 2.000.000 bytes/s, ou 16 Mbps, quando a janela é o limite ativo. Um controlador baseado em taxa também pode usar uma janela como limite superior para os dados pendentes.

Equilibre vários objetivos

Eficiência significa manter ocupada a capacidade disponível no gargalo. Equidade diz respeito a como os fluxos concorrentes a dividem. Baixo atraso exige filas curtas; estabilidade evita oscilações grandes e repetidas; capacidade de resposta significa adaptar-se quando a capacidade ou a concorrência muda. Uma regra que preenche rapidamente um caminho ainda pode ser ruim para manter o atraso baixo ou compartilhar a capacidade com outros algoritmos.

O controlador do TCP normalmente é executado no sistema operacional. O controlador do QUIC normalmente é executado em uma biblioteca da aplicação. O UDP não fornece controlador, portanto as aplicações que o usam devem fornecer seu próprio controle de congestionamento. O protocolo que transporta os dados não elimina a obrigação de responder ao congestionamento.

A janela de congestionamento, cwnd, é um limite definido pelo remetente para os dados em trânsito ainda não reconhecidos. Ela é medida em bytes, embora os acompanhamentos frequentemente contem segmentos de tamanho máximo. Ela não é um campo do cabeçalho TCP. O receptor anuncia um limite diferente, a janela de recepção, rwnd.

Aplique os dois limites

As novas transmissões devem respeitar tanto o controle de fluxo quanto o controle de congestionamento. O limite utilizável é:

Se cwnd for de 30.000 bytes e rwnd de 18.000 bytes, prevalece o limite do receptor. Com 12.000 bytes ainda pendentes, o remetente pode enviar mais 6.000 bytes. Após uma redução da janela de congestionamento, os dados existentes podem ultrapassar o novo limite; o remetente espera pelos reconhecimentos antes de acrescentar mais dados.

O tamanho máximo de segmento, MSS, conta os dados de aplicação, excluindo os cabeçalhos. Uma MTU Ethernet de 1.500 bytes menos cabeçalhos IPv4 de 20 bytes e TCP de 20 bytes deixa 1.460 bytes, sem opções. As normas usam SMSS para o MSS do remetente.

Transforme uma janela em taxa

Um remetente limitado pela janela entrega aproximadamente uma janela por RTT. Para cwnd de 65.536 bytes e RTT de 50 ms:

Multiplique por 8 para obter cerca de 10,5 Mbps. Essa estimativa também exige dados de aplicação suficientes, uma janela de recepção pelo menos tão grande e um caminho capaz de transportar a taxa resultante.

Preencha o caminho sem encher sua fila

O produto largura de banda-atraso, BDP, é a largura de banda do gargalo multiplicada pelo RTT mínimo, sem filas. Para 100 Mbps e 40 ms:

Dividir por 8 resulta em 500.000 bytes, cerca de 342 segmentos de 1.460 bytes. Um BDP em trânsito mantém esse gargalo idealizado ocupado sem uma fila persistente. Menos dados deixam capacidade ociosa; dados em excesso esperam e aumentam o RTT medido. Calcular o BDP a partir de um RTT já elevado confunde dados enfileirados com dados de que o caminho precisa.

A sincronização por ACKs ajuda a manter o ritmo. À medida que os pacotes saem do gargalo, os ACKs retornam e liberam espaço para substitutos. Em regime estável, as saídas ajudam, portanto, a determinar o momento das novas chegadas. Essa é a ideia de conservação de pacotes por trás do comportamento de autossincronização do TCP.

Defina o ponto inicial e o limiar

A janela inicial da RFC 5681 varia de dois a quatro segmentos conforme o SMSS: quatro até 1.095 bytes, três até 2.190 bytes e dois acima disso. A RFC 6928 permite uma janela inicial de até dez segmentos. Um acompanhamento que começa em um segmento é útil para ensinar, mas não afirma que todas as novas conexões começam nesse ponto.

O ssthresh, limiar de partida lenta, seleciona o modo de crescimento. Abaixo dele, o TCP usa partida lenta; acima dele, prevenção de congestionamento. Quando são iguais, a RFC 5681 permite qualquer um dos dois. Um limiar inicial alto permite que um novo remetente descubra a capacidade por meio da partida lenta.

O TCP primeiro precisa descobrir quanto tráfego o caminho consegue transportar. A partida lenta expande rapidamente a janela a partir de um ponto inicial pequeno. A prevenção de congestionamento então sonda com mais cautela quando o limiar de partida lenta é atingido.

Conte os reconhecimentos na partida lenta

A RFC 5681 aumenta cwnd em até um SMSS para cada reconhecimento de dados novos:

em que N é a quantidade de bytes recém-reconhecidos. Com um ACK por segmento completo e dados suficientes para preencher cada janela, cada segmento enviado abre espaço para dois na rodada seguinte: um substituto e um devido ao aumento da janela.

Começando em 1 MSS, os valores a cada rodada são 1, 2, 4, 8, 16, 32 e 64 MSS. São necessários seis RTTs para atingir 64 MSS. A 100 ms por RTT, isso representa 0,6 s. O nome reflete um início mais seguro do que enviar imediatamente uma janela de recepção inteira; o crescimento em si é exponencial.

Os ACKs atrasados alteram a contagem. Se o receptor enviar um ACK para cada dois segmentos completos, a regra simples por ACK resulta em um crescimento de aproximadamente 1,5 vez por RTT. A contagem apropriada de bytes, descrita na RFC 3465, usa os bytes recém-reconhecidos para lidar com a dependência da frequência dos ACKs.

Alterne os modos de crescimento

Para um acompanhamento com cwnd inicial de 1 MSS e ssthresh de 8 MSS, escolha a prevenção de congestionamento quando forem iguais. O acompanhamento fica:

As três primeiras alterações dobram a janela. As alterações posteriores acrescentam um MSS por RTT. Uma perda pode interromper qualquer uma das fases. Implementações que usam HyStart++ (RFC 9406) também podem deixar a partida lenta antecipadamente quando o atraso aumenta.

Explique o aumento aditivo

Uma regra comum por ACK durante a prevenção de congestionamento é:

Em 10 MSS, um ACK acrescenta cerca de 0,1 MSS. Cerca de dez ACKs chegam durante a rodada, portanto o aumento total é de aproximadamente um MSS. O incremento por ACK fica menor à medida que cwnd cresce, mantendo o aumento por rodada aproximadamente constante.

Essa diferença importa em um caminho de grande capacidade. Passar de 16 para 32 MSS leva um RTT na partida lenta ideal, mas dezesseis RTTs na prevenção de congestionamento. O crescimento mais lento reduz o excesso repentino depois que o remetente obtém uma estimativa útil da capacidade.

Reconheça uma reinicialização

A partida lenta não se limita ao início de uma conexão. A expiração do tempo limite de retransmissão redefine cwnd para um segmento. Um período ocioso maior que o tempo limite de retransmissão também exige uma reinicialização com no máximo a janela inicial, pois a sincronização por ACKs e a estimativa de capacidade anteriores podem não ser mais adequadas ao caminho.

A prevenção de congestionamento não mantém cwnd em um valor seguro fixo. Ela continua acrescentando capacidade até chegar um sinal de congestionamento. Em um caminho com descarte na cauda, essa sondagem contínua tende a formar uma fila persistente antes que a perda sinalize ao remetente que reduza sua taxa.

O TCP pode inferir a ausência de um segmento a partir de um temporizador ou de ACKs duplicados. A distinção importa: a expiração de um tempo limite oferece menos evidências de que a rede ainda está entregando tráfego do que três ACKs duplicados.

Defina o novo limiar

O Reno usa a quantidade realmente pendente, FlightSize, para definir:

FlightSize frequentemente fica próximo de cwnd durante uma transferência totalmente ativa, mas os dois não precisam ser iguais quando a aplicação envia poucos dados. O limite inferior impede que o limiar fique abaixo de dois segmentos.

Após a expiração de um tempo limite, o remetente retransmite, define cwnd como um SMSS e reinicia a partida lenta. Expirações repetidas para os mesmos dados dobram o temporizador de retransmissão. Esse recuo exponencial impede que uma falha persistente produza uma sequência igualmente persistente de novas tentativas.

Recupere-se antes de o temporizador expirar

Três ACKs duplicados mostram que três segmentos posteriores chegaram depois de uma lacuna. Eles não significam que três segmentos foram perdidos. Um ou dois ACKs duplicados podem resultar de uma mudança de ordem, portanto o TCP espera o terceiro antes de a retransmissão rápida enviar o segmento faltante.

O Reno então entra em recuperação rápida. Suponha que FlightSize seja 12 MSS. O novo limiar é 6 MSS, e o Reno define temporariamente:

Os três segmentos adicionais correspondem aos pacotes que comprovadamente saíram da rede. Cada ACK duplicado adicional infla cwnd em um MSS, permitindo que o envio continue quando a janela possibilita. Quando um ACK avança o reconhecimento cumulativo, o Reno reduz cwnd para 6 MSS e retoma a prevenção de congestionamento.

Com janela inicial de 1 MSS e ssthresh de 8 MSS, cwnd cresce 1, 2, 4, 8, 9, 10, 11, 12 MSS antes da perda. O Reno acaba continuando em 6, 7, 8, 9. O Tahoe reinicia em 1, 2, 4, atinge o novo limiar de 6 e depois continua 7, 8.

Repare várias lacunas em uma janela

O Reno clássico sai da recuperação no primeiro ACK de dados novos. Se esse ACK abrange apenas parte dos dados originalmente em trânsito, outra lacuna permanece. O Reno pode reduzir novamente ou ter um tempo limite expirado.

O NewReno (RFC 6582) permanece em recuperação diante desse ACK parcial e retransmite o próximo segmento faltante. Ele sai quando todos os dados pendentes na entrada em recuperação são reconhecidos. O SACK informa explicitamente os blocos recebidos; a recuperação baseada em SACK pode identificar e reparar várias lacunas em uma ida e volta.

Um episódio de congestionamento normalmente deve causar uma redução, mesmo que vários pacotes sejam perdidos. O NewReno e a recuperação baseada em SACK lidam com isso de forma mais confiável que o Reno clássico. O CUBIC usa um fator de redução diferente para sinais comuns de congestionamento, mantendo 70%, mas também reinicia com um segmento após a expiração de um tempo limite.

O Reno clássico aumenta repetidamente sua janela e a reduz após um congestionamento. O dente de serra resultante fornece uma estimativa útil de regime estável quando o RTT é aproximadamente constante, a retransmissão rápida detecta as perdas e não há expirações de tempos limite nem partida lenta.

Calcule a média da janela

Seja o pico da janela igual a W segmentos. Uma redução pela metade produz uma faixa de W/2 a W, cuja média é 0,75 W. Multiplique pelo MSS para obter bytes por ida e volta e depois divida pelo RTT:

Para W de 24 segmentos, MSS de 1.460 bytes e RTT de 80 ms, a taxa máxima é 3,504 Mbps. A média é de cerca de 2,63 Mbps. Lembre-se de que uma janela em segmentos precisa de um fator de tamanho de segmento; uma janela já expressa em bytes não precisa.

Relacione vazão e perda

A aproximação de Mathis expressa o mesmo comportamento semelhante ao do Reno usando a fração de perda L:

Se MSS estiver em bytes e RTT em segundos, T estará em bytes/s. Com MSS de 1.460 bytes, RTT de 0,1 s e fração de perda de 0,0001, o denominador é 0,001 s. O resultado é 1.781.200 bytes/s, cerca de 14,25 Mbps após a multiplicação por 8.

Com fração de perda fixa, dobrar o RTT reduz a vazão pela metade. Com RTT fixo, dobrar a vazão exige que a perda caia para um quarto, pois o denominador contém a raiz quadrada da perda. Uma fração de perda de 0,0001 significa 0,01%, não 0,0001%.

Entenda o problema em alta velocidade

Um caminho de 10 Gbps com RTT sem filas de 100 ms precisa de 1 bilhão de bits, ou 125.000.000 de bytes, em trânsito para ficar ocupado. Usando segmentos de 1.500 bytes, isso corresponde a cerca de 83.333 segmentos. Reduzir essa janela pela metade deixa cerca de 41.667 segmentos a recuperar. O Reno acrescenta um por RTT, portanto recuperá-los leva cerca de 4.167 s, quase 70 minutos.

Esse valor de 83.333 segmentos é a janela necessária para enviar a 10 Gbps em um instante. Um dente de serra do Reno com média de 10 Gbps precisaria de um pico maior, pois sua janela média é apenas três quartos do pico. A fórmula da taxa de perda estima que sustentar uma média de 10 Gbps com esse MSS e RTT exige uma perda de cerca de um segmento em 4,7 bilhões.

Verifique outros limites

Um controlador não pode entregar dados mais rápido que o gargalo, e uma janela de recepção pequena pode limitar o envio antes de cwnd. Use o menor limite aplicável. Expirações de tempos limite reduzem a taxa abaixo do modelo simples, e um objeto pequeno pode terminar inteiramente na partida lenta. Seu tempo de conclusão depende muito das rodadas iniciais e da janela inicial, portanto a fórmula para longa duração descreve mal essa transferência.

Um enlace de acesso mais rápido, portanto, só ajuda quando elimina um limite ativo. RTT longo, perda ou uma janela pequena podem deixar uma única conexão muito abaixo da capacidade do enlace ampliado.

Se K fluxos ativos querem mais capacidade do que um gargalo pode fornecer, uma parcela igual por fluxo é R/K, em que R é a taxa disponível. A eficiência diz respeito a se a soma das taxas é R. A equidade diz respeito a quão igualmente eles a dividem.

Coloque duas taxas em um diagrama

Em um diagrama de Chiu–Jain, as coordenadas horizontal e vertical são as taxas dos dois fluxos. A reta de eficiência é:

A reta de equidade é a diagonal em que as taxas são iguais. Sua interseção é a alocação justa que usa toda a capacidade. Em um enlace de 10 Mbps, ela é de 5 Mbps por fluxo. Pontos abaixo da reta de eficiência deixam capacidade sem uso; pontos acima dela oferecem mais tráfego do que o enlace consegue transportar.

Separe as duas atualizações

O aumento aditivo acrescenta a mesma quantidade a cada taxa. Começando em 8 e 1 Mbps, acrescentar 0,5 Mbps a cada uma resulta em 8,5 e 1,5 Mbps. A diferença permanece em 7 Mbps, mas o fluxo menor ganha mais em relação à sua taxa inicial. No diagrama, o ponto se move paralelamente à diagonal de igualdade.

A redução multiplicativa multiplica as duas taxas pelo mesmo fator. Reduzir 9 e 2 Mbps pela metade produz 4,5 e 1 Mbps. A razão entre elas não muda, enquanto a diferença absoluta cai de 7 para 3,5 Mbps. O ponto se move em direção à origem e elimina rapidamente a sobrecarga.

Essas são duas formas diferentes de melhoria: a adição igual melhora o equilíbrio relativo; a redução proporcional diminui a diferença absoluta. Repetir as duas impede que a diferença volte a crescer enquanto a capacidade é sondada novamente.

Acompanhe vários ciclos

Comece em 8 e 1 Mbps no enlace de 10 Mbps. Acrescente 0,5 Mbps por fluxo a cada etapa e reduza somente depois que o total ultrapassar a capacidade. Após dois aumentos, as taxas são 9 e 2, totalizando 11. A redução pela metade resulta em 4,5 e 1.

Mais cinco aumentos levam a 7 e 3,5, totalizando 10,5. A redução pela metade resulta em 3,5 e 1,75. As diferenças foram 7, 3,5 e 1,75 Mbps. Outra redução sincronizada pela metade faz a próxima diferença ser 0,875 Mbps. Os fluxos se aproximam de parcelas iguais enquanto seu total continua oscilando em torno da capacidade disponível.

Compare outras regras de atualização

Essa convergência pressupõe RTTs iguais, sinais de congestionamento sincronizados, respostas iguais e fluxos que permaneçam ativos por tempo suficiente. O incremento aditivo do Reno é de cerca de um MSS por RTT e seu fator de redução é um meio. Outros incrementos aditivos positivos e fatores de redução entre zero e um produzem o mesmo argumento básico de convergência. Fluxos reais não precisam cumprir todos esses pressupostos, portanto um par desigual em um instante não demonstra, por si só, uma falha do AIMD.

Parcelas iguais são uma referência útil, mas os fluxos reais podem diferir em demanda, RTT, número de conexões e controlador de congestionamento. Uma afirmação sobre equidade precisa responder claramente: “equidade entre quais fluxos?”

Calcule o índice de Jain

Para taxas de fluxo não negativas com total diferente de zero, o índice de Jain é:

Taxas de 8 e 2 Mbps resultam em uma soma de 10 e uma soma dos quadrados de 68, portanto o índice é de cerca de 0,735. Taxas iguais resultam em 1. Se um de n fluxos receber tudo, o índice será 1/n.

O índice mede igualdade, não utilização. Dois fluxos de 1 Mbps cada e dois de 5 Mbps cada têm índice 1, embora usem quantidades diferentes de um enlace de 10 Mbps. Verifique a taxa total separadamente.

Considere a demanda limitada

A equidade máx-min dá aos fluxos de baixa demanda o que eles precisam e depois divide a capacidade restante entre os fluxos que ainda buscam mais. Em um enlace de 12 Mbps, três fluxos desejam 2, 8 e 10 Mbps. A parcela igual inicial é 4 Mbps. O primeiro precisa de apenas 2, restando 10 Mbps para os outros dois. A alocação é, portanto, de 2, 5 e 5 Mbps.

Aumentar uma das taxas maiores exigiria reduzir um fluxo que já tem uma taxa igual ou menor. Essa propriedade define a equidade máx-min. Sua alocação desigual pode ser adequada mesmo que a medida de igualdade de Jain fique abaixo de 1.

Identifique vantagens entre os fluxos

O Reno cresce uma vez por RTT. Com a mesma fração de perda, sua vazão aproximada é inversamente proporcional ao RTT: um fluxo de 20 ms pode atingir cerca de quatro vezes a taxa de um fluxo de 80 ms. O acesso igual ao gargalo não elimina essa vantagem de tempo.

O compartilhamento também é por conexão. Com nove conexões existentes, uma aplicação que acrescenta uma pode receber cerca de um décimo do enlace. Se, em vez disso, acrescentar onze conexões comparáveis, sua parcela passa a onze vinte avos, ou 55%. HTTP/2 e HTTP/3 multiplexam muitas requisições em uma conexão, enquanto clientes HTTP/1.1 frequentemente abrem várias conexões.

Uma aplicação UDP de taxa fixa pode continuar enviando enquanto os fluxos TCP reduzem suas taxas. O próprio UDP não fornece um controlador; a RFC 8085 solicita que as aplicações acrescentem controle de congestionamento adequado. Um fluxo amigável ao TCP não usa mais largura de banda do que tráfego TCP comparável nas mesmas condições. O TFRC usa a equação de vazão do TCP para permitir uma taxa mais estável.

Considere a fila e o algoritmo

Uma fila FIFO não impõe parcelas iguais aos fluxos. Seu resultado depende do comportamento dos remetentes. O enfileiramento justo, incluindo o escalonamento por fluxo do FQ-CoDel, dá aos fluxos filas e oportunidades de atendimento separadas.

O crescimento do CUBIC e o do Reno diferem em caminhos com BDP grande. O compartilhamento entre BBR e CUBIC também depende da versão e da capacidade do buffer; as primeiras versões do BBR podiam ser agressivas com buffers pequenos. Nenhum cálculo isolado de igualdade estabelece que controladores diferentes coexistirão de modo equilibrado em todos os caminhos.

Uma fila com descarte na cauda aceita pacotes até seu buffer ficar cheio e então descarta os novos pacotes que chegam. Remetentes baseados em perda continuam aumentando o envio até receberem um sinal de congestionamento. Com um buffer grande de descarte na cauda, esse sinal só pode chegar depois que uma fila longa se formou.

Calcule o atraso oculto em um buffer

Um buffer de 2.000.000 de bytes diante de um enlace de subida de 20 Mbps comporta 16 milhões de bits. Se estiver cheio, um pacote atrás desses dados espera:

Um envio de dados pode, portanto, manter a vazão alta enquanto acrescenta quase um segundo a uma chamada que compartilha o enlace de subida. Atraso excessivo por acúmulo em buffers significa atraso excessivo persistente causado por buffers grandes e pelo comportamento do tráfego que os mantém ocupados.

O armazenamento em buffer ainda tem uma finalidade: rajadas curtas precisam de um lugar para esperar. No modelo simples de um único fluxo Reno, cerca de um BDP de buffer pode manter o enlace ocupado imediatamente após uma redução da janela pela metade. Tornar o buffer muito maior aumenta a espera sem aumentar a taxa de transmissão do enlace.

Sinalize congestionamento antes do transbordamento

O gerenciamento ativo de filas, AQM, descarta ou marca pacotes antecipadamente para sinalizar que os remetentes devem reduzir sua carga. Um transbordamento físico deixa de ser a única maneira de anunciar congestionamento. A RFC 7567 recomenda a ampla adoção de AQM.

A detecção antecipada aleatória, RED, observa uma média móvel do tamanho da fila. Abaixo de um limiar mínimo, não sinaliza. Entre dois limiares, descarta ou marca com uma probabilidade crescente. Acima do limiar máximo, sinaliza em cada chegada. O cálculo da média impede que uma única rajada curta pareça uma sobrecarga persistente, mas é difícil escolher limiares que funcionem em diferentes velocidades e cargas.

Meça o tempo de espera diretamente

O CoDel, atraso controlado, mede o tempo de permanência de um pacote: seu tempo dentro da fila. Sua meta padrão é 5 ms e seu intervalo é 100 ms. Se até mesmo o tempo mínimo de permanência observado permanecer acima da meta por um intervalo, existe uma fila persistente. O CoDel então descarta ou marca pacotes com ECN, aumentando a frequência de sinalização enquanto o atraso excessivo persiste.

O mínimo em um intervalo importa. Uma rajada pode produzir um atraso alto por pouco tempo e depois esvaziar rapidamente; uma fila cujo atraso nunca fica pequeno precisa de intervenção. A medição de atraso do CoDel permite que seus valores padrão funcionem em uma ampla faixa de taxas de enlace.

O FQ-CoDel combina filas separadas por fluxo com CoDel. A separação dos fluxos ajuda a evitar que uma grande transferência coloque todos os pequenos pacotes interativos atrás de seu acúmulo de dados.

Sinais antecipados também podem reduzir a sincronização global, em que muitos fluxos perdem pacotes juntos, reduzem suas taxas pela metade juntos e deixam o enlace temporariamente subutilizado. Sinais antecipados aleatórios distribuem as reações ao longo do tempo. Com tráfego que oferece suporte a ECN, um AQM pode enviar seu aviso por meio de uma marca e ainda entregar o pacote.

A notificação explícita de congestionamento, ECN, permite que um roteador entregue um pacote e avise que o congestionamento está aumentando. A marca altera o comportamento do remetente sem criar dados faltantes que precisem ser retransmitidos.

Leia o ponto de código IP

O campo ECN tem dois bits no byte de tipo de serviço do IPv4 ou na classe de tráfego do IPv6.

Na negociação TCP clássica da RFC 3168, o SYN do cliente ativa ECE e CWR. O SYN-ACK de um servidor que aceita a negociação ativa ECE. Após a negociação, o TCP clássico marca os pacotes de dados como ECT(0).

Acompanhe o ciclo de retorno

Um AQM que descartaria um pacote com suporte a ECN como aviso de congestionamento pode alterar seu ponto de código para CE e encaminhá-lo. Um pacote Not-ECT não pode transportar esse aviso e é descartado quando o AQM precisa sinalizar. Um buffer completamente cheio continua descartando pacotes, inclusive os que oferecem suporte a ECN.

O receptor ecoa CE ativando ECE, eco de ECN, em seus ACKs. Ele continua até receber CWR, janela de congestionamento reduzida, do remetente. Esses indicadores informam e confirmam o retorno; sua presença não significa que dados foram perdidos.

Para a ECN clássica do tipo Reno, comece com cwnd de 20 MSS. Depois que ECE chega, o remetente reduz cwnd para 10 MSS e coloca CWR em seu próximo segmento de dados novos. O receptor para de ecoar quando CWR chega. Ecos repetidos da mesma janela não exigem reduções repetidas pela metade. O aviso retorna pelo caminho dos reconhecimentos, portanto a resposta está sujeita ao atraso do retorno.

A ECN especifica o sinal; o algoritmo de congestionamento fornece a regra de redução. O Reno reduz pela metade, enquanto o CUBIC normalmente mantém 70% em um evento ECN. As duas extremidades e um gargalo que faz marcações precisam oferecer suporte a ECN para que esse ciclo funcione.

Use a fração de marcações

O DCTCP, TCP para centros de dados, usa marcações frequentes em um ambiente controlado. Ele estima a fração de bytes marcados com um valor suavizado alfa:

em que M é a fração marcada recentemente. Algumas implementações usam g igual a 1/16. Ele reduz a janela usando:

Com alfa igual a 0,2, uma janela de 100 passa a 90; com alfa igual a 1, ela cai pela metade. O DCTCP precisa de marcação e retorno compatíveis. Misturá-lo com TCP clássico em uma fila comum pode produzir parcelas injustas.

O L4S, arquitetura experimental das RFCs 9330–9332, leva uma resposta escalável semelhante aos caminhos da internet. ECT(1) identifica o tráfego escalável, e um AQM acoplado de duas filas o separa do tráfego clássico enquanto coordena o tratamento dos dois. Marcações frequentes com filas curtas buscam um atraso de fila em torno de um milissegundo. ECT(1) por si só não garante esse atraso: o controlador e o comportamento do gargalo completam o projeto.

O CUBIC trata do crescimento lento do Reno em caminhos rápidos e de longa distância. Sua janela segue o tempo decorrido desde uma redução por congestionamento, dando-lhe uma resposta diferente de um aumento fixo de um segmento a cada RTT. A RFC 9438 especifica o CUBIC; ele é o padrão nas principais pilhas TCP do Linux, Windows e Apple.

Registre o último ponto de congestionamento

Em uma perda comum ou em um evento de congestionamento por ECN, o CUBIC registra sua janela como Wmax. Com uma janela totalmente utilizada, seu fator de redução de 0,7 mantém 70% da quantidade de dados em trânsito. O Reno manteria a metade. A expiração de um tempo limite de retransmissão é diferente: o CUBIC segue o Reno de volta a uma janela de um segmento e à partida lenta, enquanto define seu limiar com o fator de redução do CUBIC.

Para o período cúbico básico após uma redução, a janela-alvo em segmentos é:

O tempo t está em segundos. Quando a janela reduzida é 0,7 Wmax, o tempo de retorno ao pico anterior é:

Acompanhe a curva

Com Wmax de 100 segmentos, a janela reduzida é 70. O valor dentro da raiz cúbica é 75, portanto K é cerca de 4,22 s. Em um segundo, a curva está em cerca de 86,7 segmentos; em dois segundos, em 95,6; em três segundos, em 99,3. Ela atinge 100 em K.

Abaixo do pico anterior, o crescimento é inicialmente rápido e depois desacelera. Essa região côncava aproxima-se com cautela de um ponto em que já ocorreu congestionamento. Perto do pico há um patamar relativamente plano. Acima dele, a região convexa acelera para sondar a capacidade que pode estar disponível agora. Aos sete segundos, a curva do exemplo atinge cerca de 108,6 segmentos.

Explique a vantagem em relação ao RTT e seu limite

O Reno precisa de 50 RTTs para voltar de 50 a 100 segmentos: 5 s com RTT de 100 ms e 10 s com RTT de 200 ms. O tempo de retorno da curva cúbica depende do pico registrado e do tempo decorrido, portanto seu retorno em 4,22 s não depende diretamente da contagem de ACKs.

O CUBIC também calcula uma estimativa amigável ao Reno. Ele usa um aumento AIMD equivalente de cerca de 0,53 segmentos por RTT com fator de redução de 0,7, adotando essa estimativa quando ela supera o alvo cúbico. Caminhos com RTT curto podem, portanto, recuperar-se antes do tempo de retorno puramente cúbico. O crescimento baseado no tempo reduz uma fonte importante de favorecimento por RTT; ele não torna toda alocação real independente do RTT.

Ajuste o pico registrado

Se o congestionamento voltar a ocorrer abaixo do pico anterior, a convergência rápida do CUBIC reduz o Wmax registrado. Um novo evento em 90 segmentos após um pico anterior de 100 resulta em:

A janela imediatamente reduzida é de 63 segmentos. O pico registrado e a nova janela atual têm funções diferentes: um molda o crescimento futuro, enquanto a outra limita o envio atual.

O CUBIC continua baseado em perda, com ECN como sinal alternativo. Ele pode formar uma fila persistente em um caminho com descarte na cauda. A recuperação mais rápida e uma redução comum mais moderada melhoram o uso de caminhos com BDP grande, mas nenhuma das duas garante, por si só, baixo atraso de fila.

A perda não é o único sinal de um caminho congestionado. O atraso pode revelar dados enfileirados, enquanto as medições de entrega podem estimar a largura de banda que o caminho fornece. Vegas e BBR usam essas observações de maneiras diferentes.

Estime os dados enfileirados do Vegas

O Vegas compara uma taxa esperada baseada no RTT mínimo, o RTT de referência, com a taxa real baseada no RTT medido. A diferença entre elas, multiplicada pelo RTT de referência, estima os dados enfileirados do fluxo.

Com cwnd de 50 segmentos, RTT de referência de 40 ms e RTT medido de 50 ms, a entrega esperada é de 1.250 segmentos/s e a entrega real é de 1.000 segmentos/s. A estimativa da fila é:

O Vegas cresce abaixo de um limiar inferior e diminui acima de um limiar superior. Se o tráfego baseado em perda continuar enchendo a fila compartilhada, o Vegas observará repetidamente o atraso e reduzirá sua taxa, o que pode deixá-lo com uma pequena parcela.

Construa o modelo do BBR em duas partes

O BBR estima a largura de banda do gargalo a partir das taxas máximas de entrega recentes e o RTT mínimo por meio de um filtro de 10 s. O produto dos dois estima o BDP. Seu alvo ideal é um enlace ocupado com aproximadamente um BDP em trânsito e poucos dados enfileirados.

Uma estimativa de largura de banda de 50 Mbps e um RTT mínimo de 30 ms resultam em 1,5 milhão de bits, ou 187.500 bytes, por BDP. Um ganho típico de janela de congestionamento de 2 limita os dados pendentes a cerca de 375.000 bytes. A taxa de cadenciamento é um controle separado: ganho de cadenciamento vezes a largura de banda estimada. Um limite permite dados em trânsito; ele não exige que o remetente envie ao dobro da largura de banda.

Acompanhe os estados da versão 3 do BBR

O teste de crescimento de Startup é um crescimento da taxa de entrega inferior a 25% por três rodadas. ProbeRTT é programado no máximo uma vez a cada cerca de 5 s. No caminho do exemplo, ProbeBW Up tem como alvo 62,5 Mbps e Down, 45 Mbps. Esses detalhes da versão 3 são especificados no rascunho de internet do BBR, e não em uma RFC publicada sobre o BBR.

Compare os sinais e as vantagens e limitações

Reno e CUBIC aumentam até que perda ou ECN sinalize congestionamento. O BBR cadencia a partir de um modelo de largura de banda e RTT. Ele forma filas deliberadamente por pouco tempo em Startup e ProbeBW Up, portanto “baseado em modelo” não significa “nunca forma uma fila”.

A versão 1 do BBR praticamente ignorava perdas. A versão 3 usa perdas intensas, em torno de 2% em uma rodada, para limitar o excesso e melhorar a coexistência. Ela pode sustentar mais vazão em caminhos longos com perdas aleatórias, mas não consegue identificar perfeitamente por que um pacote foi perdido. Sua resposta específica à ECN permanece em aberto no rascunho; qualquer conexão que declare suporte a ECN deve responder a CE como congestionamento. A capacidade do buffer, o RTT, a versão e os algoritmos concorrentes continuam influenciando a equidade.

Um protocolo se ossifica quando dispositivos implantados dependem tanto de sua forma existente que as alterações se tornam difíceis de implantar. Dispositivos intermediários de rede inspecionam cabeçalhos TCP e podem rejeitar opções ou indicadores desconhecidos. Implementações baseadas no kernel também disseminam novos comportamentos por meio de atualizações do sistema operacional, muitas vezes lentamente.

Identifique os custos que o QUIC trata

O TCP evoluiu por meio de SACK, ECN, fator de escala da janela e novos controladores de congestionamento. Ainda assim, sua estrutura continua tendo importância para o tráfego web. Uma nova conexão convencional TCP com TLS precisa da negociação TCP antes da negociação TLS. Seu único fluxo ordenado de bytes também significa que um segmento faltante bloqueia a entrega dos bytes posteriores, incluindo dados de requisições não relacionadas. Esse é o bloqueio de início de fila no transporte.

Os endereços e as portas de uma conexão podem criar outro obstáculo quando um dispositivo muda de rede. O QUIC, padronizado na RFC 9000, altera essas partes do projeto de transporte enquanto carrega seus pacotes sobre UDP. O HTTP/3 funciona sobre QUIC.

Combine as negociações

O QUIC integra o TLS 1.3 à sua negociação de transporte. Em uma troca simples com RTT de 80 ms, processamento desprezível e nenhuma perda, uma nova conexão TCP com TLS 1.3 envia a requisição após duas idas e voltas e recebe os primeiros bytes da resposta após três: 240 ms. Uma nova conexão QUIC pode recebê-los após duas idas e voltas: 160 ms.

Uma conexão QUIC retomada pode enviar dados antecipados de aplicação em seu primeiro conjunto de pacotes, chamado 0-RTT. A primeira resposta pode então chegar após uma ida e volta, 80 ms neste exemplo. Dados antecipados podem ser repetidos por um atacante, portanto as aplicações os restringem a ações que podem ser repetidas com segurança. O termo 0-RTT descreve quando o envio pode começar, e não uma resposta instantânea.

Separe os fluxos, não todos os limites compartilhados

O QUIC transporta fluxos de bytes ordenados e independentes. Se um pacote contém dados da imagem 1, perdê-lo não bloqueia a entrega de dados já recebidos das imagens 2 e 3 em fluxos separados. Um pacote que transporta vários fluxos pode afetar cada um deles. Todos os fluxos ainda compartilham o controlador de congestionamento da conexão, portanto uma perda pode reduzir a taxa total disponível para eles.

O QUIC fornece entrega confiável de fluxos sobre UDP. Ele também fornece controle de fluxo tanto por fluxo quanto por conexão. O UDP transporta os dados, mas não substitui essas funções de transporte.

Proteja detalhes que podem mudar

O QUIC cifra as cargas úteis dos pacotes, incluindo todos os quadros de transporte. A proteção do cabeçalho cobre os números de pacote e alguns bits do primeiro byte. Campos necessários para roteamento e negociação, como IDs de conexão e versão, permanecem visíveis. Ocultar detalhes de transporte que podem mudar deixa menos comportamentos dos quais os dispositivos intermediários de rede possam depender.

Os IDs de conexão identificam uma conexão independentemente dos endereços IP e portas atuais. Com a validação do caminho, uma conexão pode migrar quando um telefone passa do Wi-Fi para o acesso celular, sem iniciar uma conexão completamente nova.

O QUIC geralmente é uma biblioteca no espaço do usuário. Uma atualização da aplicação pode, portanto, fornecer uma melhoria de transporte sem esperar que o kernel de cada sistema operacional seja alterado. Essa flexibilidade também atribui à aplicação a responsabilidade pela detecção correta de perdas, segurança, controle de fluxo e controle de congestionamento.

O QUIC melhora o que um remetente pode aprender com os reconhecimentos, mas ainda precisa evitar a sobrecarga do caminho. A RFC 9002 define a detecção de perdas e um controlador padrão semelhante ao NewReno. As implementações podem usar outros algoritmos adequados, incluindo CUBIC ou BBR.

Identifique cada transmissão

Os números de pacote aumentam e nunca se repetem dentro de um espaço de números de pacote. Dados reenviados trafegam em quadros dentro de um novo pacote com um novo número. Um ACK pode, portanto, identificar a transmissão que chegou, evitando a ambiguidade do TCP entre um segmento original e sua retransmissão.

Os quadros ACK informam os intervalos recebidos e o atraso de ACK do receptor. Após a negociação, o remetente usa um atraso de ACK validado e limitado ao ajustar as estimativas de RTT; ele não subtrai automaticamente um atraso arbitrário do receptor de cada amostra.

O QUIC declara um pacote perdido quando um pacote com número pelo menos três posições posterior é reconhecido, ou por meio de seu limiar de tempo quando um pacote posterior é reconhecido. O limiar de tempo recomendado é 9/8 do maior valor entre o RTT mais recente e o RTT suavizado. Um tempo limite de sondagem, PTO, envia sondagens que provocam reconhecimentos. A expiração do PTO, por si só, não reduz cwnd ao mínimo.

Defina limites de janela em bytes

Para um tamanho máximo de datagrama d, a janela inicial da RFC 9002 é:

Com d de 1.200 bytes, o resultado é 12.000 bytes. Com d de 1.500 bytes, é 14.720 bytes. A janela mínima de congestionamento é de dois datagramas de tamanho máximo, portanto esses caminhos têm mínimos de 2.400 e 3.000 bytes, respectivamente.

No controlador padrão, uma perda ou um novo sinal de congestionamento CE reduz cwnd pela metade, respeitando o limite mínimo, e define ssthresh como a janela reduzida. Um período de recuperação impede outra redução por perdas adicionais de pacotes enviados antes do início da recuperação. O reconhecimento de um pacote enviado durante a recuperação encerra o período. O remetente então retoma o crescimento normal.

Reconheça uma falha sustentada

O congestionamento persistente é uma evidência mais forte do que a expiração de um temporizador. Ele exige uma sequência suficientemente longa de pacotes perdidos que provocam reconhecimentos, sem nenhum pacote intermediário reconhecido e com uma amostra anterior de RTT. Seu limiar de duração é:

Com RTT suavizado de 100 ms, variação de 10 ms, atraso máximo de ACK de 25 ms e granularidade desprezível do temporizador, o limiar é 495 ms. O intervalo de perda que atende às condições deve exceder esse valor. O controlador então reduz cwnd para dois datagramas, sua janela mínima.

Mantenha úteis os sinais e o controle de tempo

Os ACKs do QUIC podem informar contagens cumulativas de ECT(0), ECT(1) e CE. Após validar o funcionamento da ECN no caminho, o remetente trata um novo aumento de CE como um evento de congestionamento sem precisar de perda de pacote.

O cadenciamento distribui as transmissões. Uma taxa em torno de 1,25 vez cwnd dividida pelo RTT suavizado é uma abordagem sugerida; limites de rajada podem cumprir a mesma finalidade. Enviar uma janela inteira de uma vez cria uma rajada mesmo quando a taxa média é aceitável. A implantação no espaço do usuário facilita a distribuição de novos controladores, mas cada pilha ainda precisa compartilhar a largura de banda de forma responsável.