[컴퓨터 네트워크] Chap3. Transport Layer(2)

아래는 연세대학교 컴퓨터 네트워크 수업(23-2)을 듣고 정리한 내용입니다.

(간략하게 정리하였기에 부족한 점이 있을 수 있습니다)

 

 

TCP seq. numbers, ACKs

sequence numbers

• 이제 보낼 segment의 data의 첫번 째 바이트 수를 넣어준다.

acknowledgements

• receiver가 sender에게 0~535까지 받았으니, 536을 acknowledgement field에 넣어서 보내는 것이다.
• 즉, 다음 번 내가 받아야되는 sequence를 넣어주는 것이다.

 

TCP round trip time, timeout

Timeout Value 설정하기

• RTT < timeout해야된다.
• RTT << timeout
  • segment가 loss 났을 때 빠른 재전송이 불가능하다.
• RTT >> timeout
  • premature timeout, 불필요한 재전송이 많아진다.

estimate RTT

• SampleRTT
  • 실제 측정한 RTT 값
  • segment가 전송이되고, ACK 값을 받아오기까지 걸리는 시간
• 평균 값을 활용한다.

 

EstimatedRTT = (1-a)EstimatedRTT + a*sampleRTT

(a = 0.125)

• EWMA: exponential weighted moving average
• 과거의 sample 값의 영향은 지수함수 형태로 빠르게 감소한다.

 

• Timeout interval
  • estimatedRTT + safety margin (4*DevRTT)
• DevRTT = (1-b)DevRTT + b|sampleRTT - EstimatedRTT|
  • b = 0.25
• DevRTT를 활용한다.
  • Current estimatedRTT와 Current SampleRTT을 활용한다.
• Exponentially weighted moving average

 

TCP reliable data transfer

• TCP는 IP의 unreliable 서비스 바로 위에 reliable data transfer 서비스를 구축한다.
  • pipelined segments
  • cumulative acks
    • ACK 사이의 갭이 있는 걸 못참아서 계속해서 required 이전 ACK를 보내는 것!
    • sender 입장에서 ACK 1,2,3이 안오고 ACK 4만 오더라도 receiver가 패킷 1,2,3,4를 정상적으로 받았다는 것을 알 수 있다
  • 하나의 재전송 타이머
• 재전송을 유발하는 요소
  • 타임 아웃일 경우
    • data loss
    • ACK loss
  • 동일한 ACKs가 반복해서 왔을 경우

 

TCP sender events

data received from app

• 시퀀스 number를 달아서 segment를 생성한다.
• unacked segment에 관련해서 timer를 실행해라 → TimeOutInterval을 활용!

Timeout

• timeout를 만든 segment를 다시 보낸다.
• 다시 타이머를 시작해라

ACK received

• 만약 unacked된 segment였다면?
  • ACK로 업데이트하기
  • 그리고 unacked된 것에 관해서 timer를 실행하기

TCP: retransmission scenarios

정상적인 경우

• sender가 seq=92, 8 bytes의 data를 보내면
• receiver는 ACK(다음에 받을거) = 100을 보낸다.

재전송

1. ACK가 없어진 경우 → timeout 이후에 재전송을 한다.
2. ACK가 도착하기 전에 timeout이 일어난 경우 → 재전송한다.
3. cumulative ACK
   • 내가 그 전의 ACK를 받지 않아도 이후의 ACK를 받았으면 receiver가 제대로 받았겠구나 싶은 것!
4. sender → receiver의 packet loss → time out

TCP ACK generation

• delayed ACK
  • 일정시간 동안 순서대로 받은 segment에 관해서 한번에 마지막 ACK만을 보낸다.
  • 이미 pending중인 segment가 있다면 바로 둘 다 ACK를 보낸다.
• 순서대로 들어오지 않는 segment가 있다면
  • 바로 duplicate ACK를 보낸다.
• gap을 채우는 segment가 들어온다면, 바로 ACK를 보낸다.

 

TCP fast retransmit

• time out까지 기다리기는 너무 시간이 오래걸린다.
  • 만약 packet loss가 일어났을 경우
• 따라서 duplicate ACKs가 3개 정도 오면 그냥 바로 패킷을 재전송한다.
  • receiver에게 뒤죽박죽으로 패킷이 도착할 수 있기에 바로 패킷을 재전송하기에는 무리가 있다!.. 

TCP flow control

• receiver의 기능이다.
• receiver가 app-layer에 올리는 속도가 받는 속도보다 느리면 buffer overflow가 발생할 수 있다. 따라서 이걸 receiver가 sender에게 말해서 관리한다.
• receiver에서 sender로 보내는 segment의 TCP header에 rwnd value를 넣어서 free buffer size를 알려준다.
• Network layer에게 받은 마지막 byte - App layer에게 보낸 마지막 byte = free buffer space
• RcvBuffer
  • 전체 buffer 사이즈 → 운영체제가 이걸 자동으로 조정한다.
• receiver의 rwnd value 를 통해서 sender는 window의 사이즈를 조정한다.
  • unacked된 data의 양을 제한한다.

3.6 principles of congestion control

• network가 핸들할 수 없을 정도의 데이터들이 너무 빠르게, 그리고 너무 많이 전달되고 있다.
• flow control과는 다르다.
  • flow control은 receiver가 핸들링하기 힘들어서
  • congestion은 network가 핸들링하기 어려워서
• 생기는 문제
  • 패킷 loss (router의 buffer가 overflow가 된다.)
  • 딜레이 문제(router의 buffer에서 queuing delay가 심해진다.)

 

Causes/costs of congestion: scenario 1

• 가정
  • 하나의 라우터(buffer는 무한), 두 개의 receiver
  • Output link capacity: R
  • 재전송 없음
• 최대 out throughput = R
• Input throughput이 R/2이 될수록, 딜레이는 매우 커지게 된다.
  • Queue가 매우 꽉차게 되므로.

 

Causes/costs of congestion: scenario 2

• 가정
  • 하나의 라우터(buffer는 유한)
  • time out된 패킷에대해서는 재전송을 진행한다.
• Out throughput = In throughput
• 그러나, loss가 되는 것이 있기에 재전송을 한다.
  • 단, sender는 없어진 것만을 보낸다.
  • 높아지면 높아질 수록 lost를 많이 하게 된다!.. → retransmission이 많아진다.

 

 

Causes/costs of congestion: scenario 2

• Realistic : duplicates
  • packet은 congestion에 의해서 lost가 될 수 있다.
  • premature timeout에 의해서 동일한 ACK가 전달될 수 있다.

 

congestion에 의해서 생기는 문제점

• goodput ⇒ 송신측으로부터 수신측에게 성공적으로 전송된 실제 데이터의 양을 의미한다.
• 재전송이 많이 일어나게 된다. → sender가 많은 일을 하게 된다.
• 불필요한 재전송이 많아진다. → link도 부하가 되게 많아진다.

 

 

Causes/costs of congestion: scenario 3

• 같은 router를 공유하고 있기에, 하나의 path의 congestion이 생기면 다른 host가 보내는 패킷이 drop될 수도 있다.
• upstream transmission capacity가 낭비될 수 있다.
  • 자신의 패킷이 낭비되는 지도 모르고 계속 패킷을 열심히 보낸다.

 

3.7 TCP congestion control

TCP congestion control: additive increase, multiplicative decrease

• sender는 자신의 window(transmission rate)를 올리고, 사용할 수 있는 대역폭을 계속 체크한다.(loss가 발생하기 전까지!)
  • additive increase: loss가 발견되기 전까지 매 RTT 동안 1MSS씩 cwnd를 증가시킨다.
  • multiplicative decrease: loss가 발견되면 cwnd를 바로 반으로 쪼갠다.

• cwnd는 window size라고 보면된다.
• sender는 전송 양을 제한한다.
  • LastByteSent - LastByteAcked ≤ cwnd
  • LastByteSent - LasyByteAcked → 내가 보낼 수 있는 양!..
• crwd는 계속해서 변화하고, network congestion의 함수이다.
  • network congestion은 loss된 패킷의 양을 통해서 확인할 수 있다.
• TCP sending rate
  • rate = cwnd / RTT bytes/sec

TCP Slow Start

• TCP 커넥션이 시작되면, 첫번 째 loss가 생기기 전까지 rate를 지수함수 형태로 증가시킨다.
  • 첫번째 cwnd = 1MSS
  • 매 RTT마다 * 2를 한다.
• 처음 시작하는 rate는 매우 느리지만, 지수함수형태로 빠르게 증가하게 된다.

TCP: detecting, reacting to loss

loss를 알아차리는 방법

• Timeout에 의해서 알아차리게 된다면
  • cwnd를 1MSS로 설정
  • window 사이즈는 slow start threshold까지 지수함수 형태로 증가하다가 linear하게 증가한다.
    • Slow Start와 AIMD의 혼합형!…
• TCP Reno
  • 3개의 ACKs를 받았음을 통해서 알아차리게 된다면
  • 그래도 3개의 ACKs를 받았다는 것은 그렇게 네트워크 상태가 안좋지는 않다는 것이다.
  • 따라서 cwnd를 1/2로 줄이고, linearly하게 cwnd를 증가시킨다.
• TCP Tahoe
  • 3개의 ACKs를 받았음을 통해서 알아차리게 된다면
  • 어떠한 상태의 loss이던 지 간에 cwnd를 1로 설정한다. → Slow Start
• 만약 바로 전에 loss가 되었던 value의 1/2 값에 도달하면(slow start threshold) slow start에서 linear하게 바꾼다.
• ssthreshold 설정
  • loss되기 직전의 crwd의 1/2 값이다.
• TCP Reno는 loss가 발생하면
  • 1/2 지점부터 시작한다.
• TCP Tahoe가 loss가 발생하면
  • 1부터 시작한다.

 

TCP throughput

• 평균적인 TCP througput을 window size와 RTT를 통해서 어떻게 구할까?
  • slow start는 무시하고, 항상 보낼 data가 있다고 가정해보자.
• W: loss가 일어난 window의 사이즈(bytes)
  • 평균적인 W 는 3/4W이다.
  • 평균적인 througput은 3W/4RTT(bytes/second)이다.

 

TCP Fairness

• fairness goal
  • K개의 TCP session의 bandwidth R인 link를 공유하면 각각의 평균 rate는 R/K가 된다.

 

 

Why is TCP Fair?

• AIMD에 의해서 점차점차 equal bandwidth share로 이동하게 된다.

 

 

+)

• multimedia app은 TCP를 활용하지 않는다.
  • congestion control을 하기를 원하지 않는다. → throttle이 걸리니까
• 그 대신 UDP를 활용한다.
• audio/video를 항상 같은 속도로 보내는 대신 packet loss를 감수한다.
• 단, TCP임에도 하나의 앱이 여러 TCP connection을 열게되면 fairness가 지켜지지 않을 수 있다.

 

Explicit Congestion Notification (ECN)

• network-assisted congestion control
• Network router에서 2 bit의 IP Header(ToS Field)에 congestion 여부를 적어서 보낸다.
• receiver는 sender에게 다시 보내는 ACK segment에 ECE bits를 설정해서 congestion이 일어남을 알린다.