Controle de Congestionamento
Video da aula estara disponivel em breve
Controle de fluxo vs. controle de congestionamento
Controle de fluxo protege o receptor de ser sobrecarregado. Controle de congestionamento protege a rede de ser sobrecarregada. Sao mecanismos diferentes que coexistem no TCP.
Diagrama
Controle de fluxo: Controle de congestionamento:
Remetente <--> Receptor Remetente <--> Rede
"Nao envie mais rapido "Nao envie mais rapido
do que EU consigo ler" do que a REDE aguenta"
Mecanismo: rwnd (receiver Mecanismo: cwnd (congestion
window) anunciada pelo window) estimada pelo
receptor no header TCP remetente
Janela efetiva = min(rwnd, cwnd)AIMD: Additive Increase, Multiplicative Decrease
O principio fundamental do controle de congestionamento TCP e o AIMD:
- Additive Increase: enquanto nao ha congestionamento, aumenta a janela (cwnd) linearmente — +1 MSS por RTT
- Multiplicative Decrease: quando detecta congestionamento (perda de pacote), reduz cwnd pela metade
Diagrama
cwnd
^
| /\
| / \ /\
| / \ / \ /\
| / \ / \ / \
| / \ / \ / \
| / \/ \ / \
| / \/ \
| /
| /
+──────────────────────────────────────> tempo
/ = additive increase (linear, +1 por RTT)
\ = multiplicative decrease (cwnd /= 2 em perda)
O padrao "dente de serra" e a assinatura visual do AIMD.Fases do controle de congestionamento TCP
1. Slow Start (inicio lento)
Comeca com cwnd = 1 MSS e dobra a cada RTT (crescimento exponencial). Continua ate atingir o ssthresh (slow start threshold).
2. Congestion Avoidance (evitar congestionamento)
Apos atingir ssthresh, o crescimento muda para linear (+1 MSS por RTT). E a fase "additive increase" do AIMD.
3. Deteccao de perda
- Timeout: perda grave. cwnd volta a 1 MSS, ssthresh = cwnd/2. Reinicia slow start.
- 3 ACKs duplicados: perda leve (fast retransmit). cwnd /= 2, ssthresh = cwnd. Vai para congestion avoidance.
Diagrama
cwnd
^
| ssthresh
| .......:....
| .....´ : \
| ...´ : \ 3 dup ACKs
| ...´ : \ (cwnd /= 2)
| ..´ : |
| ..´ : / Congestion
| .´ Slow Start : / Avoidance
| ´ (exponencial) : / (linear)
|´ : /
+──────────────────────────────:──────> tempo
^
ssthreshTCP Reno vs. TCP Cubic
Referencia
TCP Reno (classico):
- Slow start + AIMD
- Apos 3 dup ACKs: cwnd /= 2 (fast recovery)
- Apos timeout: cwnd = 1 MSS
- Recuperacao lenta em links de alta capacidade
TCP Cubic (padrao do Linux desde 2006):
- Funcao cubica em vez de linear para cwnd
- Mais agressivo em descobrir capacidade disponivel
- Melhor em links de alta largura de banda e alta latencia (BDP grande)
- W(t) = C * (t - K)^3 + Wmax
onde K = (Wmax * B / C)^(1/3), B = fator de reducao
TCP BBR (Google, 2016):
- Model-based: estima bandwidth e RTT da rede
- Nao usa packet loss como sinal de congestionamento
- Melhor performance em links com buffer bloatBufferbloat
Bufferbloat ocorre quando buffers excessivamente grandes em roteadores aumentam a latencia sem melhorar o throughput. Pacotes ficam parados em filas gigantes em vez de serem descartados (o que sinalizaria congestionamento ao TCP).
Paradoxo do buffer
Buffers maiores previnem perda de pacotes, mas causam latencia enorme. Buffers menores mantêm latencia baixa, mas podem causar mais perdas. A solucao moderna e Active Queue Management (AQM) — algoritmos como CoDel que descartam pacotes antes do buffer encher.
No harness.os
Diagrama
Controle de Congestionamento TCP Analogia harness.os
────────────────────────────── ──────────────────────────────────
cwnd (congestion window) Token budget por sessao
ssthresh Limite antes de reduzir agentes
Slow start Sessao comeca com poucos agentes
Congestion avoidance Cresce linearmente o paralelismo
Packet loss = congestion signal Token budget esgotado = signal
AIMD Adiciona agentes gradualmente,
reduz pela metade se budget estoura
Cenario concreto:
Orchestrator spawna 1 agente (slow start)
Agente completa rapido? Spawna 2 (exponencial)
2 completam? Spawna 4
Atingiu ssthresh (ex: 4 agentes)? Cresce +1 por vez
Budget estourou? Reduz para 2 agentes (multiplicative decrease)
Token timeout? Volta a 1 agente (reset)
Backpressure:
Muitos agentes concorrentes --> Neon connection pool saturado
--> Queries ficam em fila (bufferbloat!)
--> Aumenta latencia de todas as sessoes
--> Solucao: limitar agentes concorrentes (cwnd para agentes)Resumo
- Controle de congestionamento protege a rede; controle de fluxo protege o receptor
- AIMD: cresce linear, diminui pela metade — garante convergencia justa
- Slow start: crescimento exponencial ate ssthresh
- Congestion avoidance: crescimento linear apos ssthresh
- TCP Cubic (Linux default) e mais eficiente que Reno em links modernos
- Bufferbloat: buffers grandes aumentam latencia sem melhorar throughput
Exercicio pratico
Projete um mecanismo de controle de congestionamento para orchestracao de agentes harness.os.
- Defina o equivalente de cwnd (quantos agentes em paralelo)
- Defina o sinal de congestionamento (timeout? token budget? erro de Neon?)
- Implemente AIMD: como cresce o numero de agentes? Como reduz?
- Simule: 10 tasks, budget de 100K tokens. Quantos agentes em paralelo e otimo?
Verifique seu entendimento
No AIMD, o que acontece quando o TCP detecta congestionamento via 3 ACKs duplicados?