network - transport layer(4)

* TCP Flow control(흐름 제어)

sender가 receiver의 buffer가 overflow 되도록 너무 빠르게 data를 전송하지 못하도록 하는것

(out-of-order segment는 버린다고 가정 

- TCP connection에서 수신측이 가용한 버퍼의 크기를 알려주어 흐름을 제어.

- application process가 수신 buffer로부터 data를 늦게 읽으면 RcvWindow가 줄어들수 있다.

- 흐름제어는 속도를 일치시키는 서비스(receiver쪽 application이 data를 읽는 속도와 sender의 전송)

- 버퍼내에 여유 공간 :  RcvWindow = RcvBuffer – [LastByteRcvd – LastByteRead]
- segment내에 RcvWindow size 를 저장 receiver가 sender에게 알려줌 

- sender는 RcvWindow크기보다 작은 확인 응답된 data량을 유지함으로써 수신 buffer에 overflow가 발생하지 않았음을
확신한다.

 

* TCP의 connection 관리

- recall(TCP sender와 receiver는 connection을 초기화한 다음 data segment을 전송)

- TCP 초기화 변수(sequence number, buffer, flow control 등의 정보. ex) RcvWindow) 

- client : connection initiator
- server : client의 접속을 승인

 

3 way handshake
step 1 : client가 server에게 TCP SYN segment를 전송
- 초기 sequence number 설정
- data는 들어있지 않음.

 
step 2 : server는 SYN를 수신 후 SYN-ACK를 전송
- server : 변수 및 buffer 할당(메모리를 할당 받는 것이기때문에 syn flood 공격의 여지가 있음) 
- server의 초기 sequence number 설정

 

step 3 : client는 SYN-ACK수신 후 ACK전송(data를 추가해도 된다.)
- client : 변수및 buffer 할당

 

closing a connection

- 창을 그냥 닫는 경우 FIN signal은 원래 전송되지 않지만 OS에서 보내주는 경우도 있음.

step 1

- client는 connection을 종료하기위해 FIN bit가 1로 설정된 TCP segment를 server에게 전달

 

step 2

- server는 FIN을 수신하면 ACK를 응답하고 connection을 종료한다는 FIN를 client에게 전송.

 

step 3

- client는 FIN을 수신하면 ACK를 응답하고 일정시간을 기다린 후(time wait) connection을 종료.

step 4

- server는 ACK를 수신하면 connection을 종료.

 

* congestion(혼잡)

- 많은 근원지에서 높은 전송률로 data를 전송하려고 하기 때문에 발생하는 문제
- flow control과는 다르다.

- packet 손실(router buffer의 overflow), 지연 증가(router buffer에서 queueing delay 증가) 현상 발생 

- sender에 의해서 조정하지만 실제 혼잡도를 조사 하는 것은 아니고 혼잡도를 조사하기 위해서는 네트워크 장치들의 협조가 필요(ATM처럼 혼잡도를 같이 보내주는 경우) 

- time out이 계속해서 일어나거나 재전송량이 증가(ack number 증가)하면 data 전송량을 줄인다.

 

congestion scenario 1

congestion scenario 1

상황

- 두개의 sender와 reciver
- 무한 버퍼를 가진 하나의 라우터
- 재전송은 없다.

 

문제점

- 혼잡시에 매우 큰 지연이 발생.
- packet의 처리량이 link의 용량에 접근하게 되면 매우 큰 queueing delay(큐잉 지연)가 발생.

- c는 switch에서 처리할 수 있는 packet의 총량

 

congestion scenario 2

congestion scenario 2

상황

- 유한 buffer를 가진 라우터

- 손실된 packet에 대한 재전송이 이루어짐.

congestion scenario 2

- 그림 a : 손실이 발생하지 않는 이상적인 경우 : λin = λout
- 그림 b : 손실된 packet만 재전송하는 완벽한 경우 : λ’in > λout 
- 그림 c : packet의 delay로 인한 불필요한 재전송으로 λ’in이 매우 커지고 λout이 더욱 감소.

- r은  switch에서 처리할 수 있는 packet의 총량

 

congestion scenario 3

- 4개의 sender
- 여러 개의 라우터와 다중 경로

- 라우터와 라우터 사이에서 패킷이 버려질 수 있음. 
- timeout시에 재전송

- λin 이나 λ’in 가 커지면 오히려 받는 data의 양이 급격히 감소

- window size의 크기를 계속해서 조절해서 λin이 너무 커지지 않도록 조절

 

* congestion control에 대한 접근 방법

end-end congestion control(종단간 혼잡제어)

- TCP가 사용하는 방식 

- network으로 부터 어떠한 feedback도 제공되지 않음.
- 손실, 지연등의 현상을 관찰해서 end system이 추측(정확히 알 수 없음) 

network-assisted congestion control(네트워크 지원 혼잡제어)
- router가 혼잡상태에 관한 정보를 sender에게 직접적으로 feedback 제공.
- 하나의 bit로 혼잡을 나타낸다.(SNA, ATM, DECbit…)
- 전송률을 sender에게 명확히 전달.
- 혼잡 data를 전송하는 방식은 router가 sender choke packet방식과 송신자와 수신자간의 packet의 field에 추가하는 두 가지 방식이 존재.

- TCP에서는 전혀 고려하지 않음.

 

ATM ABR 혼잡 제어

- 전화 기지국이 사용하는 방식

- source와 destnation은 ATM 장치.

- rm cell을 직접 끼워넣어서 전송.

 

* TCP congestion control(TCP 혼잡제어)

end-end control(종단간 혼잡 제어)만 사용

- network의 지원은 없음

 

sender의 전송량 제한

- LastbyteSend – LastbyteAcked ≤ CongWin(TCP 수신buffer가 충분히 큰 경우 : 혼잡 제어만 필요)
[≤ min{congWin(혼잡 제어), RcvWindow(흐름 제어)}]

송신률

- rate = CongWin(전송률, 혼잡 윈도우 크기) / RTT (byte/sec)

- RTT는 조절할수 없지만 CongWin은 조절이 가능함

- CongWin는 netwok 혼잡도에 따라 동적으로 변함.(가능한 최대한 늘리다가 문제가 발생할 경우 줄임)

 

congestion에 대한 sender의 반응

- 손실(timeout 또는 3번의 중복 ACK)이 발생하면 재전송 발생

- TCP sender는 손실이 발생하면 무조건 CongWin을 줄인다.

 

혼잡제어 알고리즘
- AIMD, slow start, timeout event에 대한 반응 3가지 모두 사용.

 

* TCP AIMD

multiplicative decrease
- loss event가 발생하면 CongWin의 size를 반으로 줄인다.
- 1MSS 이하로 떨어지지는 않는다.

additive increase
- 각 RTT마다 congWin의 증가폭이 1MSS가 되도록 조금씩 congWin을 증가.
- 이러한 선형 증가를 혼잡 회피.

 

* TCP slow start

- TCP 연결이 시작될때 CongWin의 크기는 1MSS로 초기화 되고 초기 전송률은 MSS/RTT.(시작할때도 1mss로 하고 무조건 1mss로 줄임)
ex)MSS(500byte), RTT(200ms)init rate = 20kbps
500byte/200ms = 4,000bit/0.2s = 20,000bps =20kbps

- MSS/RTT 보다 훨씬 큰 사용가능한 대역폭 
- 선형비율로 증가시키면 전송률이 적당한 수준에 오를때 까지 긴 지연이 초래되기 때문.

- 첫번째 loss가 발생할 때 까지 각 ack를 확인할때 마다 congWin을 1MSS만큼 증가 시켜 각 RTT마다 congWin이 두배가 되도록 한다.

 

congWin의 증가치

AIMD : 각 RTT마다 1MSS 증가 
Slow Start : 각 ACK마다 1MSS(= RTT마다 2배) 증가

 

* refinement

세 번의 중복 ACK 수신(빠른 재전송) 

- network가 대역폭 한계에 거의 도달했다고 판단

- CongWin은 반으로 줄어든다.
- Congwin은 선형적으로 증가한다.
- AIMD

 

timeout 발생

- 세 번의 중복된 ACK보다 심각하게 판단 

- CongWin을 1MSS로 줄인다.
- 지수적으로 CongWin을 증가 
- threshold(CongWin의 절반)에 도달하면 다시 선형적으로 증가(혼잡 회피에 들어감)

 

* TCP 혼잡제어 요약

- CongWin은 threshold에 도달 할때 까지 slow-start방식으로 빠르게 증가.
- CongWin이 threshold에 도달하면 혼잡회피를 위해 선형적으로 천천히 증가.
- 세 번 중복된 ACK가 감지되면 CongWin은 threshold까지 줄어들고 선형적으로 증가.
- timeout이 발생하면 CongWin은 1MSS로 줄었다가 다시 threshold에 도달할 때까지 빠르게 증가.