[네트워크] 24. Transport-Layer Protocols

Position of Transport-Layer Protocols

• UDP is an unreliable connectionless transport-layer protocol
  • 그때그때 -> unreliable
• TCP is a reliable connection-oriented transport-layer protocol
  • 보내기 전에 connection establishment -> connection teardown
• SCTP is a new protocol that combines the features of UDP and TCP

• end-to-end의 data delivery

 

User Datagram Protocol (UDP)

• The User Datagram Protocol (UDP) is a connectionless, unreliable transport protocol.
  • lack of error control, No flow control
  • 하나하나를 독립적으로 전달
• UDP is a very simple protocol using a minimum of overhead
• The calculation of checksum and its inclusion in the user datagram are optional(선택적인)
• 복잡한 계산보다 빠른 처리가 중요한 곳에서 사용되면 good!(real-time and 짧은 시간의 transaction)

• total length = header + data
• checksum is optional
  • checksum으로 error를 detection 해도 버리는 것 외에는 할 수 있는 일이 없기 때문.

 

UDP: Checksum

• Checksum includes three section: a pseudoheader, the UDP header, and the data from the application layer

• data가 16bits(2bytes) 미만인 경우 0으로 padding 하여 전달

 

UDP Operation

• Connectionless services
• Flow and error control: no control without checksum
  • no flow control
  • error control - checksum
• Encapsulation and decapsulation
• mux/demux
• Queuing
  • port address 별로 incoming queue와 outgoing queue 존재하여 상호작용

UDP Applications

• Features: Connectionless service, Lack of error control and congestion control, no flow control
• Typical Applications:
  • Suitable for a process that requires simple request-response communication with little concern for flow and error control
  • Suitable for a process with internal flow and error control mechanisms such as TFTP
    • application 내 프로세스가 내부적인 flow and error control을 가지고 있을 때
  • Suitable for multicasting
  • Used for management processes such as SNMP(simple network management protocol)
  • Used for some route updating protocols such as RIP
• 요즘에도 real-time도 TCP를 쓰긴 하는 추세

 

Transmission Control Protocol (TCP) - 중요

• Transmission Control Protocol (TCP) is a connection-oriented, reliable protocol.
• TCP explicitly defines connection establishment, data transfer, and connection teardown phases to provide a connection-oriented service.
• TCP uses a combination of GBN(go-back-n) and SR(selective repeated) protocols to provide reliability.
  • SR에 가깝고 GBN 한 스푼 (GBN 방식의 ACK counting)
• TCP Services:
  • Process-to-process communication
  • Stream delivery service
  • Full-duplex communication
  • Multiplexing and demultiplexing
  • Connection-oriented service
  • Reliable service

 

Stream Delivery Service: TCP

• Unlike UDP, TCP is a stream-oriented protocol
  • stream 형태로 쭉 보내는 방식

• Buffering handles the disparity(차이) between the speed of the producing and consuming processes
• One example: to use a circular array of 1-byte locations

Segments: TCP

• IP layer needs to send data in packets not as a stream of byte

• 실제로 인터넷 상으로 보낼 때는 IP 형태로 보낸다.
• 실제로 우리가 보낼 때는 하나씩 보내는 것 같지만 전달될 때는 segment 단위(header+TCP)로 보낸다.

 

TCP Features

• Numbering system: sequence number and acknowledgment number
  • 내가 보낸 것의 number, 그거에 대한 응답 number
• Byte number: The bytes of data being transferred in each connection are numbered by TCP.
  • The numbering starts with a randomly generated number
• The value in the sequence number field of a segment defines the number of the first data byte contained in that segment
  • packet의 number를 적어주는 것이 아니라 내가 지금 나르는 segment의 sequence number를 적어준다.
• The value of the acknowledgment field in a segment defines the number of the next byte a party expects to receive.
  • The acknowledgment number is cumulative(누적되는)
    • 11000이 날라오면 그 전 것까지 다 잘 받았다는 것을 의미
  • TCP는 기본적으로 SR 방식인데 ACK와 관해서는 cumulative 특성을 가지는 것으로 보아 GBN의 특성 또한 가지고 있는 것을 알 수 있다.

• segment 1: header에는 10001
• segment 2: header에는 11001

range가 13001~14000 인 segment를 잘 받았다면 그 다음 ACK는 14001일 것임.

 

TCP Segment Format - 시험

• 각각이 몇 비트인지 외우기
• header: 20~60bytes
• 20bytes의 mandatory header(노란색을 제외한 부분)
  • 중요한 source port address와 destination port address -> 16bits
  • 내가 보내는 segment의 첫번째 byte number(random number를 generate해서 나온 것부터 시작)
  • header length field: 한 bit가 4byte를 나타냄 -> 515 <=> 2060
    • HLEN이 5면 아! option header는 없구나!
  • 6bit의 control field -> FLAG!(1과 0으로 특정 기능들을 on/off)
  • Window size = 65535(rwnd, receiving window)
    • 내가 얼마까지 수신할 수 있는 그릇을 가지고 있는지 명시
  • checksum - error control
    • UDP는 optional이었지만 TCP는 필수임!!!!!!!!!
  • urgent pointer
    • 급하게 보내야할 정보가 있을 때 URG 부분에 1 값을 준다.
    • 첫번째 byte부터 얼만큼 처리할 것인지
    • 예를 들어 40이라고 되어있고 첫번째 sequence number의 byte가 10001이라면 10001~10041은 급하게 보내야 한다는 의미
• header가 4byte 단위로 떨어지지 않으면 padding을 통해서 4bytes 단위로 맞춰준다.

 

TCP Control Field

• URG: 해당 FLAG가 1이면 urgent point field가 valid하다! -> 해당 값을 보고 sequence number와 더한 값만큼 급한 처리 고고
• ACK: 잘 받았다는 응답 - 1이면 Ack field가 valid
• PSH: TCP segment를 보낼 때 receiver 쪽에다가 stream으로 쭉 받을 생각하지 말고 빠른 처리를 해달라 요청.
• RST: 이것이 1이면 -> error가 발생했거나 recovery가 안되는 상황에서 connection을 강제적으로 끊음.
• SYN: 양쪽은 모두 random number를 generation 하고나서 어느 번호부터 보내겠다라는 것을 상대방에게 알려줘야 함.
  • 사실상 connection establish 단계
• FIN: connection 끊어버림
  • teardown

conncetion-oriented -> establish일 때는 SYN을 1로 만들어서 setup하고 teardown 할 때는 FIN을 1로 만든다.

 

Checksum: TCP

• The use of the checksum in TCP is mandatory

• IP header의 일부를 포함
• checksum은 16bit 단위이기 때문에 padding으로 맞춰줌

 

A TCP Connection: Establishment - 시험

• Connection establishment: Three-way handshaking(OK를 하면서 나도 연결맺자고 요청)
  • 4-way까지 가능
• A SYN segment cannot carry data, but it consumes one sequence number
  • SYN 상황에서 data는 보내지 않지만 하나의 sequence number는 소비한다!
• A SYN + ACK segment cannot carry data, but does consume one sequence number
  • ACK(8001부터 보내줘!) + 나도 연결 맺을래!(SYN)
• An ACK segment, if carrying no data, consumes no sequence number
  • ACK는 sequence number 소비하지 않음! 다음에 보낼 때는 ACK를 보내면서 보냈던 seq_number 그대로 사용하여 data를 실어서 보냄!
• Simultaneous open and SYN flooding attack (denial-of service attack, cookie)
  • 동시에 양쪽 모두 SYN을 보내는 경우 양쪽 다 ACK를 보내주면됨
  • SYN flooding attack 발생(DOS 공격)
  • 여러개의 클라이언트 한 서버에게 SYN를 보내는 경우를 생각해 보자
    • 서버마다 처리 용량의 한계가 있는데 이를 1000이라고 하자.
    • 근데 해커가 남의 주소를 도용하여 SYN를 1000개를 보내버린다.
    • 서버는 SYN+ACK를 보내주고 resource를 할댕해준다.
    • 그런데 실제로 1000명의 클라이언트가 온 것이 아님. 그래서 선의의 클라이언트들이 서버에 거부됨.
    • cookie로 해결!
      • resource를 요청한 클라이언트의 IP주소가 valid한지 확인을 하고 valid하면 자원을 할당.

A TCP Connection: Data Transfer - 중요!!!

이거 숫자 채워넣는 거 무조건 무적권 무조껀 나올 듯!

• After connection is established, bidirectional data transfer can take place
• Pushing data and urgent data

A TCP Connection: Connection Termination

• Three-way handshaking
• The FIN segment consumes one sequence number if it does not carry data
• The FIN + ACK segment consumes one sequence number if it does not carry data

A TCP Connection: Connection Termination

• Half-Close

• 서버측에서 아직 보낼 데이터가 남아있는 경우 FIN을 할 수 없기 때문에 일단 OK를 보내고 나머지 segment를 다 보내고나서
• F+A를 보내고 처음 F를 보낸 클라이언트에서 A를 날리면서 연결을 완전히 끊어낸다.

 

State Transition Diagram

• 각각 화살표에 써있는 글씨 유념하며 보기
• TIME-WAIT
  • ACK를 보내다가 lost가 되어 도착하지 않으면 상대방쪽에서는 본인도 끊자고 OK 했는데 ACK를 못받고있기 때문에 다시 또 ACK를 보낼 것인데 이 때 다시 보낼 때 2MSL(Maximum Segment Lifetime)동안 기다려서 아무런 얘기가 없으면 아 제대로 끊어졌구나 생각하고 CLOSED 상태로 돌아간다.

 

State for TCP

• The state marked ESTABLISHED in the FSM is in fact two different sets of states that the client and server undergo to transfer data

FSM: Half-Close Scenario

• 왜 client state의 경우에만 time-out을 기다렸다가 close되는가?
  • server의 경우 ACK가 오면 그냥 끊어지는 것이지만
  • client의 경우 server의 FIN에 대해 ACK를 클라이언트가 날리는 것이기 때문에 클라이언트에 이 ACK가 도착해야 한다.
  • 그런데 server에서는 resource를 회수하고 하느라 오래 걸릴 수가 있어서 그것에 대한 ACK가 늦을 수도 있다.
  • 그래서 이러한 ACK의 lost 상태까지 고려하여 time-out 과정이 추가된것이다.

 

Time-line Diagram for Common Scenario - 중요

• half-closed
• 서버는 아직 보낼게 남아있으면 그거까지 다 보낸다음에 passive close를 하고 FIN을 보내고 ACK를 받으면서 끝

 

Send Window in TCP

• receiver로부터 받은 rwnd로 window size를 결정
• First outstanding byte
• 파란색 부분 -> 이미 보냄 하지만 잘 받았는지는 모름 -> ACK가 와야지 지울 수 있음
• 상대방으로부터 온 window size의 크기가 늘어나면 open 될 수 있음

 

Receive Window in TCP

• rwnd = buffer size(창고) – # of waiting bytes to be pulled

• 창고에 100박스를 받을 공간이 있는데 60박스를 받아놨지만 아직 부산에 있는 가게에서 창고에 있는 박스를 가져가진 않은 상태
• 추가로 받을 수 있는 공간 -> 40공간 = receive window size

 

Flow Control

• Flow control balances the rate a producer creates data with the rate a consumer can use the data. TCP separates flow control from error control.
• We discuss flow control, ignoring error control. We assume that the logical channel between the sending and receiving TCP is error-free.

• transport layer에서는 application layer로 부터 message를 받기 때문에 consumer 역할도 하고 receiver의 transport layer로 전달하기도 하기 때문에 producer의 역할도 한다.
• TCP에서 4번 flow control을 지원하고 있음

 

Opening and Closing Windows 

• 쉬운 예제 - 단방향
• client -> server
  • 예를 들어, 유저가 post 하는 경우

• client가 server로 data를 보내면 rwnd가 줄어들 것이기 때문에 이는 항상 갱신됨.
• 위 예제에서 consumed 된 값들은 그냥 가정을 한 것(100 bytes를 consumed)
  • 일단 받아놓은 것이기 때문에(SR) 소비는 나중에 되는 것!
  • 창고에 라면박스 400개가 있는데 가게 주인이 200개를 소모하면 200공간이 남는 동시에 라면박스는 200개가 남는다.
• window가 open하고 close하는 경우를 잘 볼 것

 

Shrinking of Windows

• The receive window cannot shrink. The send window, on the other, can shrink if the receiver defines a value for rwnd that results in shrinking the window
  • shrink가 발생하는 경우
    • Ackno = 206, rwnd=12인 응답이 왔는데 잇따라 Ackno = 210, rwnd= 4인 것이 오면 shrink 발생
    • receiver 쪽에서 새로운 ACK를 주고 새로운 rwnd를 주었는데 그것이 그 전의 것을 shrink 하는 방향의 것이면 안된다.
• The receiver needs to keep the following relationship between the last and new ACK and the last and new rwnd values to prevent shrinking of the send window
  • new ackNo + new rwnd ≥ last ackNo + last rwnd
    • shrink가 안 일어나는 조건
    • 206+12 = 218
    • 210+4 = 214 이기 때문에 214보다 반드시 작아야지 shrink 가능
• Window shutdown – probing to prevent a deadlock
  • shutdown 후에 다시 보내도 된다는 응답을 보내는데 만약 이것이 lost 되면 영원히 주고 받을 수 없는 deadlock이 걸린다.

TCP Sliding Window

❏ The size of the window is the lesser of rwnd and cwnd(congestion window).

• min(rwnd, cwnd)

❏ The source does not have to send a full window’s worth of data.

❏ The window can be opened or closed by the receiver, but should not be shrunk.

❏ The destination can send an acknowledgment at any time as long as it does not result in a shrinking window.

❏ The receiver can temporarily shut down the window; the sender, however, can always send a segment of 1 byte after the window is shut down.

• Silly Window Syndrome
  • 부산에 있는 창고에서 1000박스를 저장할 수 있는 창고인데 999박스가 쌓여있으면 1박스 놓을 공간만이 남기 때문에 receiver는 sender에게 rwnd=1을 전달할 것이다.
  • 그러면 트럭 한 대가 라면 1박스를 전달하기 위해 출발한다.(overhead)
  • Nagle’s algorithm for syndrome created by the sender -> NS!!!
    • 모아서 보냄(양이 작은 것들은 안 보냄)
    • 1, 2개 이런애들은 안 보내고 모았다가 보낸다.
  • Clark’s solution for syndrome created by the receiver -> CR!!!
    • byte 수가 작으면 그냥 zero window(꽉참)이라고 해버리기
  • (1) zero window announcement, (2) delayed ACK

 

Error Control

• 디지털 세상에서 error는 불가피하게 발생함
• Error detection and correction in TCP is achieved through the use of three simple tools: checksum, acknowledgment, and time-out
• Checksum: If corrupted, it is discarded and considered as lost
  • header 뿐 아니라 IP psuedo header, payload까지
• Acknowledgment:
  • ACK segments do not consume sequence numbers and are not acknowledged
  • Two types of ACKs for TCP: Cumulative ACK (ACK) and Selective ACK (SACK)
    • 기본적으로 cumulative 방식
• Retransmission:
  • time-out에 의해서 구동- 시간이 지날 때까지 답장이 안 오면 사고로 간주
  • In modern implementations, a retransmission occurs if the retransmission timer expires or three duplicate ACK segments have arrived
  • No retransmission timer is set for an ACK segment
    • ACK에 대해서 timer를 구동하지 않음(ACK에 대한 ACK는 없음)
  • Retransmission after RTO (Retransmission Time-Out): RTO is updated based on the RTT (Round Trip Time)
    • traffic을 고려하여 RTO를 설정 (RTT + a)
    • RTT: 왕복시간(딱 걸리는 시간)
  • TCP가 해야 하는 일은 RTT값을 계속해서 계산해서 traffic을 고려하여 수시로 RTO 값을 update 하는 것
  • Retransmission after three duplicate ACK segments
    • sender는 2,3,4번을 보냈는데 돌아오는 ack가 2,2,2 이라면 3번에 문제가 생겼음을 의미
      • 3번이 잘 안 갔으니까 계속해서 2번을 요구하는 거겠지?
      • TCP는 기본적으로 SR(Selective Repeat 방식을 채택!)
• Out-of-order segments
  • Data may arrive out of order and be temporarily stored by the receiving TCP, but TCP guarantees that no out-of-order segment is delivered to the process
  • 순서대로 오지 않았어도 일단 저장
  • 넘겨줄땐 다 모이고 나서 넘겨줌(빈 packet이 채워졌을 때)

 

Simplified FSM for TCP Sender Side

Simplified FSM for TCP Receiver Side

Normal Operation Scenarios

769-770 페이지

• rule of ACK

• Rule 1:
  • piggybacking(내가 보낼 것 + 답장)
• Rule 2:
  • 조금 기다렸다가 ACK를 보냄
  • 500ms를 기다리는 이유는 내가 보낼 data가 생기거나 다른 프로세스로부터 보낼 데이터가 생기면 그걸 piggybacking으로 보내야 효율적이니까
  • 그래도 보낼 게 없으면 답장(Ack)만 보내라.
• Rule 3:
  • 500ms가 안되었을 때 두 segment가 오면 그 즉시(얼른) 두 segment에 대한 답장을 한 번에 보내라.

 

Lost Segment Scenarios

• Rule 4:
  • 클라이언트가 보낸 segment 하나가 lost되고 그 다음 segment가 잘 도착하면 서버 쪽에서는 일단 잘 도착한 걸 저장해 두고 바로 out-of-order가 되게 만든 segment에 대한 ACK를 즉시 다시 보내서 resent를 유도
• 701-800과 801-900이 보내졌는데 앞 segment가 중간에 Lost되어 server 쪽에서 out-of-order가 생기게 된다. 그래서 Ack 901을 지금은 보내지 못하는 상태
  • 901을 보내버리면 cumulative이기 때문에 빈 곳까지 잘 받았다고 이해해 버림
• Rule 5:
  • out-of-order가 발생했을 때 time-out되고 timer가 다시 restart 되어 resent를 하게 되고 해당 부분이 채워지게 되면(해결되면) 그 즉시 Ack를 보냄.

 

Fast Retransmission Scenarios

• 301로 시작하는 segment가 lost되어 out-of-order 때문에 Ack 301만 계속 보내지게 되는데 이 때, 500ms가 지나면 301에 대한 packet을 resend 할 것이고 해당 packet이 도착하면 rule 5에 의해서 즉시 다음 ACK를 전송할 텐데 아직 500ms가 지나지가 않았다.
• 따라서 500ms가 지나기 전에 Three duplicate가 만족되면(timer가 expire되기 전에) Fast retransmission을 빠르게 진행한다.
• 이는 RTO 값을 너무 충분히 잡아서 오랫동안 lost packet에 대해 재전송이 일어나지 않는 경우

 

Lost ACK Scenarios

• Deadlock created by lost ACK: persistent timer needed
• Ack 701이 오다가 Lost 되면...?
  • Ack에 대한 Ack는 하지 않기 때문에 알 길이 없다.
  • 1번 그림에서는 문제가 없음
    • 어차피 sender는 701을 보낼 건데 701을 보내달라는 ACK 701을 못받았다고 해서 문제가 되지 않기 때문에
    • 그 뒤에 오는 ACK 901덕분에 cumulative에 의해 701도 잘 받은 것으로 처리가 되기 때문에
  • Rule 6:
  • 하지만 2번 그림에서는 client 쪽에서는 segment를 두 개 보냈는데도 답장이 안 오니까 time out이 되고 501-600 sequence를 재전송하게 된다.
  • 그치만 서버 쪽에서 Ack701을 보내는 것은 이미 700까지는 잘 받았다는 뜻인데 이미 중복된 데이터가 오는 셈이다.
    • 그래서 이 때는 이미 있는(duplicated) segment가 오면 즉각적으로 Ack를 보낸다.(그 segment는 버리고)

 

TCP Congestion Control

• Receive window, rwnd, is the size of the send window which is controlled by the receiver
• Congestion window, cwnd, whose size is controlled by the congestion situation in network
• Actual window size = minimum (rwnd, cwnd)

• Congestion Detection
  • TCP sender uses the occurrence of two events as a sign of congestion in the network
  • 혼잡하다는 사실을 뭘로 알아? -> retransmission의 유무
    • Time-out and three duplicate ACKs
  • TCP를 구현한 형태
    • Taho TCP (earlier version) treated both events similarly
      • time-out이나 three dup ACK를 비슷하게 생각한다.(또이또이)
    • Reno TCP treats these two signs differently
      • time-out에 대한 재전송을 더 심각한 congestion으로 보고 처리

 

Slow Start: Exponential Increase

• In the slow-start algorithm, the size of the congestion window increases exponentially until it reaches a threshold

• 하나의 segment를 처음에는 작게 보내다가 점점 exponentially 증가시키는 방식
• 처음에는 낮게 시작해서 지수적으로 증가

 

Slow Start: Exponential Increase

ack가 잘 오면 cwnd를 늘려!

 

Congestion Avoidance: Additive Increase

• In the congestion-avoidance algorithm, the size of the congestion window increases additively until congestion is detected
• If an ACK arrives, cwnd = cwnd + (1/cwnd)
• slow start에서 한 없이 늘릴 수는 없기 때문에 threshold값을 준다.(ssthreash-slow start threashold)
  • 그 때부턴 congestion avoidance
  • 천천히 하나씩만 증가시킴

slow start -> congestion avoidance

 

Fast Recovery

• Three duplicated ACKs are interpreted as light congestion
• Use additive increase like congestion avoidance
  • If a duplicated ACK arrives, cwnd = cwnd + (1/cwnd)

Policy Transition

• When each of these congestion policies is used and when TCP moves from one policy to another ?
• Three versions of TCP: Taho TCP, Reno TCP, and New Reno TCP

 

FSM for Taho TCP

• start
  • cwnd = 1로 시작
• slow start
  • ack가 도착할 때마다 cwnd 점점 증가(1, 2, 4, 8 ,16)
  • cwnd가 threshold값보다 커지는 순간 congestion avoidance
• congestion avoidance
  • threashold 값에서 1씩 증가
• 만약 time-out 되었거나 3 dupACKs가 되면
  • ssthresh = cwnd / 2
  • cwnd = 1

 

Example 24.9: Taho TCP - 시험

• ssthresh가 6인 경우에 1, 2, 4 와 같이 증가하다가 그 다음으로 8이 되어야 하는데 ssthresh가 6이므로 6이되고 그 이후부터는 7, 8, 9,... 처럼 1씩 증가한다.
• y축 보면 cwnd임!!

시험 나올 때 어디어디서 time out이 발생했을 때의 그래프를 그려라

 

FSM for Reno TCP

• 기본적으로 start 값은 똑같음
  • 적당한 threashold
  • cwnd = 1
• Reno TCP는 Taho와 달리 3 dupACKs는 다르게 처리한다.(fast recovery)
  • ssthresh = cwnd / 2
  • cwnd = ssthresh + 3
  • Fast recovery로 들어감
    • 그 전까지 exponential 증가시키다가 new ACK(duplicated ACK이 아니라!)가 오면
    • cwnd = ssthresh 로 떨어뜨리고
    • Congestion avoidance(additive increase)로 감.
• 똑같이 혼잡한 것은 맞지만 time-out보다는 3 dupACKs가 light한 혼잡이라고 본다.

 

Example 24.10: Reno TCP

AIMD algorithm

• Additive Increase, Multiplicative Decrease

TCP Throughput

• If the cwnd is a constant (flat line) function of RTT,
  • Throughput = cwnd/RTT (unrealistic)
• If each tooth were exactly the same,
  • Throughput = [(maximum + minimum)/2]/RTT
• The max is twice the value of the min because in each congestion detection the value of cwnd is set to half of its previous value.
  • Throughput = (0.75) W_max/RTT
    • W_max
      • 혼잡이 발생했을 때의 average of window size(즉, peak 값들)

 

TCP Timers - 시험(100%)

• To perform their operations smoothly, most TCP implementations use at least four timers:
  • retransmission, persistence, keepalive, and TIME-WAIT.
• Retransmission timer(중요)
  • Measured RTT: RTT_M
    • 지금 막 측정된 왕복 시간을 의미하는 값
    • 0.1초가 되었는데도 상대방으로부터 답이 안 오면 time-out이 되고 다시 보냄
    • 그런데 얘는 고정된 값을 가질 수 없음(congestion은 계속 바뀌기 때문에)
    • round trip time에 따라 값을 설정
  • Smoothed RTT
    • 갑자기 RTT값이 팍 늘어나지 않게 그 동안의 값(smooth RTT)들을 누적한 부분에 weight를 준다.
    • 즉, 지금 막 측정된 RTT_M의 값은 그렇게 중요하지 않게 처리함.(1/8 비율 반영)
    • Initially No value
    • After first measurement RTT_s = RTT_M
    • After each measurement RTT_S = (1-α)RTT_S + α x RTT_M
    • 보통 α=1/8
  • RTT Deviation(편차)
    • 편차가 심하다는 것은 해당 측정값에 신뢰도가 낮다는 소리(이랬다 저랬다 하니까)
    • Initially No value
    • After first measurement RTT_D = RTT_M/2
    • After each measurement RTT_D = (1-β)RTT_D + β x [RTT_S - RTT_M]
    • 보통 β=1/4
    • 지금 측정된 편차를 적게(0.25) 반영하고 누적되고 있는 편차를 크게(0.75) 반영
• Retransmission Time-out (RTO)
  • Original Initial value
  • After any measurement RTO = RTT_S + 4 x RTT_D

 

Example 24.12: Retransmission Timer

• 초기 RTO 6
• R_D = 3/4 x 0.75 + 1/4{1.625 - 2.5} = 0.78

RTO = 1.625 + 4 x 0.78 = 4.74

 

Example 24.13: Karn's Algorithm

• TCP does not consider the RTT of a retransmitted segment in its calculation of a new RTO
• Use an exponential backoff strategy if a retransmission occurs

• 재전송이 발생한 경우 RTO 값 어떡해 할 거임?
• 가다가 lost된 경우 time-out 되면 resent 하는데 복잡한 계산을 하지 않고 임시적으로 이전 RTO 값에 2배를 한 것을 RTO로 한다.
• 근데 그 다음 ACK에 대해서는 중간에 두 배한 table을 사용하여 계산하는 것이 아니라 이 전의 table을 가져와서 다시 계산한다.

 

TCP Timers

• Persistence Timer:
  • To deal with a zero-window-size advertisement
    • slim window syndrome
  • 상대쪽이 zero-window-size라고 advertisement를 하면 1byte를 계속 보내보면서 아직도 zero-window니...? 하면서 물어보는 것(5초, 10초 ,... 최대 60초 단위로)
  • ACK segment announcing nonzero window size is lost: deadlock
  • set to the value of the retransmission timer up to 60 seconds
• Keepalive Timer:
  • To prevent a long idle connection between two TCPs
  • Usually after 2 hours, send 10 probes, each of which is 75 seconds apart
    • 정전 등의 이유로 idle connection이 계속된다면, 이를 끊어줄 필요가 있음
  • No response after 10 probes, terminate the connection
    • connection에게 probe를 날려서 답이 없는데도 계속 해서 연결되어 있으면 terminate
• TIME-WAIT Timer:
  • 2MSL(maximum segment lifetime) during connection termination
    • Finish의 경우, Finish를 보냈는데 ACK가 없으면 ACK가 잘 갔겠구나 하고 connection을 termination하는 것
  • Common value of MSL is 30 seconds, 1 or 2 minutes
  • Allow TCP to resend the final ACK in case of the ACK is lost

 

SCTP

• Stream Control Transmission Protocol (SCTP) is a new reliable, message-oriented transport layer protocol that combines the best features of UDP and TCP
  • TCP - reliable(error control, flow control)
  • UDP - message-oriented
    • TCP는 stream-oriented
• 많이 쓰이지는 않음
• TCP와 UDP의 특징을 같이 갖고 있음.
• SCTP Services:
  • Process-to-process communication: use all well-known ports in TCP
  • Multiple streams (TCP - single stream)
    • 다양한 media 동시 전송
    • 하나의 stream에 문제가 생겨도 다른 stream은 진행 가능
  • Multi-homing
    • 하나의 device가 여러개의 network connection을 가지는 것
  • Full-duplex communication(UDP, TCP도 마찬가지)
  • Connection-oriented service - TCP의 특성
  • Reliable service

 

SCTP Services

• Multiple streams: An association in SCTP can involve multiple streams
  • stream id 를 부여
• data chunk로 묶어서 stream으로

• Multihoming: SCTP association allows multiple IP addresses for each end

SCTP Features - 시험

• Transmission sequence number is used to number a data chunk
  • a packet = data chunk + control chunk
• Stream identifier (SI) to distinguish between different streams
• Stream sequence number to distinguish between different data chunks belong to the same stream
  • 한 stream 안에서 소속된 data chunks를 구분
• Packets: TCP has segments; SCTP has packets
  • In SCTP, control information and data information are carried in separate chunks
  • header는 간단함.

• Verification tag
  • association id

 

Differences between SCTP and TCP - 중요

1. The control information in TCP is part of the header; the control information in SCTP is included in the control chunks(in payload)
   • control information이 TCP 에서는 header에 있고 SCTP에서는 control chunk에 있다.
2. The data in a TCP segment treated as one entity(한 덩어리); an SCTP packet can carry several data chunks(여러 개의 data chunk)
3. The option section, which can be part of a TCP segment, does not exist in an SCTP packet
   • option section이 TCP에는 있고 SCTP에는 없다.
4. The mandatory part of the TCP header is 20 bytes, while the general header in SCTP is only 12 bytes(control 정보들이 header에 들어있지 않고 control chunk에 분리되어 들어감)
   • TCP mandatory header는 20byte, SCTP general header는 12byte이다.
5. The checksum in TCP is 16 bits; in SCTP, it is 32 bits
   • checksum bit 수가 TCP는 16bit, SCTP는 32bit이다.
6. The verification tag in SCTP is an association identifier, which does not exist in TCP
   • SCTP에는 verification tag가 존재한다.
7. TCP includes one sequence number in the header, which defines the number of the first byte in the data section. AN SCTP packet can include several different data chunks
8. Some segments in TCP that carry control information (such as SYN and FIN) need to consume one sequence number; control chunks in SCTP never use a TSN, SI, or SSN(data chunk에서만 사용)

이 중 세가지는 확실히 외우자(c, o, c)

checksum, option, control

 

Packet, Data Chunks, and Stream

• Data chunks are identified by three items: TSN, SI, and SSN.
  • SI defines the stream;
  • SSN defines the chunk in a stream
  • TSN is a cumulative number identifying the association;

• data chunk의 TSN, SI, SSN이 누적하여 매겨짐
• TSN: 일련번호가 쭉 매겨짐
• SI: 각각의 stream을 identify하는 identifier
• SSN: 한 stream 안에서 identify

Acknowledgment Number

• In SCTP, acknowledgment numbers are used to acknowledge only data chunks;
• control chunks are acknowledged by other control chunks if necessary

 

SCTP Packet Format

• In an SCTP packet, control chunks come before data chunks

• General Header

SCTP Chunks

0: data chunk

1~ : control chunk

connection = association

 

SCTP Association

• SCTP, like TCP, is a connection-oriented protocol
• A connection in SCTP is called an association to emphasize multihoming
• Association establishment requires a four-way handshake
• No other chunk is allowed in a packet carrying an INIT or INIT ACK chunk.
• A COOKIE ECHO or a COOKIE ACK chunk can carry data chunks

• client가 valid한지를 확인해 보기 위해 요청이 오면 cookie를 보내본다.
• valid하지 않다면 그 주소로 가지 않지만 valid하다면 그 주소로 제대로 cookie가 전달될 것이기 때문에 cookie를 서버에게 다시 전달한다.
  • 서버가 INIT ACK을 날릴 때 cookie를 같이 보내는데
  • 클라이언트로부터 cookie echo가 안 오면 valid한 클라이언트가 아니라고 보는 것

 

SCTP Association: Data Transfer

• Bidirectional data transfer
• Like TCP, SCTP supports piggybacking
• In SCTP, only DATA chunks consume TSNs; DATA chunks are the only chunks
  that are acknowledged
• The acknowledgment defines the cumulative TSN, the TSN of the last data chunk received in order

Association Termination

SCTP Flow Control

• Flow control in SCTP is similar to that in TCP.
  • TCP는 byte만 사용
• But, SCTP use two units of data, the byte and the chunk.
• The value of rwnd and cwnd are expressed in byte; the value of TSN and acknowledgment are in chunks

• window size, rwnd, cwnd, inTransit를 표현할 때는 byte
• TSN, Sequence number나 ACK는 chunk number를 사용

 

Flow Control Scenario

• rwnd는 내가 어느 정도 받을 수 있는지를 의미하기 때문에 sender의 rwnd는 사실상 무의미
• 보냈는데 아직 ACK를 못받은 상태는 outstanding 상태 -> inTransit

 

SCTP Error Control

• SCTP, like TCP, is a reliable transport layer.
• It uses a SACK chunk to report the state of the receiver buffer to the sender

• 빠진 것들도 받아 놓고 한 번에 보냄
• Gap ACK block
  • current TSN으로부터 몇 data chunk만큼 떨어져 있는 곳에 있는가
  • 1, 2번이 빠져있으니까 24, 25가 빠졌겠구나!
  • 6,7번이 빠져있으니까 29, 30이 빠졌겠구나!

 

SCTP Error Control

• Sender site

1400바이트가 전송(inTransit)되고 있다.

 

Error Control

• Sending Data Chunks: Whenever(즉시 전송) there are data chunks in the sending queue with a TSN greater than or equal curTSN or if there are data chunks in the retransmission queue
• Retransmission: Using retransmission timers and receiving three SACKs with the same missing chunks
• Generating SACK Chunks: Similar rule used for ACK with the TCP ACK flag
• Congestion Control : The same strategies in TCP.
  • SCTP has slow start (exponential increase), congestion avoidance (additive increase), and congestion detection (multiplicative decrease). SCTP also use fast retransmission and fast recovery

QnA