[Network] Congestion Control

Principles of congestion control 

flow control 과 다르게, core network의 문제를 추측해야 한다. 

core network의 혼잡이 발생하지 않게 해서, retransmit 을 줄이는게 목적이다. 

그러기 위해서는 보내는 쪽이 천천히 보내야 한다. 

 

troughput을 보장하기 위해서 slice window 기법을 사용하고, 클수록 좋긴하지만 congestion이 발생할 확률도 올라간다. 

들어가는 throughput을 람다 in 으로 하고, 나가는 것을 lambda out으로 한다. 중간 코어 네트워크에 문제가 생기면 보낸 애를 또 보내는 retransmition이 생긴다.

drop, time-out등의 이유로, retrasmit 발생한다. 이게 많을 수록, 원래 보내는 세그먼트 수가 줄어든다. 그러면 람다 out이, throughput이 줄어든다. 그래서 우리 목적이 retransmit을 줄이는거임.

 

처음에는 버퍼가 무한대라고 가정한다. 라이터에서 들어오는 링크, 나가는 링크를 2개의 호스트가 같이 사용하고 있다. 

각각 R / 2까지 람다 in 이랑 람다 out이랑 같게 사용하는 상황이다. 버스트한 특성 때문에 딜레이가 확 커진다. 

---

2번째 시나리오는 다음과 같다. 버퍼가 유한한 경우에는 drop이 발생하게 된다. 

 

만약에 보내는 쪽에서 속도를 조절하게 된다면,, 드롭이 발생하지 않는다. + retrasmit, time-out도 발생하지 않는다.

이 경우, 람다 in이랑 람다 프라임 in이랑 같게 된다. 

 

1.loss, 2. time-out

아래 경우, drop 될 수 있으니까 R / 2로 보내고 받는 R/3만 갈 수 있고 나머지는 retransmission 된다. 

 

2번째는 ack이 늦게 와서 time-out 돼서 duplicate 되는 상황이다.

 

“costs”of congestion:

• more work (retrans) for given “goodput”
• unneeded retransmissions: link carries multiple copies of pkt
• decreasing goodput

---

 

 

중간에  finite 저게 문제가 생기면 파랭이랑 연관된 왼쪽 라우

터 영향 받고, 그와 관련된 라이터 영향 받고, 전체적으로 다 영향을 받는다. 그래서 중요함. 

 

람다 아웃 4개의 은 평균이다. 

another “cost”of congestion:

when packet dropped, any upstream transmission capacity used for that packet was wasted!

 

저기 저 람다 in으로 유지하면 좋다. 절대 저길 넘으면 안 된다. 보통 2배로 증가시켜서 보낸다. 

 

end-end congestion control:

• no explicit feedback from network
• congestion inferred fromend-system observed loss, delay
• approach taken by TCP

network-assisted congestion control (이건 일반적인거 아니라고? ) 

• routers provide feedback to end systems

---

# TCP 7강 

 

TCP 헤더에서 rwnd로 flow 컨트롤을 할 수 있게 알려준다. cwnd도 지정해서 사용한다.

cwnd 어떻게 사용하는지 볼 예정이다. tcp는 기본적으로 aimd이다. 증가할 때는 선형적으로 감소는 지수적으로 한다. 

tcp의 기본이다. 여기는 중간부터 어떻게 변하는지 보는거야. 

 

간 보는거야. congestion이 발생했을 때, 확 감소시킨다. 처음에는 보내는 쪽이 cwnd 조정한다. 1 MSS는 슬라이딩 윈도우 크기의 기본 단위이다. 데이터를 보내고 받을 때, 슬라이딩 윈도우 크기 만큼 보내고, ack을 쭉쭉쭉 받는다. 처음 보냈을 때부터 ack 받을 때까지, RTT라고 부른다.  4개의 세그먼트를 한번에 보낸다고 생각하자. 그러면 다음에는 1 증가 시켜서 5개를 보내는 것이다. time out이 발생하면 반으로 줄여버리는거야. 다시 보낼 때 2개만 다시 보내. 

 

보내는 쪽 윈도우 사이즈랑 속도 조절이랑 상관이 있다. RTT에서 cwnd = 1 이면 하나 보내고 기다리고 하는거임.

 

 

그럼 위도우가 1이고 stop-and-wait 기법이다. 그럼 크다고 좋아? 그건 아니다. loss 생길 수 있잖아. 적당히가 중요함.

 

 

위에는 중간부터 본거고, 처음 시작할 때는, 1에서 시작하지만 2배로 증가한다. 그러면 언젠가는 time-out이 발생할 것이다.

 

time-out이 발생하면 그 때부터, 조금씩 늘려서 보내는거다. 그러면 구현할 때는, ack을 받을 때마다, 1 MSS 씩 증가시키면 다음에는 결국 2배가 되는거다. 그냥 2배가 증가하는데, 구현할 때, 그렇게 하겠다는거임. 이렇게 하는걸 slow start라고 한다. (개 빠른거 같은데;;)

 

처음 세그먼트 타임 아웃 하나가 발생해, 그럼 중복된 ack이 발생하겠지? 중복된 ack도 3개 이상이면 무시하잖아? 그니까, 4개를 보냈어도, 1개만 갔다고 생각했을 때, time-out이 생기는데, 그럼 다 같이 못간거야. duplicated 는 뒤에는 잘 간거다. 

 

처음에는, 둘 다 congestion 이라 했는데, 3번 중복된 ack을 받을 때, 중간에 하나만 이상한 것일 수 있으니 기회를 한 번 더 준다. 

문제 상황이면 반으로 줄인다. (아. 딴생각하다 못 들었다.) 초창기에는 time-out이 발생하면, 다시 1로 내렸다고 한다. 

 

slow start thres-hold 지나갔을 때는 조심 스럽게 본다. 1씩 증가시켜. 그러다가 time-out이 발생하면, 다시 1로 줄여서 증가해. 다시 2배로 증가 하고, ssthresh를 바꾼다. congestion 발생한 값의 반으로 줄인다. 

 

새로나운 TCP Reno에서는 1까지 안 내려가고, 1/2 지점부터 선형적으로 증가시킨다. 

3번의 ack을 받았을 때, 르노 방식으로 하는거야! 이걸 fast recovery라고 부른다. 

 

처음에 2배씩 증가하는게, slow start.

+1 증가하는게 congestion avoidance.

3번의 ack을 만났을 때, fast recovery 상태가 된다. 

MSS = 1560으로 나누기?

맨 앞에 대한 ack이 안 오고 중복된 ack이 오는 경우에, duplicated ack이 온다. 

시간이 지나서,,, 

처음에 대한 ack을 잘 받았을 때, 1 증가 시켜서 보낸다. new ack은 첫번째 세그먼트에 대한 ack이다. cwnd 모두 보내. 하나 잘 받았다면, 하나 더 보내. 증가 시켜서 2개 보낼 수 있는거야. 좀 복잡하넹.. 순서 바뀌어서 duplicated ack 이 하나씩 증가해? 뭔솔이야... time-out 발생하면 cwnd = 1 MSS로 다시 시작해. time-out이면 다시 보내니깐 dup ACK 은 0으로 만들어줘. 

 

아래 그림 이해하는게 중요하네!!! 

 

 

cwmd = cwnd + MSS * (MSS / cwnd) 이게 +1 하는거야. 아항. 

fast recovery는 무슨 상황이지? 1부터 다시 시작하는 상황이야. 이제 어떻게 동작하는지 이해해야 한다. 

우선 time-out 상황인 경우에, 다시 보냈는데도 timeout이 발생한거면 congestion이 확실한 상황이다! 

 

새로운 ack을 받았을 때는, 처음 ack을 잘 받았다는 이야기이다. 그럼 duplicated 되지 않고 잘 받았다는 거다. 

 

duplicate ack을 또 받았어? 맨 앞 친구 ack을 받아야 하는데, 또 뒤에 애들도 따라서 순서 바뀌어서 온거야. 

그럼 상태가 안 좋다기보다는 맨 앞에 ack만 잘 안 온거야. congestion은 아니고, 처음꺼만 missing 된거야.

이 경우는, cwnd 를 1 MSS 만큼 증가시켜. 이거 헷갈리니깐 잘 이해하렴.