[네트워크]Principles of Congestion Control

정태규·2023년 5월 31일
0

네트워크

목록 보기
16/19

congestion

링크나 노드가 너무 많은 데이터를 처리하여 서비스 품질이 저하되는 경우이다.

  1. packet switching network 에서는 shared link에 있는 버퍼를 사용해서 paket을 저장하고 전달한다.

  2. 라우터가 처리하기에 소스들이 많은 데이터를 빠르게 보낸다. 당연히 라우터가 overflow된다.

congestion으로 생기는 현상

  1. router에서 버퍼가 overflow 되어서 패킷이 손실됨.
  2. 딜레이가 길어짐
  3. call blocking

congestion control의 목적

  • 성능이 급격하게 떨어지지 않도록 일정 수준 이하로 네트워크 성능을 유지하기 위함이다.

network 성능 측정

  1. (network)throughput
  • 네트워크에서 혹은 채널에서 성공적으로 메세지를 전달하는 속도
  1. (end-to-end)delay
  • source 에서 도착지까지 패킷 전달 지연 + 각 노드에서 처리와 대기 지연

congestion control이 없을때

  1. ideal case
  • buffer infinite
  • congestion control과 관련해 오버헤드가 없다.
  • throughput의 최대까지 올라가고 계속 유지됨.
  • bound가 없어서 network capcity를 초과하면 delay는 exponential 하게 올라간다.
  1. practical case

congestion collapse & avoidance

  1. congestion collapse

    traffic 증가 ->congestion->timeout->retransmission->congestion 증가
    -> more timeout -> more retransmission

  2. congestion avoidance

    congestion이 일어나기전에 control 한다.

congestion control을 통해 ideal한 상황근처까지 throuput을 유지한다.

congestion control

Implicit congestion control

  • packet이 loss나 delay가 나면 network layer에서 congestion이 발생했다고 생각하고 해결하려고 하는것.
  • TCP에서는 packet 손실이 congestion이 일어났다고 본다.

Explicit Congestion Control

  • router가 현재 congestion이 발생했는지 판단하고, end-system에 알려주게 된다.(feedback) feedback은 두가지 방향으로 갈 수 있게 만든다.
  1. BECN: 기존에 없던 패킷 만들어서 sender에게 congestion 발생 알려준다.
  2. FECN: sender에게서 온 패킷에 congestion이 발생했음을 알려주는 표시를 하고 receiver 쪽으로 흘린다. receiver가 sender에게 congestion 발생했음을 알린다.
    (ACK에 congestion 발생했음을 알린다.)

rwnd(receive window)

  • receiver buffer가 overloading 되는것을 막기위해 사용한다.
  • receiver buffer에서 남은 공간의 양이다.
  • 동적이다.
  • TCP flow control에 사용된다.

cwnd(congestion window)

  • TCP에서 데이터를 전송할 수 있는 최대 양을 제어하는 변수입니다. 네트워크 혼잡 상황에 따라 동적으로 조정된다.
  • TCP congestion control로 사용된다.

TCP flow control

  • host 기반이다.
  • receiver가 free buffer space(rwnd)를 알려주면 sender는 window size를 제한한다.

    (당연히 마지막으로 보낸 LastByteSent - 마지막으로 받은 LastByteAcked) window size의 크기가 rwnd 크기보다 작거나 같아야한다.

TCP congestion Control

  • host 기반
  • sender가 cwnd를 사용해서 자신의 전송속도를 제한한다.
    그러기 위해서 receiver의 상태를 확인하고 인지된 네트워크 congestion status를 확인한다.
  • window size is limited:

AIMD(additive increase multiplicative decrease)

  • cwnd는 동적이고, 네트워크 congestion을 인지하는 기능을 한다.
  • additive increase

    손실이 감지될때까지 모든 RTT마다 1 MSS씩 cwnd를 증가시킨다.
    *MSS : maximum segment size

  • multiplicative decrease

    손실 이후에는 cwnd를 반으로 자른다.



slow start

  • AIMD의 한계
    ✍️ linear한 additive increase는 맨처음 시작부터 최대로 확장시키기가 너무 오래걸린다.

  • 4개의 main TCP congestion control functions
    ✍️slow start(SS)
    ✍️Congestion Avoidance(CA)
    ✍️Fast Restransmit
    ✍️Fast Recovery

  1. connection이 시작되면, 첫번째 loss가 일어날때까지 기하급수적으로 속도가 증가한다. RTT마다 cwnd가 두배로 증가

slow start vs AIMD


cwnd가 증가하는 속도가 다르다.
AIMD는 1씩 증가 , slow start는 두배씩 증가

Congestion Avoidance(Tahoe)

  • ssThresh
    ✍️TCP에서 cwnd를 제어하기 위해 사용되는 값으로, 네트워크 혼잡 상황을 감지하면 cwnd를 줄이고 ssthresh로 설정합니다. 그 후, slow start 알고리즘 대신 congestion avoidance 알고리즘을 사용하여 cwnd를 증가시킵니다.

Fast Recovery(Reno)


TCP Tahoe vs TCP Reno

  • TCP Tahoe는 모든 전송을 중지하고 재전송하며, slow start 알고리즘으로 다시 시작합니다.
  • TCP Reno는 3개의 duplicate ACK를 수신했을 때만 전송을 중지하고, fast retransmit 알고리즘으로 재전송합니다.
  • TCP Reno는 fast recovery 알고리즘을 사용하여, 데이터 손실 후 slow start 알고리즘 대신에 congestion avoidance 알고리즘으로 cwnd를 증가시킵니다. 이를 통해 더 빠르고 안정적인 데이터 전송이 가능합니다.
    따라서, TCP Reno는 TCP Tahoe보다 더 효율적이고 빠른 데이터 전송을 할 수 있습니다.

TCP fast retransmit

3 duplicated ack를 받는상황

sequence를 보내다가 loss로 인해 delay가 되었고, seq4가 hostB(Receiver)로 이동하지못했다. host B는 seq4가 빠졌기 때문에 seq 5,6,7을 받아도 다시 ack4를 보낸다. 이렇게 똑같은 ack가 3번 쌓이면

  • TCP Tahoe는 cwnd를 1로하고 slow start를 시작한다.
  • TCP Reno는 cwnd를 cwnd/2+3으로 하고 fast recovery를 한다.

TCP Fairness

  • fairness goal
    만약 k개의 TCP session이 bandwith가 R인 하나의 bottleneck을 공유하고 있다면 각각의 TCP session은 R/k의 평균속도를 가진다.

0개의 댓글