컴퓨터 네트워크 3 : Transport Layer 2

LeemHyungJun·2023년 10월 31일
컴퓨터네트워크
0

Computer Network

목록 보기
4/8

5. Connection-oriented transport: TCP

<segment structure & reliable data transfer>

1. TCP overview

  • point to point (1:1 통신)
    • cf1) 1 : 모두 -> broadcast
    • cf2) 1 : 다수 -> multicast
  • reliable, in-order byte stream
  • full duplex data
    • 하나의 링크를 통해 데이터 보내고 받기 수행
  • cumulative ACKs
  • pipelining
    • congestion and flow control
  • connection-oriented
  • flow controlled

2. TCP segment structure

  • source port, dest port
  • seq #
  • ack #
  • checksum
  • receive window : for flow control
  • C,E : congestion 알려주는 것
  • data

3. TCP sequence numbers, ACKs

  • telnet?

4. TCP round trip time, timeout

  • timeout값을 정하는 기준
    • RTT의 평균보다는 큰 값
    • 너무 작으면 성급한 timeout 발생
    • 너무 크면 반응이 느려짐
  • RTT 측정
    • sampleRTT : segment를 받은 시간부터 해당 segment에 대한 ACK이 오기 전까지 시간
    • sampleRTT는 불규칙하다!
    • 해결 : sampleRTT의 평균치 구하기 -> EstimatedRTT
  • EstimatedRTT
    • EstimatedRTT=(1−α)∗EstimatedRTT+α∗SampleRTTEstimatedRTT=(1-\alpha)*EstimatedRTT + \alpha*SampleRTT
  • exponential weighted moving average (EWMA)
    • 최근 sample에 대한 값의 우선순위 주기!
    • 더 smooth 한 결과를 얻을 수 있다.
  • timeoutInterval
    • TimeoutInterval=EstimatedRTT+4∗DevRTTTimeoutInterval = EstimatedRTT+4*DevRTT
    • 4*DevRTT는 safety margin (여윳값)
  • DevRTT(RTT변화율, 표준편차)
    • DevRTT=(1−β)∗DevRTT+β∗∣SampleRTT−EstimatedRTT∣DevRTT = (1-\beta)*DevRTT+\beta*|SampleRTT-EstimatedRTT|
    • sample이 평균으로부터 얼마나 떨어져있는가..

5. TCP sender

  • application으로 부터 data받기
  • timeout
  • ACK received

6. TCP receiver

  • arrival in-order
  • out of order

7. TCP: retransmission scenarios

  • lost ACK
  • premature timeout
  • cumulative ACK covers for earlier lost ACK

<flow control & connection management>

8. TCP flow control

  • Congestion control 이랑 다른것
  • 수신하는 application의 읽는 속도와 송신자가 전송하는 속도를 같게 하는 것
  • TCP segment structure에 존재하는 receive window 사용
  • 과정
    • receive window는 수신측에서 가용한 버퍼 공간이 얼마인지 송신자에게 알려준다.
    • 수신자는 수신 받을 것이 생기면 수신 버퍼(RcvBuffer)를 할당한다.
    • 수신버퍼에 저장된 번호 - 버퍼로부터 읽은 번호 <= RcvBuffer 인 경우를 유지해서 넘치지 않게 한다.
    • rwnd = RcvBuffer-(수신버퍼 저장된 번호 - 버퍼로부터 읽은 번호) 수식을 만족하는 동적인 공간이 존재한다.

9. TCP connection management

  • 데이터를 교환하기 전에 sender와 receiver가 handshake 하기
  • 2-way handshake 쓰면 안되는 이유
    • variable delay
      • client는 timeout 발생했지만, server는 응답을 보낸경우 -> half open 상태
    • message loss & reordering
    • client와 server는 각자 다른 쪽의 상태를 모른다.
  • 3-way handshake과정
    • SYN이라는 1비트 보내기(sent 상태), client_isn 선택하여 seq #에 넣기
    • server host는 TCP SYN 추출 / 다시 응답을 보낼때 SYN은 1로(receive상태) seq#는 server_isn으로 ACK#을 client_isn+1로 설정해서 보낸다.
    • 다시 client가 응답을 받으면 SYN은 0으로 seq#는 client_isn+1로 ACk#은 server_isn+1로 설정한다.

6. Principles of congestion control

1. introduction

  • congestion : network가 처리하기에 너무 많은 양의 data가 들어옴
  • long delay
  • packet loss

2. Causes/cost of congestion

1. scenario 1: 2개의 송신자와 무한 버퍼 라우터 하나

  • packet 손실 x, 라우터의 용량 R, throughput R/2
  • 링크를 둘이서 공유해야 하므로 R/2가 최대 값
  • packet이 불규칙적으로 들어오는 경우 R/2 부근에서 지연이 무한대가 된다.

2. scenario 2: 2개의 송신자, 유한 버퍼 라우터

  • retransmit lost, time-out packet
  • 버퍼가 가득찬 상황에서 도착한 패킷은 버려짐 -> 재전송 필요
  • 재전송을 하게되면 보내야 하는 양이 늘어남
  • 종류
    • perfect knowledge
    • some perfect knowledge
      • retransmissions 때문에 끝에서 꺾인다.
    • un-needed duplicates

3. scenario 3: 4개의 송신자, 유한 버퍼 라우터, 멀티홉

3. Approaches towards congestion control

  • congestion에 대한 정보는 network 계층이 가장 잘 안다. 그러나 network 계층은 혼잡 처리에 대해 아무일도 하지 않는다. -> host가 혼잡제어 하기
  • End-End congestion control
    • network 계층의 피드백 없는 경우
    • RTT나 timeout을 통해 추론하기
  • Network-assisted congestion control
    • router가 최소한의 피드백을 전해준다.
    • ex) TCP ECN

7. TCP congestion control

1. TCP congestion control: AIMD

  • Additive Increase Multiplicative Decrease
  • Additive Increase
    • 시간에 따라 선형적으로 네트워크에 주입되는 data양을 늘리기
    • AI 수행 후 MD 수행
  • Multiplicative Decrease
    • 혼잡이 생긴 부분에서 data양을 확 줄이기
    • MD 수행 후 다시 AI 수행

2. TCP overview

  • TCP 혼잡의 증상
    1) timeout (2번보다 심각한 문제)
    2) 3 duplicate ACKs
  • TCP Tahoe
    • 가장 초기의 TCP
    • TCP혼잡 증상인 1,2에 대해 모두 동일하게 처리
    • sending rate를 1로 돌아가서 다시 올라오기
  • TCP Reno
    • 1의 경우는 Tahoe처럼 처리
    • 2의 경우는 congestion 값 * 0.5에서 다시 시작하기

3. TCP congestion control: details

  • CWND : receiver에 상관없이 sender가 보낼 수 있는 최대 값
  • TCP rate (throughput) = CWNDRTTbytes/sec\frac{CWND}{RTT}bytes/sec
  • (LastByteSent - LastByteACKed) <=CWND

4. TCP slow start

  • TCP rate를 1->2->3->4-> ... 올리면 너무 오래걸리기때문에 지수 형태로 1->2->4->8->... 로 올리기
  • slow start의 threshold (SST)는 지수형태로 올라가다가 AIMD로 바뀌는 지점이다.

5. TCP: from slow start to congestion avoidance

  • 위 그림에서 Reno는 round 9 에서 cwnd 9에서 부터 시작해야함!! - 그림 틀렸음
  • if) duplicate ACK 상황에 12에서 congestion 발생
    • 위의 그래프에서 Tahoe인 경우 1로 내려가서 slow start로 다시 시작후 SST가 6이므로 이때부터 AIMD 수행
    • Reno인 경우 6에서 다시 시작 SST가 6이므로 바로 AIMD 수행

6. summary: TCP congestion control

7. TCP CUBIC

  • TCP Reno의 다음 버전 (Linux의 default)
  • 한번 혼잡이 발생한 이후 가까운 다음 시점에도 혼잡 발생한 시점이 비슷할것이기 때문에 최대 window size(W_max) 까지는 급격하게 올리고 근처에서 천천히 올리기
  • bottleneck link : data가 전송이되는 링크는 항상 혼잡하지 않아야 한다

9. Delay-based TCP (TCP Vegas)

  • just full enough, but no fuller!
  • bottleneck link가 넘치치 않을 정도로 바쁘게 하기
  • Throughput = CWNDRTTmin\frac{CWND}{RTTmin} : 혼잡하지 않을때 처리율
  • ex) BBR

10. Explicit congestion notification (ECN)

  • network로 부터 congestion에 대한 정보 받아오는 방식
  • TCP segment에 존재하는 C,E field 이용
  • 여기서 congestion 하다는 정보는 주지만, 이에 대한 처리는 각자 다른 방식으로 하는것

11. TCP fairness

  • bottleneck router capacity이 R이고 TCP session이 K개 있다면 하나당 R/K의 속도 가진다.
  • TCP는 fair 하다! -> 아래의 그림으로 증명
  • 위의 그림을 통해 어떠한 곳에서 시작해도 결국 bandwidth 가 같은 선위로 가게 된다. (AIMD로 동작하는 것)

12. must all network apps be fair?

  • UDP는 fair 하지 않음
  • TCP가 fair 하다는 것은 host 기반으로 봤을땐 fair하지 않음

8. Evolution of transport-layer functionality

1. QUIC: Quick UDP Internet Connections

  • TCP와 UDP의 중간 지점
  • application layer에 QUIC라는 protocol을 올림 (아래 오른쪽 그림)
profile
LeemHyungJun
이전 포스트

컴퓨터 네트워크 3 : transport layer 1

다음 포스트

컴퓨터 네트워크 4 : Network Layer

0개의 댓글