Chapter 17 Transport Protocols
Connection-Oriented Transport Protocol Mechanisms •
¾
Reliable Network Service: Design Issues
¾
Unreliable Network Service: Design Issues ¾TCP
•
¾Slow
Reliable Sequencing Network Service ¾ ¾ ¾
Addressing Multiplexing ¾ Flow Control ¾ Connection Establishment & Termination: Negotiation of optional parameters (e.g., QoS); Triggers allocation of transport entity resources (e.g., buffer space) ¾
Start •
Unreliable Network Service ¾ ¾
Spring, 2003
EE 4272
Design Issues under Reliable Network Service: Addressing & Multiplexing •
User identification ¾
¾ ¾
•
¾
¾
Longer transmission delay between transport entities (end-to-end) compared with actual transmission time
¾
Variable transmission delay: Difficult to use timeouts
Delay in communication of flow control info
• Mechanisms under Reliable Network Services ¾
Do nothing: Segments that overflow are discarded Refuse further segments
¾
Use fixed sliding window protocol (sequence number /window size/ACK)
¾
¾ ¾
Multiple users employ same transport protocol User identified by port number or service access point (SAP)
Spring, 2003
EE 4272
Design Issues : Flow Control in Transport Layer
¾
Port represents a particular transport service (TS) user: e.g. “DNS” port 53, “Unix talk” port 517, see /etc/services on Unix Host address and Network number ¾ In an internet, a global internet address
Multiplexing ¾
Spring, 2003
Usually (host, port), called a socket in TCP ¾
E.g., Internet More Design Issues
• Challenges:
Addressing: Target user specified by ¾
Transport service is end-to-end protocol between two systems on same network Design Issues ¾
(Additive Increase/Multiplicative Decrease)
• Connectionless Transport Protocol: UDP
virtually 100% reliable delivery by network service: e.g. reliable packet switched network using X.25
Congestion Control
¾AIMD
Logical connection between TS : end-to-end transport of data, shield TS users from details of underlying systems
• Connection-Oriented Transport Protocol
¾
Backpressure type of Mechanism: clumsy & coarse grained Works well on reliable network: failure on ACK is taken as flow control indication Does not work well on unreliable network ¾
¾ EE 4272
Can not distinguish between lost segment and flow control tactic
Use credit scheme
Spring, 2003
EE 4272
1
Transport Protocol within Internetworking
Credit Allocation Scheme •
Use credit scheme ¾
Greater control on reliable network
¾
More effective on unreliable network
¾
Decouples flow control from ACK
• Unreliable Network Service: e.g. Internet ¾ ¾
• Design Issues of Transport Protocol ¾
May ACK without granting credit and vice versa
¾
¾
Each octet has sequence number
¾
¾
Each transport segment has Seq number, Ack number and window size in header
¾
Spring, 2003
Segments may get lost Segments may arrive out of order
¾
¾ ¾
EE 4272
Ordered Delivery Retransmission strategy Duplication detection Flow control (Credit Allocation Scheme) Connection establishment/termination Crash recovery
Spring, 2003
Duplication Detection
Design Issues under Unreliable Service • Ordered Delivery ¾
Segments may arrive out of order ¾ ¾
Number segments sequentially: TCP numbers each byte sequentially Segments are numbered by the first octet number in the segment
• Retransmission Strategy ¾
Segment damaged/failed in transit ¾ ¾
Transmitter does not know of failure Receiver must acknowledge successful receipt
¾
Use cumulative acknowledgement for efficiency
¾
Time out waiting for ACK triggers re-transmission ¾
Fixed timer: Based on understanding of network behavior ¾ ¾ ¾ ¾
¾
Too small leads to unnecessary re- transmissions Too large and response to lost segments is slow Should be a bit longer than round trip time Can not adapt to changing network conditions
Adaptive scheme
Spring, 2003
EE 4272
EE 4272
• If ACK lost, segment is retransmitted -> duplicate • Receiver must recognize duplicates • Duplicate received prior to closing connection Receiver assumes ACK lost and ACKs duplicate ¾ Sender must not get confused with multiple ACKs ¾ Sequence number space large enough to not cycle within maximum life of segment ¾
• Duplicate received after closing connection Spring, 2003
EE 4272
2
Three Way Handshake: Connection Establishment in TCP
Connection Termination • Entity in CLOSE WAIT state sends last data segment, followed by FIN ¾
FIN could arrive before last data segment ?? Remember: Internet
• Receiver accepts FIN ¾ ¾
Closes connection Loses last data segment
• Associate sequence number with FIN • Receiver waits for all segments before FIN sequence number
Spring, 2003
EE 4272
Spring, 2003
TCP Services & Mechanisms •
Reliable communication service between pairs of processes ¾
•
¾
•
¾ ¾
•
¾ ¾
AIMD Slow Start
• Retransmission timer management
Three way handshake Between pairs of ports
¾
Data transfer ¾
TCP Congestion Control • Window management
Across variety of reliable and unreliable networks and internets
Connection establishment ¾
EE 4272
Logical stream of octets Flow control by credit allocation of number of octets Data buffered at transmitter and receiver
¾
Estimate round trip delay by observing pattern of delay Set time to value somewhat greater than estimate Simple average Exponential average ¾ RTT Variance Estimation (Jacobson’s algorithm) ¾ ¾
Connection termination ¾ ¾
TCP users issues CLOSE primitive Transport entity sets FIN flag on last segment sent
Spring, 2003
EE 4272
Spring, 2003
EE 4272
3
AIMD: Additive Increase/Multiplicative Decrease
Additive Increase/Multiplicative Decrease Objective: adjust to changes in the available window capacity ¾
•
¾
New state variable per connection: CongestionWindow ¾
limits how much data source has in transit
¾
Note: CongestionWindow is set by TCP source based on the observed congestion level
Idea: ¾ ¾
•
Destination
increment CongestionWindow by one packet per RTT (linear increase) divide CongestionWindow by two whenever a timeout occurs (multiplicative decrease)
increase CongestionWindow when congestion goes down decrease CongestionWindow when congestion goes up
Question: how does the source determine whether or not the network is congested? ¾
Answer: a timeout occurs ¾
timeout signals that a packet was lost
¾
lost packet implies congestion
¾
…
•
Source
• Algorithm
Instead of a fixed size window for a TCP connection
packets are seldom lost due to transmission error
Spring, 2003
EE 4272
Spring, 2003
AIMD (cont)
Slow Start
KB
• Trace: sawtooth behavior 70 60 50 40 30 20 10
•
Slow start increase the congestion window exponentially rather than linearly
•
Idea: ¾ ¾
• 1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
• Reason of being conservative: consequences of having too large a window are much worse than those of it being too small Note: the accurate timeout mechanism is desirable
• Problem: it takes too long to ramp up a connection when it is Spring, 2003
EE 4272
¾
•
Destination
begin with CongestionWindow = 1 packet double CongestionWindow each RTT (increment by 1 packet for each ACK) compare with the original behavior of TCP (advertised window), not compare with “linear growth” of AIMD Exponential growth, but slower than all at once (original TCP)
Used… ¾ ¾
¾
Source
Why “slow”? ¾
10.0
Time (seconds)
starting from scratch (cold start)
EE 4272
when first starting connection when connection goes dead waiting for timeout (more knowledge)
In Reality ¾ interplay of “slow start” & “AIMD” Spring, 2003
…
•
EE 4272
4
UDP • User datagram protocol: RFC 768 • Connectionless service for application level procedures Unreliable Delivery and duplication control not guaranteed ¾ Adds multiplexing ¾ ¾
• Advantages: reduced overhead ¾
E.g., real time applications such as voice and telemetry
Spring, 2003
EE 4272
5
