Transport-layer services

Transport layer

Network layer: host 간의 logical communiction 제공

• 각기 다른 호스트에서 동작하는 애플리케이션 프로세스 간의 logical communication(논리적 통신) 제공
  • 송신 측: application layer 부터 수신한 메세지를 segment로 분해 및 헤더 추가하여 network layer로 보냄
  • 수신 측: 데이터그램으로 부터 세그먼트를 다시 조립하고 application layer로 보냄
• 애플리케이션에서 하나 이상의 transport protocol을 사용할 수 있다
  • ex) 인터넷: TCP, UDP

example

• 앤의 12명 애들이 빌의 12명 애들한테 메세지를 보내는 경우
• host(end system): 집
• processes: 애들
• app messages: 편지
• transport protocol: 앤과 빌이 집에서 애들한테 편지를 배분하는 것
• network layer protocol: 우체국 서비스

Transport layer protocols

1. TCP (Transmission Control Protocol)
   • connection-oriented and reliable
   • in-order delivery
   • congestion contro
   • flow control
   • connection setup
2. UDP (User Datagram Protocol)
   • connectionless and unreliable;
   • unordered delivery
   • no-frills extension of “best-effort” IP
   • fast because no acknowledgments are used,
   • less traffic is sent across the network

• 역할
  • TCP/UDP
    • Segmentation and Reassembly: 메세지를 segment로 분할하고, datagram을 segment로 조립
    • 서로 다른 응용 프로그램 식별 (port number)
  • TCP only
    • 어플리케이션에서 source host와 destination host간의 개별 통신 추적
    • 대화 제어: session 설정, reliable delivery, same order, flow control

Multiplexing and Demultiplexing

• transport layer muliplexing(다중화)와 demultiplexing(역다중화)
• TCP와 UDP의 서비스 모델
• Network layer가 제공하는 호스트 대 호스트 전달 서비스에서 호스트에서 동작하는 애플리케이션에 대한 프로세스 대 프로세스 전달 서비스로 확장하는 과정

Multiplexing

• 출발지 host에서 소켓으로부터 데이터를 모아 이에 대한 세그먼트를 생성하기 위해 각 데이터에 헤더 정보로 캡슐화(encapsulation)하고, 그 세그먼트들을 네트워크 계층으로 전달
• 위에서 아래로 (정보들이 캡슐화됨)

Demultiplexing

• transport layer의 세그먼트 데이터를 올바른 소켓으로 전달
• 아래에서 위로

Multiplexing의 요구사항

1. 소켓은 유일한 식별자를 가짐 (port number)
2. 각 세그먼트는 세그먼트가 전달될 적절한 소켓을 가리키는 특별한 필드를 가짐

Port number

• 각 애플리케이션(프로세스)는 자신의 end system 내에서 고유한 port number를 가짐
• port number는 다양한 애플리케이션 프로토콜을 구분해냄
• IANA(Internet Assigned Numbers Authority)가 port number를 할당

UDP/TCP segment format(형식)

• 각 segment는 source port number field(출발지 포트 번호 필드), destination port number field(목적지 포트 번호 필드)를 가짐
• 각 port number는 16비트 수 (0 ~ 2^16-1)

(UDP) Inversion of source and destination port number

• B가 A에게로 segment를 보낼 때,
  • B->A 세그먼트의 목적지 포트 번호는 A->B 세그먼트의 출발지 포트 번호
• source port number: 송신 호스트의 앱 프로세스와 관련된 번호
• destination port number: 원격 호스트의 목적지 프로세스와 관련된 번호
  

(TCP) Concurrent server

• 여러 동시 TCP 연결을 지원할 수 있는 서버
• 각 연결은 고유한 네 개의 튜플로 구별됨 <source IP addr, source port num, dest IP addr, dest port num>
• 서버는 각기 다른 클라이언트가 보낸 segment를 source IP addr와 source port num로 구분한다

• 같은 목적지 포트 번호(80)을 이용하는 두 client
  • host C가 서버 B로 2개의 HTTP 세션 시작
  • host A가 서버 B로 1개의 HTTP 세션 시작
• 각 호스트와 서버는 각자 유일한 IP 주소를 가진 모습
  

1. UDP (User Datagram Protocol)

• Transport layer 프로토콜이 할 수 있는 최소 기능으로 동작
  • Multiplexing and Demultiplexing 기능
  • 간단한 오류 검사 기능

features

• "no frills", "bare bone": 최소한의 프로토콜 기능만을 제공
• 장점
  • connectionless: 연결 설정 과정(handshaking) 없이 데이터 송신, 각 segment는 독립적 -> 연결 설정을 위한 어떤 지연도 없음
  • Fast: congestion control(혼잡제어)이 없어 데이터를 원하는 속도로 보낼 수 있음
  • Low overhead: UDP 헤더는 작고 네트워크 관리 traffic이 없음
• 단점
  • "best effort": UDP segment가 유실되거나 순서가 바뀔 수 있음
  • congestion control(혼잡제어)가 없어 라우터에 packet overflow가 발생하고 소수의 packet만 통과(유실)

key application

• Streaming multimedia apps (손실 허용, 속도 민감)
• Domain Name System (DNS)
• Simple Network Management Protocol (SNMP)
• Dynamic Host Configuration Protocol (DHCP)
• Routing Information Protocol (RIP)
• Trivial File Transfer Protocol (TFTP)
• IP telephony or Voice over IP (VoIP)
• Online games

reliable transfer in UDP

• UDP에서 reliable transfer 하고싶다면 애플리케이션 자체에서 신뢰성 제공 필요
  • application layer에 신뢰성 기능 구현 (add function on reliability)
  • application별 오류 복구 메거니즘

UDP segment (header) structure

• 8 bytes로 구성
• field
  1. Source Port
  2. Destination Port
  3. Length (header+data의 segment 길이; byte)
  4. Checksum (for error detection)

Checksum

• 전송된 segment에서 오류(flipped bits)를 감지
• sender
  • segment 내용을 16비트 정수의 sequence로 처리
  • segment 내용의 1의 보수 합을 UDP segment의 checksum field에 삽입
• receiver
  • checksum을 계산하여 checksum의 field value와 같은지 확인
    • 일치: 오류 없을 가능성 큼
    • 불일치: 오류
• example
  • parameters
  1. 16bit 이진수로 변환
  2. pseudo header, UDP header, UDP data 전부 더하고 carry를 계산한 뒤, 1의 보수를 적용하여 check sum을 구함
  3. checksum field에 삽입
  4. error detection
  • no error: checksum이 모두 0인 경우
  • error: checksum이 모두 0이 아닌 경우

2. ARQ (Automatic Repeat reQuest)

• reliable data 전송은 application, transport, link layer에서 중요한 역할
• TCP는 transport layer에서 논리적인 신뢰성 있는 연결을 위해 사용되며 ARQ 체계를 활용한다

• 데이터 전송 중에 발생하는 오류에 대응하기 위한 메커니즘

1. Error detection
   • checksum 사용
2. Receiver feedback (수신자 피드백)
   • 송신자는 각 패킷에 일련 번호를 할당하고, 수신자는 수신한 패킷에 대한 확인 신호를 송신자에게 반환
     • ACK(Positive Acknowledgment): 패킷을 정상적으로 수신한 경우
     • NAK(Negative Acknowledgment): 패킷에 오류가 있는 경우
3. Retransmission (재전송)
   • NAK를 받는 경우, 송신자는 해당 패킷을 재전송하고, 수신자는 중복 패킷을 삭제한다. (상위 계층으로 보내지 않는다)

Timeout Mechanism

• lose packets에게 checksum, ACK, retransmission은 좋지만 부족하다
• Timeout mechanism은 송신자 하나의 패킷을 보내고 ACK를 기다리는 "합리적인" 시간을 설정하고, 이 시간 내에 ACK를 수신하지 못하면 retransmission

Stop-and-Wait ARQ

Operation

• Sender
  • 하나의 패킷을 보내고 timer 시작
  • 수신자로부터 ACK 기다림
  • timeout 시간 내에 ACK를 받지 못하면 retransmission
• Receiver
  • 패킷을 정상적으로 수신하면 ACK 전송
• 만약 송신자/수신자 양쪽에서 패킷이 손상된 경우 버림
• 0과 1을 번갈아 가며 사용 (ack0 for pkt0, and ack1 for pkt1)
  
  
• packet을 보낼 때 loss
• ACK 오다가 loss
• ACK가 timeout 지나고 와서 ACK가 중복되는 경우 (delay ACK)

Utilzation

• 송신자가 비트를 전송하는데 실제로 사용하는 시간의 비율 (오류 없다고 가정)
• 실제로 데이터를 전송하는데 사용하는 시간과 전체 시간 간의 비율(L: bits, R: bits/sec)
  
  
• example(Utilization의 의미는 효과적인 처리량을 나타냄)

properties

• 장점
  • simple
  • 큰 프레임으로 전송하는 메세지에 대해 효과적
• 단점
  • 매우 높은 데이터 전송 속도이거나 sender와 receiver사이의 거리가 너무 먼 경우에 부적합 (비효율적) -> sol: pipelined protocol
  • link 활용도의 비효율성 (너무 큰 낭비)
• Stop-and-Wait ARQ는 간단하고 작은 규모의 통신에 유용함!

Pipelined ARQ

• 순서를 매긴 여러 패킷들이 ACK수신 필요 없이 전송될 수 있는 프로토콜
  • 각 패킷은 sequence number를 가지고 field 크기(k)로 제한됨
    • sequence number의 범위 [0, 2^k-1]
    • sequence number는 이 범위를 순환하며 증가 (0, 1, 2, ..., 2^k-1, 0, 1, 2, ...)
  • 최대 window(ACK없이 동시에 보낼 수 있는 frame) 크기(N)은 2^k-1
    • 수신자는 N 길이의 버퍼를 가짐
    • 송신자는 확인 응답 없이 최대 N개의 패킷을 전송할 수 있음
• stop-and-wait vs pipelined

sliding window

• ACK는 다음 패킷의 번호를 포함 -> cumulative(누적) ACK
  • 1~5 패킷을 올바르게 받으면 다음 패킷은 6번 정보를 포함한 ACK를 전달
    -> 송신자가 다음에 보내야할 패킷의 번호를 알 수 있음
    -> Window가 오른쪽으로 sliding하며 움직임
• 송신자의 입장 diagram (누적 ACK로 window가 어디로 sliding해야하는지 알 수 있다)

Operation

1. window initialize
2. ACK수신 전까지는 window가 줄어들며 패킷 전송
3. 누적 ACK를 수신하면 window가 해당 패킷으로 이동하며 원래 크기 되찾음

Go-Back-N (GBN) ARQ

• sliding window를 기반으로 동작하는 에러 제어 메커니즘

Operation

• ACK만 사용 (NAK 사용 안함)
• Sender
  • ACK없이 N개의 패킷 보낼 수 있음 (pipelined protocol)
  • 중복 ACK는 무시
  • 가장 오래된 미확인(unACKed) 패킷에 대한 타이머 가짐
  • Timeout되면 모든 미확인 패킷 재전송
• Receiver
  • cumulative ACK로 응답
  • gap(중간에 패킷이 손실된 경우)이 있는 패킷은 확인 안함 -> discard(2번 패킷을 못받아서 다른 패킷들이 와도 무시하고 다음 패킷이 2번이라는 ACK만 계속 보내니까 나머지 패킷들은 gab이 생겨 버려짐, timeout돼서야 2번 패킷이 와서 정상 동작)

Utilization

문제점 (drawback)

• 패킷이 하나만 잘못되어도 window를 재전송하므로 많은 패킷들이 재전송됨
  -> sol: SR ARQ

Selective Repeat (SR) ARQ ⭐

• window + buffer를 통해 패킷을 개별적으로 ACK할 수 있다
• GBN과 달리 buffer를 통해 손실된 패킷을 고를 수 있다

Operation

• ACK만 사용 (NAK 사용 안함)
• SR receiver
  • 올바르게 수신된 패킷을 개별적으로 확인 (individually acknowledges)
  • 필요한 경우 상위 레이어로 순서대로 전달하기 위해 패킷을 buffer에 저장
• SR sender
  • 각각의 미확인 패킷에 대한 타이머 가짐
  • Timeout 시 해당 패킷만 재전송
• window size
  • window 크기에 따라 송신자는 최대 N개의 미확인 패킷을 pipeline에 가질 수 있음

SR Sender

1. 상위 레이어로 부터 데이터를 받음
   • window 내에서 다음 사용 가능한 시퀀스가 있다면 segment 전송
2. 타임아웃 된 segment(n)를 재전송하고 타이머 재시작
3. 수신된 ACK 확인
   • ACK(n)이 [sendbase, sendbase+N] 범위 내에 있을 경우
     -> segment(n)을 수신한 것으로 표시
     -> n이 가장 작은 미확인 segment라면 window를 다음 확인되지 않은 번호로 이동

SR Receiver

• n이 [rcvbase, rcvbase+N-1] 범위 내에 있을 경우
  • segment(n) 수신
  1. out-of-order: segment가 순서대로 수신되지 않은 경우 버퍼에 저장
  2. in-order: segment를 받고 버퍼에 저장했던 segment도 순서대로 가져옴, window를 수신되지 않은 segment로 이동
• n이 [rcvbase-N, rcvbase-1] 범위 내에 있을 경우
  3. ACK(n)을 전송, 이미 확인했더라도 재확인함
• n이 범위 바깥에 있는 경우 -> 무시
  

문제점(dilemma)

• receiver의 입장에서 sender가 어떻게 보내는지 알 수 없음
• 이름이 겹치면 timeout인지 새 패킷인지 구분 불가 (naming convention)
  • ex) seq filed size(k) = 2 -> seq: 0, 1, 2, 3, 0, 1, 2, ...
  • 수신자가 0, 1, 2, 3번 패킷을 잘 받았으면 그 다음 오는 packet은 처음 보는 0번 패킷일텐데
  • 수신자가 다 못받은 경우, timeout으로 packet들을 다시 보낼텐데
  • 두 상황의 0번 패킷을 구분 못하는 경우
• 또한, window 크기가 크면 windoow 안에 같은 숫자가 있어 겹칠 수 있다 (overlap)
  -> SR ARQ에서는 window size는 sequence number space 크기의 반보다 작거나 같도록

3. TCP (Transmission Control Protocol

TCP Connection & Segment structure

TCP features

• connection-oriented: 데이터 교환 전 3-way handshake
• reliable, in-order byte steam
• point-to-point: single sender/receiver 간의 연결 (멀티캐스팅 X)
• full duplex service: 양방향 데이터 흐름을 동시에 처리 가능
• pipelined: GBN과 SR ARQ를 혼합한 방법 사용
• flow controlled: 수신자가 overwhelm되지 않도록 데이터 전송 조절
• MSS (Maximum Segment Size)
  • TCP segment에서 App layer의 최대 data size
  • a segment = TCP/IP header + segmented data at MSS
  • MTU (Maximum Transmission Unit)
    • = MSS + TCP/IP header length
    • link-layer frame의 최대 크기
  • ex) Ethernet과 PPP, MTU= 1500byte -> MSS=1460byte

TCP segment structure

Sequence and Ack. numbers

• Sequence number
  • segment의 첫번째 byte
• Acknowledgement number
  • 수신받은 seq 다음에 받을거라고 예측되는 seq <- cumulative ACK로 알 수 있는 수
• Piggybacking
  • TCP troughput 성능 개선을 위해 seq num과 ack num을 동시에 송신
  • ack num와 seq num이 데이터와 함께 TCP segment에 실림

Round-Trip Time and Timeout

Round-Trip Time (RTT)

• 데이터가 송신되고 이에 대응하는 acknowledgement를 수신하는 데 걸리는 시간 간격
• 네트워크 상황에 따라 변함
• TCP timeout값은 어떤 기준으로 설정?
  • RTT보다 길어야하지만, RTT는 유동적
  • 너무 짧으면, 일찍 timeout이 돼서 불필요한 재전송이 많아짐
  • 너무 길면, segment 손실에 대해 반응이 느리고 불필요한 대기 시간 발생
    -> RTT 예측 필요

RTT Estimation

1. SampleRTT: actual time, real value (변함)
2. EstimatedRTT: EWMA를 사용해서 "smoothed"된 sampleRTT 값
   • EWMA(Exponential Weighted Moving Average)는 sampleRTT의 가중 평균을 계산
   • 예전 샘플보다 최근 샘플에 높은 가중치를 줘서 현재 네트워크 상의 혼잡을 잘 반영하도록 함
   • estimate는 얼추 sample의 평균이지만, sample이 많을 수록 더 smooth할 것
3. DevRTT
   • RTT의 변화율 (sampleRTT와 EsimatedRTT 차이의 EWMA)
     -> safety margin (안전 여유 시간)
   • sampleRTT가 EstimatedRTT로부터 얼마나 많이 벗어나는지
   • EstimatedRTT의 변동이 크다면, TCP는 safety margin을 크게 가져야함
4. Timeout interval

Reliable Data Transfer

• TCP는 IP의 unreliable service위에 RDT 서비스 생성
  • pipelined segment
  • cumulative ACKs
  • single retransmission timer
• TCP retransmission
  • timeout이 발생할 때
  • 중복 ACK를 받았을 때 -> fast retransmit
• single retransmission timer
  • 단일 재전송 타이머는 타이머 관리의 overhead를 줄임
  • 단일 타이머는 oldest unacked segment를 확인

TCP Sender event

1. TCP에서 데이터가 애플리케이션으로부터 수신
2. 해당 데이터에 seq를 포함한 segment 생성
   (seq는 segment의 첫번째 data byte 의 byte-stream number)
3. 타이머가 실행 중이 아니면, oldest unacked segment 기준으로 타이머 시작
4. Timeout 발생
   • oldest unacked segment 재전송
   • Timer 재시작
5. ACK 수신
   • ACK가 이전 unacked segment를 확인하면 송신자는 해당 segment의 정보를 업데이트
   • unacked segment가 여전히 존재하면 그거의 타이머 시작

Scenarios

• LostACK

  • A가 B에게 segment 보내고 A가 타이머 시작
  • B가 보낸 ACK 손실 -> timeout -> A가 재전송
  • B는 똑같은 걸 또 받았으니 재전송된 segment는 저장 안함 (ACK는 보내고)

• Premature Timeout

  • A가 B에게 2개의 segment 보내고 첫번째 segment에 대한 타이머 시작
  • B가 각각의 ACK를 보냈는데, timeout 뒤에 A가 받음
  • timeout이 발생했으니 A는 이미 첫번째 segment 재전송
  • B가 보낸 두번째 ACK는 새로운 timeout 전에 도착한 셈
    -> 두번쨰 segment는 재전송되지 않는다.
  • GBN과 다른 점
    • GBN도 oldest unacked segment 기준으로 타이머 가지지만, timout되면 모든 unacked segment를 재전송함

• Cumulative ACK

  • A가 B에게 2개의 segment 보내고 첫번째 segment에 대한 타이머 시작
  • B가 보낸 첫번째 ACK만 손실되었는데, timeout 전이라 두번째 ACK는 받음
    -> A는 어쨋든 B가 2개 다 잘 받았구나를 알 수 있으므로 재전송 안함

  • ACK가 손실되면 retransmission을 줄이는 편으로 대처한다
  • ex) 90 100 " " 120 인 경우 ACK=100 (가장 최근 unacked 직전까지의 ACK 보냄)
    (아래 ACK generation의 3번)

TCP ACK generation

• 외우려 하기보단 이해하면 자연스러운 내용

1. delayed ACK
   • 수신자가 기다리는 순서 번호를 가진 in-order segment 도착했고 그 전 segment는 이미 확인 됐을 때
   • 수신자는 또 다른 in-order segment를 500ms 기다리다가 안오면 그냥 ACK 보냄
2. Imediate & single cumulative ACK
   • 수신자가 기다리는 순서 번호를 가진 in-order segment가 도착하고, 다음 in-order segment도 도착
   • 수신자는 순서대로 ACK를 보내기 위해 즉시 두 segment의 누적 ACK를 보냄
   • 안정적인 네트워크 상황(in-order, no loss)에서 N개의 segment를 받았을 때 몇개의 ACK를 보내야할까? -> N개 또는 N개보다 적게
3. Immediate & duplicate ACK
   • 수신자가 기다리는 순서 번호보다 높은 순서 번호를 가진 out-of-order segment가 도착한 경우 -> Gap
     (송신한 segment가 loss된 경우)
   • 수신자는 즉시 가장 최근 unacked 직전까지의 ACK 보냄 -> 이미 확인된 것이라 duplicate ACK
4. Immediate ACK
   • Gap을 부분적으로 또는 모두 채우기 위해 segment가 도착한 경우
   • segment가 gap의 최솟값에서 시작한다면 즉시 ACK 보낸다

Fast Retransmit

• timeout period이 긴 경우도 있는데, 이는 lost packet을 재전송하기 전 long delay를 유발한다
• 그래서 Duplicate ACK을 받아 timeout되기 전에 빠르게 재전송
  • segment가 loss되면 많은 duplicate ACK
    -> duplicate ACK로 segment lost를 감지
• ex) 송신자가 3개의 duplicate ACK를 받은 경우
  • ACK된 segment의 다음 3개의 segment가 분실되었음을 의미
  • ACK된 segment의 다음의 segment가 분실되었음을 의미
    -> 송신자는 timeout되기 전에 빠르게 손실된 segment를 재전송
    -> seq 100도 확인되면 seq 141까지 다 받은거니까 141 다음 번호를 가지는 ACK가 보내진다

Flow Control

• sender가 reciever 오버플로우 안시키려고 속도를 맞춰주는 방법
• sender는 reciever가 받을 수 있는 속도보다 더 빠르게 segment를 보내면 안됨
• overflow: reciever의 버퍼가 가득차면 도착하는 segment들은 버려짐

• 송신자가 수신자의 버퍼를 오버플로시키는 것을 방지하기 위해 하는 건 flow control
• 송신자가 IP네트워크의 혼잡 때문에 억제되는 것은 congestion control

잘 구분하기

• RcvBuffer: 수신 버퍼의 크기
• Receive window(rwnd): 수신 버퍼의 여유 공간 양
  • 수신 측에서 가용한 버퍼 공간(rwnd)이 얼마나 되는지를 송신자로의 세그먼트에 포함
  • 송신자는 수신자의 rwnd값에 따라 in-flight 데이터(미확인된 데이터의 양)을 제한

Recive window 크기 결정 (RWND)

• 여유 공간은 시간에 따라 변하며 동적
• LastByteRead: 수신자의 애플리케이션 프로세스에 의해 버퍼로부터 읽힌 데이터 스트림의 마지막 바이트 번호
• LastByteRcvd: 수신자에서 네트워크로부터 도착하여 수신 버퍼에 저장된 데이터 스트림의 마지막 바이트 번호

  rwnd = RcvBuffer - (LastByteRcvd - LastByteRead)
  LastByteRcvd - LastByteRead <= RcvBuffer (빈 버퍼 공간이 더 많아야한다)

송신자의 Flow control

• window 사이즈 <= rwnd (보내질 수 있는 범위는 수신 버퍼 여유 공간 양보다 무조건 작아야 함)

• LastByteAcked: ACKed segment의 마지막 바이트 번호

• LastByteSent: window안에 있어 보내질 수 있지만 아직 보내지지 않아 확인되지 않은 segment의 마지막 바이트 번호

  LastByteSent - LastByteAcked <= rwnd

• 수신자가 ACK 전달할 때, rwnd 사이즈를 포함해서 전송

• 송신자의 window는 rwnd보다 작아야한다..

TCP Connection Management

• TCP 연결 관리 (TCP is connected oriented)
  • Connection establishment: 실제 데이터 전송 전에 송신자와 수신자 간에 연결 설정되야함
  • Data trasnfer: 데이터 전달의 신뢰성 보장을 위해 데이터가 성공적으로 전달되었는지 확인해야함
  • Connection termination: 데이터 전송이 완료되면 연결 해제

연결 설정: 3-way handshake

• 1단계
  • 클라이언트 TCP는 서버 TCP에게 SYN세그먼트 송신
    • 클라이언트는 ISN(Initial sequence number)x를 랜덤으로 선택하고, 최초의 TCP SYN세그먼트의 순서 번호 필드에 이 번호를 넣음 (seq = x)
  • 세그먼트가 데이터그램 안에서 캡슐화되고 서버로 송신
• 2단계
  • SYN세그먼트를 포함하는 IP데이터그램이 서버에 도착하면 서버는 SYN세그먼트 추출
  • 클라이언트에게 SYN을 잘 받았다고 SYNACK(연결 승인 세그먼트)를 보냄
    • 서버는 자신의 ISNy을 선택하고 TCP SYN세그먼트의 순서 번호 필드에 이 번호를 넣음 (seq = y)
    • (확인 응답 필드 ACKnum =x+1)
• 3단계
  • 클라이언트가 SYNACK를 받으면 잘 받았다고 ACK를 보냄 (Acknum = y+1)
    
    
• 클라이언트에서 보내기 시작한 것은 x를 따라서, 서버에서 보내기 시작한 것은 y를 따라서... (ISN을 설정한다는 것은 초기값만 설정하는거고, 주고받을 때마다 +1씩)
• 위의 세 단계가 완료되면, TCP연결이 설정되고 클라이언트와 서버는 서로에게 데이터를 포함하는 데이터를 보낼 수 있게됨
• SYNbit는 1이다가 연결 완료되면 0으로 설정됨

연결 해제

1. 클라이언트가 종료 명령 내림 clientSocket.close()
   • 데이터를 더이상 보내진 않지만 받을 순 있는 상태
2. 클라이언트가 서버에게 FINbit=1로 설정하여 특별한 TCP 세그먼트 보냄 (seq=x)
3. 서버가 이 세그먼트를 받으면 클라이언트에게 확인 응답 세그먼트 보냄 (ACKnum = x+1)
4. 클라이언트는 계속해서 서버가 종료되길 기다리고, 서버는 Finbit=1로 설정된 자신의 종료 세그먼트를 송신 (seq = y)
   • 서버는 데이터를 게속 보낼 수 있는 상태
5. 클라이언트가 종료 세그먼트를 받으면 확인 응답 (ACKnum = y+1)
   • 서버가 데이터를 보낼 수 없는 상태
   • 클라이언트는 2*MSL(max segment lifetime) 시간만큼 기다림

MSL (Maximum Segment Lifetime)

• TCP세그먼트가 internetwork system에서 존재할 수 있는 시간
  • 보통 30초, 1분, 2분 등..
• 클라이언트가 서버로부터 종료 세그먼트를 받고 TIMED_WAIT상태에서 2*MSL이 필요한 이유
  • 연결이 종료되었지만 늦게 도착한 세그먼트나 중복된 세그먼트를 처리하기 위해
  • MSL의 두 배인 시간동안 해당 연결이 완전히 사라질때까지 대기하여 이전 연결에 대한 모든 정보가 시스템에서 제거되도록함
  • 만약, 기다렸는데도 안오면 닫힘

---

⛄기말고사 시작

---

4. Congestion Control 원리

Network Congestion

• 네트워크 혼잡의 원인: 너무 많은 출발지에서 너무 높은 속도로 많은 양의 데이터를 보내려고 시도
• Congestion이 발생하면 노드가 꽉 차서 품질 낮아짐
• Congestion 표현 및 증상
  • lost packet (라우터에서 오버플로우)
  • long delay (라우터 버퍼에서의 대기queueing)
  • call blocking (호출 차단)
• Congestion cotrol의 목적
  • to keep the traffic entry into communication networks below level at which performance falls off dramatically (네트워크가 특정 수준 이상의 트래픽을 처리할 때 성능이 급격히 감소하는 혼잡 상황을 방지하기 위해)

Network 성능 측정

1. 네트워크 처리량 (Throughput)
   • 네트워크가 얼마나 많은 데이터를 처리할 수 있는가
2. end to end delay
   • 데이터가 얼마나 빠르게 전송되는가
   • 소스에서 목적지까지 지연 + 각 노드에서의 지연

• generating rate (패킷이 생성되는, 차는 속도)
• service rate (패킷이 전송되는 속도)
  • generating rate < service rate : throughput 손실 (packet이 더 많아야함)
  • generating rate > service rate : delay 발생 (buffer 대기)
  • generating rate = service rate : 가장 이상적 (버퍼에 데이터가 없고 계속 생성되자마자 전송)

Congestion control이 없다면

1. 이상적인 경우 (버퍼 무한, 혼잡제어 관련 오버헤드 없음)

• 데이터 양에 따른 throughput
  • 수신자의 throughput = 송신자의 전송 속도
  • 데이터 양(load)가 많아지면 throughput의 한계 존재
    
    
• 데이터 양에 따른 delay
  • 무시할 수 있는 데이터양에서는 작은 상수량의 지연
  • 네트워크 데이터 양이 증가함에따라 각 노드에서의 delay 추가
  • 네트워크 데이터 양이 네트워크 용량을 초과하면 무한대의 delay

2. 실제 상황 (버퍼 유한하여 오버플로우 발생, 혼잡제어 신호 교환으로 네트워크 용량 소모)

• 데이터 양에 따른 throughput
  • 적은 양의 데이터에서는 데이터 양에 따라 네트워크 throughput(처리량) 증가 No Congestion
  • 계속 데이터의 양이 증가하면 throughput이 줄어들기 시작 Moderate Congestion
  • 노드가 대기열 오버플로우로 인해 패킷을 버릴 때, 소스가 데이터를 재전송하며 throughput 급격히 감소 Severe Congestion

Congestion 대응

1. Congestion Collapse (혼잡 붕괴)
   • 트래픽 증가 > 혼잡 > 타임아웃 > 재전송 > 혼잡 증폭(amplification) >...
   • 반복되며 더욱 악화 -> 네트워크 성능 급격히 저하
2. Comgestion Avoidance (혼잡 회피)
   • 혼잡 발생 전에 트래픽을 적절히 제어 (효율적인 혼잡 제어 기법 필요)

5. TCP Congestion Control

Congestion control 전략

1. Implicit(암묵적)
   • 명시적인 피드백 없이 end system이 관찰한 손실 및 지연 정보를 통해 혼잡 유추
   • TCP의 방법 (혼잡하다 판단되면 송신 속도를 낮춤)
2. Explicit(명시적)
   • 목적지를 포함한 네트워크 요소가 명확하게 혼잡 정보 제공

TCP flow control vs congestion control

• 흐름제어

  • 수신 측이 송신 속도를 조절
  • 수신자의 버퍼 오버플로우 방지
  • rwnd(recive window)를 사용해 수신자가 송신자에세 수신버퍼의 여유 공간 양을 알려줌
    • 수신버퍼 여유 공간에 따라 아래 식을 만족하도록 window크기를 제한하여 속도 조절
      (window크기가 버퍼 여유 공간을 넘지 않도록)

• 혼잡제어

  • 송신 측에서 혼잡을 감지하고 송신 속도 조절
  • 네트워크의 라우터 버퍼 오버플로우 방지
  • cwnd(congestion window)를 사용해 송신자가 네트워크에 트래픽을 전송할 수 있는 속도 설정
    • 수신자의 상태 및 네트워크 상태에 따라 속도 제한
      (window 크기가 cwnd와 rwnd 둘 다 넘지 않도록)

Functions

0. AIMD

• Additive Increase Muliplicative Decrease
• 송신 속도를 동적으로 조절하여 네트워크 혼잡을 관리하는 알고리즘
• Additive Increase: 손실이 감지되기 전까지 ACK를 받을 때마다 MSS * (MSS / cwnd)씩 cwnd를 증가시킴 (즉, RTT(round-trip time)마다 MSS씩 증가됨)

  increment = MSS * (MSS / cwnd)
  cwnd += increment

• Multiplicative Decrease: 손실이 감지되면 cwnd를 절반으로 감소시킴
• 가산적인 속도 증가로 송신 속도를 높이고, 곱셈적인 속도 감소로 빠르게 속도를 낮춰 혼잡 제어

  cwnd /= 2 

  

AIMD 한게

• AIMD의 선형 가산적인 속도 증가는 새로운 TCP연결을 처음부터 빠르게 증가시키기에 너무 오래 걸림
• sol: slow start

1. Slow Start (SS)

• cwnd의 크기를 초기에는 지수적으로(exponential) 증가시켜 초기 램프업을 빠르게 제공
• 연결이 시작되고 처음 손실 사건이 발생할 때까지 지수적 증가, 손실이 감지되면 감소
• RTT마다 MSS씩 증가시키는 AIMD와 다르게, ACK를 받을 때마다 MSS씩 증가시킴

  increment = MSS;
  cwnd += increment

  

SS vs AIMD

ssthreshold

• slow start 하다가 threshold에 도달하면 congestion avoidance
• 손실이 감지되면 ssthreshold값이 cwnd의 절반 값으로 설정

2. Congestion Avoidance (CA; TCP Tahoe)

• ACK를 받을 때마다 MSS/cwnd만큼 증가시킴 (즉, RTT마다 MSS만큼 증가)
• 타임아웃으로 손실되거나 3개의 중복 ACK가 검출되면
  • ssthreshold는 손실 감지 시점의 cwnd 크기의 절반으로 변경되고, cwnd는 1로 변경
• ssthreshold에 따라 SS와 CA를 번갈아가며 동작

3. Fast Recovery (TCP Reno)

• 혼잡이 감지되면 Tahoe에서 cwnd=1로 설정하는게 너무 손해여서 tahoe에 fast recovery 도입
• 3개의 중복 ACK가 검출되면 sthresh는 cwnd 크기의 절반, cwnd은 cwnd/2 + 3로 변경하고 ss로 돌아감 (타임아웃으로 손실 해당 안됨 -> 그대로 tahoe 적용)

Tahoe vs Reno

• 다 동일하고, 3개의 중복 ACK가 검출되는 혼잡의 경우만 다름
  • 공통점:즉시 세그먼트를 재전송하고 ssthresh = cwnd/2로 설정
  • Tahoe는 slow start를 시작하고 cwnd=1으로 설정
  • Reno는 Fast recovery를 시작함 cwnd = cwnd/2+3으로 설정

제목	new ACK	timeout loss	3 dup.ACKs
Tahoe	ssthresh 기준으로 SS(+1)와 CA(+1/cwnd)	ssthresh = cwnd/2, cwnd =1	ssthresh = cwnd/2, cwnd =1 (slow start trigger)
Reno	ssthresh 기준으로 SS(+1)와 CA(+1/cwnd)	ssthresh = cwnd/2, cwnd =1	ssthresh = cwnd/2, cwnd/2+3 (fast recovery trigger)

Fairness

• TCP 공정성의 목표는 동일한 bottleneck link를 공유하는 k개의 TCP 세션 각각 R/K의 평균속도를 가지도록함
• 한 개의 bottleneck 라우터의 용량이 R일 때, 길이 k개이므로 용량을 k개로 나눠가지는 것
• 여러개의 TCP 연결 중 하나가 많은 throughput을 가지면 나머지는 적은 throughput을 갖게 됨
  • 이것을 방지하기 위해 공정하게~