10. TCP
HDMI는 point to point 이지만 방해가 없어서 protocol이 필요 없다.
다른 신호에 의한 interrupt가 없기 때문이다.
여러개의 data-flow가 들어오는 상황에서는, protocol이 필요해진다.
그렇다면 switch를 어떻게 처리해야할까?
- give a switch knowledge
- Good, but when the number of switches gets larger, we need to control all of them.
- If we create a centralized control machine, it becomes a single point of failure.
- This approach will be useful at an institutional level, such as with eduroam.
- Knowledge to end-host (with TCP protocol)
- If data arrival slows down, we can reduce the data rate to control flow
- This causes a fairness problem—we need to be neither too humble nor too greedy
- Question: “Can it converge to the desired equilibrium?”
TCP
- point-to-point
- reliable, in-order
- pipelined
- full-duplex data
- bi-directional (ACK와 data를 동시에)
- MSS
- flow-controlled
- rhythm을 맞춘다.
- maximum size of window!
- connection-oriented
일반적인 TCP에서 seq #와 ACK #은 다음을 의미한다.
- Sequence Number: First byte의 number
- ACK: 현재 기대하고 있는 다음 byte
Estimating RTT
- We need to set the timeout value longer than RTT, but RTT varies.
- We use SampleRTT to estimate RTT!
EstimatedRTT = (1-a)*EstimatedRTT + a*SampleRTT
- EWMA: Exponentially weighted moving average
- Typically, a = 0.125 (to simplify calculations, using only shifting values)
a가 작다 - 기존거를 더 따르겠다.
a가 크다 - 현재꺼를 더 믿겠다.
→ a는 얼마나 파란색을 따라가는지, (fluctating 정도)를 나타낸다.
Then, we need a timeout interval
This consists of RTT plus a safety margin.
For largely fluctuating RTTs, we need a larger margin.
DevRTT = (1-b)DevRTT + b*(|SampleRTT-EstimatedRTT|)
TimeoutInterval = EstimatedRTT + 4*DevRTT
This assumes a normal distribution.
Consequently, this method is applicable only to internet traffic, not for specially optimized CPUs.
Fast retransmit
timeout은 실제로 매우 길다.
- long delay for resending lost packet!
→ Detect lost packet via duplicated ACKs.
만약 3개가 duplicated 되었다면 timeout까지 기다리지 말고 바로 전송
TCP Congestion control
ACK clocking: ACK가 도착한 rhythm에 맞춰 다시 패킷을 보내는 것.
→ 다음 장에서 다시 설명
TCP flow control
→ Receiver의 buffer가 다 차지 않도록 sender가 조절할 수 있게 하는 것
sender가 보내는 data의 양은 bottleneck에 의한 데이터 최대양 과 수신자의 능력 중 더 작은 값으로 결정된다.
Receiver는 자신의 상태(temperature, free buffer space size, movement 등)을 packet에 담아 보낸다.
→ cell tower에 전달되고, queue된다.
Handshake!
→ A 2-way handshake won’t work due to:
- Variable delays
- Retransmitted messages
- Message reordering
- Inability to see the other side
For example:
(1) If we request a connection but it times out, we might request again. If the first request succeeds after resending, and we terminate the connection between the second request and server establishment, a half-open connection will occur.
(2) If we resend a connection request and send (x+1) after establishment but before terminating, scenario (1) will happen. Additionally, the system might accept the (x+1) request sent before termination, causing a security problem.
3-way handshake
sender: SYN bit
receiver: SYN, ACK bit
sender: ACK bit → connected!
if ACK bit lost, this will not guarantee the connection, however this is the appropriate time with the tradeoff between connection-latency and reliable connection.
Closing connection
- close connection by setting FIN bit to 1.
마치 잠수이별처럼 헤어지자고 통보하면, 조금 있다가 결과를 알려준다.
결과를 알려주고도 먼저 헤어지자고 통보한 사람은 2*(max segment lifetime)만큼 기다린다.
→ If last ACK lost, the receiver will not closed and keep sending FIN packet. So Initiator waits for reasonable time.