CHAPTER 3:

TRANSPORT LAYER
PRINCIPLES
FRU NGANG
SUPP’TIC
 PLAN

1. Design Issues
2. User Datagram Protocol
(UDP)
3. Transmission Control
Protocol (TCP)
4. New(er) transport
protocols
1. SCTP
2. DCCP
4.1 Design Issues
• Characteristics of the layers below the transport layer
• Available on the hosts and on the routers
• Operate in a hop to hop fashion
• Typically unreliable
• Characteristic of the Transport Layer
• Available only on the hosts
• Operate in an end-to-end fashion
• It has to operate like a pipe
• Services Provided to the upper layers
• Connection oriented service
• Connectionless service
• Convenient interface for application programmers (sockets)
• sockets
4.1 Design Issues
• Services Provided to the upper layers
• Goal is to provide an efficient, reliable, and cost effective service
• Transport Entity is responsible to provide that service
• May be located in the OS kernel, user process, library package or NIC
4.1.1 Transport service Primitives
Some terminology
 Messages from Transport Layer entities are
known as Transport Protocol Data Unit (TPDU).
 TPDU are contained in contained in network layer
Packets.
 Packets are contained in in data link layer frames.
 4.1.1 Transport service Primitives
• Processes on the application layer expect 100% reliable
connections
• They are not interested in acknowledgements, lost packets,
congestion, …
• Transport layer provides
• Unreliable datagram services ( connectionless)
• Reliable connection-oriented services
PRIMITIV PACKET SENT MEANING
• Three phases: establishment, communication, termination
E
• The primitives for a simple connection-oriented transport
LISTEN (none) Block until some process tries to
service connect
CONNECT CONNECTION REQ Actively attempt to establish a
connection
4.1.1 Transport service Primitives
4.1.1 Transport service Primitives
A state diagram for a simple connection management
scheme
• Transitions labelled in italics are caused by packet arrivals
• The solid lines show the client’s state sequence
• The dashed lines show the server’s state sequence
4.1.2 Transport protocol
Transport Protocol
• Transport services are implemented between transport entities by a transport
protocol
• Similar to Data Link Layer Protocols, Transport layer protocols have to deal with error
control, sequencing and flow control.
• On DLL, two routers communicate by using a physical channel
• No explicit addressing is required,
• Channel is always there
• On TL, channel is provided by the network layer
• Explicit addressing of the destination is required
• Channel is not always there
• Connection establishment is complicated
4.1.2 Transport protocol: addressing
• Addressing on the Transport Layer
• To which process connect to?
• Transport Service Access Point (TSAP)
• Network Service Access Point (NSAP)

• Question
• How does the process on Host 1 know the TSAP
of server 1 on Host 2?

• Solution
• TSAPS are stored in specific files
• Unix: /etc/services
• Window: \system32\drivers\etc\services
4.1.2 Transport protocol: addressing
• Addressing on the Transport Layer
• To which process connect to?
• Transport Service Access Point (TSAP)
• Network Service Access Point (NSAP)

• Question
• How does the process on Host 1 know the TSAP
of server 1 on Host 2?

• Solution
• TSAPS are stored in specific files
• Unix: /etc/services
• Window: \system32\drivers\etc\services
 4.1.2 Transport protocol: addressing
• Disadvantage of the previous solution
• For small number of servers the solution with specific files
works fine.

• Problem
• What happens when there are many servers which are
rarely used.

• Solution
• Special process: Process Server
• Listens to a set of TSAPs
• When desired server is not active, Connection is made with the
process server
• Process server starts the server for the desired service and passes
the connection to it.
 4.1.2 Transport protocol: addressing
• Disadvantage of the previous solution
• What happens if the server can not be started, ie
service depends on the process

• Solution
• Special process: Name Server / Directory Server
• Listens to a set of TSAPs
• When the desired server is not active, connection is
made with the process server
• Process server starts the server for the desired
service and passes the connection to it.
• Requirement
• Servers have to register with the name server
• Records of ( Name, TSAP)
 4.1.2 Transport protocol: connection
•
establishment
Problems with connection establishment
• When network can lose, store, and duplicate packets
• Delayed duplicates
• Solution approaches
• Throw away TSAPs: For each connection, a new TSAP is used.
• Management of used TSAP
• Restrict packet life time, e.g by a TTL field, timestamp …
• The Three way handshake (Tomlinson, Sunshine and Dalal)
• Each computer has a clock, time of the day
• Clocks do not need to be synchronized
• Clock has to run even if when the computer crashes or is switched off
• Idea: Put sequence numbers into TPDU and two TPDUs with the same sequence number may not outstand in the same time
• Each connection starts with a different initial sequence number.
4.1.2 Transport protocol: connection establishment
Connection establishment with the three way handshake
• Three protocol scenarios for establishing a connection using a three-way handshake. CR
denotes CONNECTION REQUEST
a)Normal operation
b)Old CONNECTION REQUEST appearing out of nowhere
c)Duplicate CONNECTION REQUEST and duplicate ACK
4.1.2 Transport protocol: connection release
• Terminating a connection
●Asymmetric release
• Telephone system model
• Either one peer can terminate the connection
• Danger of data loss
●Symmetric release
• Model of two independent unicast connections
• Each peer has to terminate the connection explicitly
• Data can be received by in the non-terminated direction
• Problem: Data loss can happen on both cases
• Question: Is there an optimal solution?
4.1.2 Transport protocol: connection release
• Famous example to illustrate the problem of controlled (reliable) connection
termination: The two-army problem
• The Blue armies can only communicate with messengers, i.e., soldiers running
through the valley
• Messengers are subject to loss
Messengers
Of the
Blue Army
4.1.2 Transport protocol: connection release
Four protocol scenarios for releasing a connection
a. Normal case of a three-way handshake
b. final ACK lost
4.1.2 Transport protocol: connection release
Four protocol scenarios for releasing a connection
c)Response lost
d)Response lost and subsequent DRs lost
4.1.2 Transport protocol: connection release
Four protocol scenarios for releasing a connection
c)Response lost
d)Response lost and subsequent DRs lost
4.1.2 Transport protocol: Multiplexing
Multiplexing of several conversations onto connections
a) Upward multiplexing: Many transport connections use the same network address
b) Downward multiplexing: Distribute the traffic of one connection over many network connections
4.1.2 Transport protocol: Multiplexing
4.1.2 Transport protocol: Crash Recovery
4.1.2 Transport protocol: Crash Recovery
4.2 Transport protocols in the TCP/IP model
4.2.1 The Classical Transport layer protocols
TCP & UDP
• Transport protocols are used by the application layer as communication services
• They allow the communication between application processes
• TCP is a connection-oriented protocol
• UDP is a connectionless
4.2.2 UDP
• Principle: “Keep it simple!”
• 8 byte header
• Like IP: connectionless and unreliable
• Small reliability, but fast exchange of information
• No acknowledgement between communication peers with UDP
• Incorrect packets are simply discarded
• Duplication, sequence order permutation, and packet loss are possible
• The checksum offers the only possibility of testing the packets on transfer errors
• Possible: ACKs and retransmissions are controlled by the application
• Use in multicast (not possible with TCP)
• Why at all UDP?
• Only the addition of a port to a network address makes communication unique
(IP Address1, Port1, IP Address2, Port2)
4.2.2 UDP Header
• Source Port, Destination Port: Addressing of the applications by port numbers
• Length: The total length of the datagram (header + data) in 32-bit words
• Checksum (optional): IP does not have a checksum for the data part, therefore it can be a meaningful
addition here
• The same procedure as in TCP
• Data: The payload, it is filled up if necessary to an even byte number, since message length counts in 32-bit
words
4.2.2 UDP Header
• Source Port, Destination Port: Addressing of the applications by port numbers
• Length: The total length of the datagram (header + data) in 32-bit words
• Checksum (optional): IP does not have a checksum for the data part, therefore it can be a meaningful
addition here
• The same procedure as in TCP
• Data: The payload, it is filled up if necessary to an even byte number, since message length counts in 32-bit
words
4.2.2 UDP Header

• Port number is 16-bit address, currently three different ranges

• Ports in the range 0-1023 are Well-Known (a.k.a. “system”)
• Ports in the range 1024-49151 are Registered (a.k.a. “user”)
• Ports in the range 49152-65535 are Dynamic/Private
• See for more information: http://www.iana.org/assignments/port-numbers
4.2.3 TCP
Characteristics of TCP
• Connection-oriented and reliable (error-free, keeps packet order, without duplicates)

• Error handling, acknowledgements, flow control (Sliding Window procedure)

• Byte stream, not message stream, i.e., message boundaries are not preserved

• Segmentation (max. segment size of 64 KByte)

• “Urgent”-messages outside of flow control

• Limited QoS

• Addressing of the application by port numbers

• Port numbers below 1024 are called well-known ports, these are reserved for standard services
4.2.3 TCP as a reliable connection
• If the server port is unknown, the use of a process server (Initial Connection
Protocol) is possible:

• Alternatively: Name server (comparable to a phone book) returns the destination port
4.2.3 TCP as a reliable connection
 Establishes logical connections between two Sockets
 IP address + 16 bit port number (48 bit address information)
 (IP Address1, Port1, IP Address2, Port2)
 For an application, sockets are the access points to the network
 A socket can be used for several connections at the same time
 TCP connections are always full-duplex and point-to-point
connections
 TPDUs exchanged between the two communicating stations are
called segments
 Segments are being exchanged for realizing
 Connection establishment
 Agreement on a window size
 Data transmission
 Sending of confirmations
 Connection termination
4.3.2TCP: Overview R FCs: 793, 1122, 1323, 2018, 2581

 full duplex data:

 bi-directional data flow in same
 point-to-point:
connection
 one sender, one receiver
 MSS: maximum segment size (536,
 reliable, in-order byte steam: 1460)
 no “message boundaries”  MSS is set based on MTU (MSS =
 pipelined: MTU – 40)
 TCP congestion and flow control set window  Path MTU Discovery

size  connection-oriented:
 send & receive buffers  handshaking (exchange of control msgs)
init’s sender, receiver state before data
exchange
application application
 flow controlled:
w rites data reads data
sock et
door
sock et
door
 sender will not overwhelm receiver
TCP TCP
send buffer receive buffer
se g m e n t
 TCP segment structure
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UA P R S F Receive window
(generally not used) # bytes
checksum Urg data pnter
rcvr willing
R ST, SYN , FIN: to accept
Options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)
 TCP segment structure
●Source and Destination Port: port number of sender resp. receiver
●Sequence Number/Acknowledgment Number: Segments have a 32 bit sequence and
acknowledgement number for the window mechanism in flow control (Sliding
Window).
●Sequence and acknowledgement number count single bytes!
●The acknowledgement number indicates the next expected byte!
●Sequence numbers begin not necessarily with 0! A random value is chosen to avoid a
possible mix-up of old (late) segments.
●Piggybacking, i.e., an acknowledgement can be sent in a data segment.
●Header Length: As in case of IP, also the TCP header has an indication of its length.
The length is counted in 32-bit words.
●Window Size: Size of the receiver’s buffer for the connection.
●Used in flow control: the window of a flow indicates, how many bytes at the same time can
be sent.
●The size of the buffer indicates, the number of bytes the receiver can accept.
●The window of flow control is adapted to this value.
 TCP segment structure
●Flags:
●URG: Signaling of special important data, e.g., abort, Ctrl-C
●ACK: This bit is set, if an acknowledgement is sent
●PSH: Immediate transmission of data, no more waiting for further data
●RST: Reset a connection, e.g., during a host crash or a connecting
rejection
●Generally problems arise when a segment with set RST bit is received
●SYN: set to 1 for connection establishment
●FIN: set to 1 for connection termination
●Urgent pointer: indicates, at which position in the data field the urgent data
ends (byte offset of the current sequence number).
●Option:
●Negotiation of a window scale: Window size field can be shifted up to 14
bits allowing windows of up to 230 bytes
●Use of Selective Repeat instead of Go-Back-N in the event of an error
●Indication of the Maximum Segment Size (MSS) to determine the size of
4.3.3 Connection management: connection establishment
 The server waits for connection requests using
LISTEN and ACCEPT.
 The client uses the CONNECT operation by
indicating IP address, port number, and the
acceptable maximum segment size (MSS).
 CONNECT sends a SYN.
 If the destination port of the CONNECT is
identical to the port number on which the server
waits, the connection is accepted, otherwise it is
rejected with RST.
 The server also sends a SYN to the client and
acknowledges at the same time the receipt of
the client’s SYN segment.
 The client sends an acknowledgement for the
SYN segment of the server. The connection is
established.
4.3.3 Connection management: irregular connection establishment

 Two computers at the same time try to

establish a connection between the
same sockets.
 Connections are characterized by their
endpoints; only one connection is
established between a pair of endpoints.

 The endpoints are uniquely

characterized by:
(IP Address1, Port1, IP Address2, Port2)
4.3.3 TCP Connection management:Data Transmission

 Full-duplex connection
 Segmentation of a byte stream into
segments.
 Usual sizes are 1500, 536, or 512 byte; thus IP
fragmentation is avoided.
 All hosts have to accept TCP segments of 536
byte +20 byte = 556 byte
 Usual acknowledgement mechanism:
 All segments up to ACK-1 are confirmed. If
the sender has a timeout before an ACK, he
repeats the sending.
 Usual procedure for repeating:
 Go-Back-N or Selective Repeat
4.3.3 TCP Connection management:Connection Termination

 Termination as two simplex connections

 Send a FIN segment
 If the FIN segment is confirmed, the
direction is “switched off”. The opposite
direction remains however still open,
data can be still further sent.
 Half-open connections!
 Use of timers to protect against packet
loss.
4.3.3 TCP Connection management:Irregular connection establishment

 Two computers at the same time try to

establish a connection between the
same sockets.
 Connections are characterized by their
endpoints; only one connection is
established between a pair of endpoints.

 The endpoints are uniquely

characterized by:
(IP Address1, Port1, IP Address2, Port2)
4.3.4 TCP Timer management
 TCP uses several timers
 Retransmission timer (for repeating a transmission)
 But:how to select the timer value?
 Probability density of the time till an acknowledgement arrives:

Problem on the transport

layer:

 T1 is too small: too many

retransmissions

 T2 is too large: inefficient

for actual packet loss
4.3.4 TCP Timer management
How to set TCP timeout value?
 Longer than RTT
• But RTT varies
 Too short: premature timeout
• Unnecessary retransmissions
 Too long: slow reaction to segment loss
How to estimate RTT?
 SampleRTT: measured time from segment transmission
until ACK receipt
• Ignore retransmissions
 SampleRTT will vary, want estimated RTT “smoother”
• Average several recent measurements, not just current SampleRTT
4.3.4 TCP Timer management: Retransmission Timer
 Solution: dynamic algorithm, which adapts the timer by
current measurements of the network performance.
 Jacobson’s Algorithm (1988)
 TCP manages a variable RTT (Round Trip Time) for each connection
 RTT is momentarily the best estimation of the round trip time
 When sending a segment, a timer is started which measures the time the
acknowledgement needs and initiates a retransmission if necessary.
 If the acknowledgement arrives before expiration of the timer (after a time unit
sampleRTT), RTT is updated:
RTT =  × RTT + (1 – ) × sampleRTT
  is a smoothing factor, typically 0.875
 The choice of the timeout is based on RTT
Timeout =  × RTT
 At the beginning,  was chosen as 2, but this was too inflexible
4.3.4 TCP Timer management: Retransmission Timer
 Improvement (Jacobson): set timer proportionally to
the standard deviation of the arrival time of
acknowledgements
 Computation of standard deviation:
devRTT = ɣ × devRTT + (1 – ɣ) × |RTT – sampleRTT |
 Typically ɣ = 0.75
 Standard timeout interval:
Timeout = RTT + 4 × devRTT
 The factor 4 was determined on the one hand by trying out,
on the other hand because it is fast and simple to use in
computations.
4.3.4 TCP Timer management: Other timers
Persistence timer
 Prevents a deadlock with a loss of the buffer release message of a
receiver
 With expiration of the timer, the sender transfers a test segment. The
response to this transmission contains the current buffer size of the
receiver. If it is still zero, the timer is started again.

Keep-alive timer
 If a connection is inactive for a longer time, at expiration of the timer it is
examined whether the other side is still living.
 If no response is given, the connection is terminated.
 Disputed function, not often implemented.

 Time Wait timer

 During the termination of a connection, the timer runs for the double
packet life time to be sure that no more late packets arrive.
4.3.4 TCP Timer management: Other timers
Persistence timer
 Prevents a deadlock with a loss of the buffer release message of a
receiver
 With expiration of the timer, the sender transfers a test segment. The
response to this transmission contains the current buffer size of the
receiver. If it is still zero, the timer is started again.

Keep-alive timer
 If a connection is inactive for a longer time, at expiration of the timer it is
examined whether the other side is still living.
 If no response is given, the connection is terminated.
 Disputed function, not often implemented.

 Time Wait timer

 During the termination of a connection, the timer runs for the double
packet life time to be sure that no more late packets arrive.
4.3.5 TCP Reliable Data Transfer
 Reliable transfer with TCP
 TCP creates reliable data transfer service on top of IP’s unreliable
service
 Pipelined segments
 Cumulative acks
 TCP uses single retransmission timer

 Retransmissions are triggered by:

 Timeout events
 Duplicate acks

 Initially consider simplified TCP sender:

 Ignore duplicate acks
 Ignore flow control, congestion control
4.3.5 TCP sender events
 Data received from app:
 Create segment with sequence number
 Sequence number is byte-stream number of first data byte in
segment
 Start timer if not already running (think of timer as for oldest unacked
segment)
 Expiration interval: TimeOutInterval
 Timeout:
 Retransmit segment that caused timeout
 Restart timer
 Ack received:
 If acknowledges previously unacked segments
• Update what is known to be acked
• Start timer if there are outstanding segments
 4.3.5 TCP: retransmission scenarios
Host A Host B Host A Host B

Seq=9 Seq=9
2, 8 b 2, 8 b
ytes d ytes d
a ta Seq= a ta
100,

Seq=92 timeout
20 by
t es d
at a
00
timeout
=1
ACK 0
10
X CK
A AC
=
K =12 0
loss
Seq=9 Seq=9
2, 8 b 2, 8 b
ytes d Sendbase ytes d
a ta
a ta = 100

Seq=92 timeout
SendBase
= 120 =1 20
K
CK =100 AC
A

SendBase
= 100 SendBase
= 120 premature timeout
time time
lost ACK scenario
Transport Layer 3-51
4.3.5 TCP retransmission scenarios (more)
Host A Host B

Seq=9
2, 8 b
ytes d
a ta

Seq=1 CK = 10 0
timeout 00 , 20 A
bytes
da t a
X
loss

SendBase CK =120
A
= 120

time
Cumulative ACK scenario

Transport Layer 3-52

4.3.5 TCP ack generation
Event at Receiver TCP Receiver Action

Arrival of in-order segment with expected seq #. All data Delayed ACK. Wait up to 500ms
up to expected seq # already ACKed for next segment. If no next segment, send ACK

Arrival of in-order segment with expected seq #. One other Immediately send single cumulative
segment has ACK pending ACK, ACKing both in-order segments

Arrival of out-of-order segment higher-than-expect seq. # . Immediately send duplicate ACK,

Gap detected indicating seq. # of next expected byte

Arrival of segment that partially or completely fills gap Immediately send ACK, provided that
segment starts at lower end of gap

Transport Layer 3-53

4.3.6 TCP flow control: sliding window

Transport Layer 3-54

4.3.6 TCP flow control: sliding window

Transport Layer 3-55

4.3.6 TCP flow control: sliding window

Transport Layer 3-56

4.3.7 TCP congestion control
 Principles of congestion control

 Congestion:
 Informally: “too many sources sending too much data too fast for
network to handle”
 Different from flow control!
 Manifestations:
• Lost packets (buffer overflow at routers)
• Long delays (queueing in router buffers)
A top-10 problem!

Transport Layer 3-57

4.3.7 TCP congestion control
Approaches towards congestion control
 Two broad approaches towards congestion control:
 End-end congestion control:
 Noexplicit feedback from network
 Congestion inferred from end-system observed loss,
delay
 Approach taken by TCP
 Network-assisted congestion control:
 Routers provide feedback to end systems
 Single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)
 Explicit rate sender should send

Transport Layer 3-58

4.3.7 TCP congestion control: Additive increase, multiplicative decrease
 Approach: increase transmission rate (window size), probing for
usable bandwidth, until loss occurs
 Additive Increase: increase CongWin by 1 MSS every RTT until
loss detected
 Multiplicative Decrease: cut CongWin in half after loss
• Additive Increase Multiplicative Decrease (AIMD)

Chapter 4: Transport Layer 4-59

4.3.7 TCP congestion control:details
 Sender limits transmission:
 LastByteSent - LastByteAcked ≤ CongWin
 Roughly,

 CongWin is dynamic, function of perceived network congestion

 How does sender perceive congestion?
 Loss event = Timeout or 3 duplicate acks

 TCP sender reduces rate (CongWin) after loss event

 Three mechanisms:
 AIMD
 Slow start
 Conservative after timeout events

Chapter 4: Transport Layer 4-60

4.3.7 TCP slow start
 When connection begins, CongWin = 1 Maximum
Segment Size (MSS)
 Example: MSS = 500 bytes & RTT = 200 msec
 Initial rate = 20 kbit/s

 Available bandwidth may be >> MSS/RTT

 Desirable to quickly ramp up to respectable rate

 When connection begins, increase rate

exponentially fast until first loss event

Chapter 4: Transport Layer 4-61

4.3.7 TCP slow start
 Each sender maintains two windows for the number of bytes which can be sent:
 Flow Control Window: granted receiver buffer
 Congestion Window: “network granted” capacity (cwnd)
 Minimum of both windows is the maximum number of bytes that can be sent
 With connection establishment, the sender initializes the congestion window to one
maximum segment size (MSS)
 MSS is the maximum number of application data that can be send in one segment!!!
 A segment with MSS bytes of application data is sent
 Slow Start Algorithm
 If an acknowledgement arrives before timeout, double the congestion window,
otherwise reset it to the initial value. Thus a “grope” takes place up to the transmission
capacity.
 Enlargement stops with reaching the flow control window
 Refinement by introduction of a threshold value ssthresh
 At the beginning 64 Kbyte
 Only linear enlargement by one maximum segment size (Congestion Avoidance)
 With a timeout the threshold value is put back to half of the maximum window size
reached before
Chapter 4: Transport Layer 4-62
4.3.7 Fast Retransmit and Fast Recovery

 Slow Start is not well suited when only a single packet is lost…
 Time-out period often relatively long  Long delay before resending lost packet
 E.g. short interference on a wireless link

 Fast Retransmit
 The receiver sends a duplicate ACK immediately when an out-of-
order segment arrives
 When the sender has received 3 duplicate ACKs, it retransmits
the missing segment.
• Hopefully, the acknowledgement for the repeated segment
arrives before a timeout

Chapter 4: Transport Layer 4-63

4.3.7 Fast Retransmit and Fast Recovery
 Fast Retransmit has to be enhanced to be useful in overload
situations…
 Fast Recovery
 When the third ACK is received, reduce

ssthresh = max(ssthresh/2, 2×MSS)

 Retransmit the missing segment, set

Cwnd = ssthresh + 3*MSS

 For each more duplicated ACK, increment cwnd by MSS
 This reduces cwnd by the amount of lost segments to adapt to the
network situation
 If the new cwnd (and the receiver’s buffer) allows, send a segment
 When the next (normal) ACK arrives, set cwnd to ssthresh to go on
normally
Chapter 4: Transport Layer 4-64
4.3.7 TCP congestion control summary
 When CongWin is below Threshold, sender in slow-start
phase, window grows exponentially.
 When CongWin is above Threshold, sender is in
congestion-avoidance phase, window grows linearly.
 When a triple duplicate ACK occurs, Threshold set to
CongWin/2 and CongWin set to Threshold.
 When timeout occurs, Threshold set to CongWin/2 and
CongWin is set to 1 MSS.

Chapter 4: Transport Layer 4-65

4.3.8 TCP Throughput

 What’s the average throughout of TCP as a function of window size

and RTT?
 Ignore slow start
 Let W be the window size when loss occurs.
 When window is W, throughput is W/RTT
 Just after loss, window drops to W/2, throughput to W/2RTT.
 Average throughput: (W/RTT+W/2RTT)/2  0.75W/RTT

Chapter 4: Transport Layer 4-66

4.4 Stream Control Transmission Protocol
 Key motivation
 Reliable transport of messages via IP networks (e.g. SS7
signaling)
 TCP too strict in-order delivery (danger of head-of-line-blocking)
 Limitations of sockets wrt. highly-available data transfer using
multi-homed hosts
 Vulnerability of TCP wrt. DoS attacks such as SYN flooding

 Key features
 Reliable,connection-oriented transport protocol, multi-streaming,
multi-homing, heartbeats, 4-way-handshake, TCP friendly, certain
resistance to flooding/masquerade attacks, message oriented

Chapter 4: Transport Layer 4-67

4.4 Stream Control Transmission Protocol
 SCTP association, 4 way handshake
 The client sends an INIT signal to the server to initiate
an association.
 On receipt of the INIT signal, the server sends an INIT-ACK response to the
client. This INIT-ACK signal contains a state cookie. This state cookie must
contain a Message Authentication Code (MAC), along with a time stamp
corresponding to the creation of the cookie, the life span of the state cookie,
and the information necessary to establish the association. The MAC is
computed by the server based on a secret key only known to it.
 On receipt of this INIT-ACK signal, the client sends a COOKIE-ECHO response,
which just echoes the state cookie.
 After verifying the authenticity of the state cookie using the secret key, the
server then allocates the resources for the association, sends a COOKIE-
ACK response acknowledging the COOKIE-ECHO signal, and moves the
association to ESTABLISHED state

Chapter 4: Transport Layer 4-68

4.4 SCTP Multi-Streaming
 Allows partitioning of data into multiple streams within one association
 Stream are independent wrt. sequenced delivery
i.e. loss in any one stream will only affect delivery within that stream
 Allows for partial ordering of e.g. objects of a web page
 Each object is assigned to a stream, order of object delivery irrelevant
 However, all streams are subjected to a common flow and congestion control
mechanism
 Two sequence numbers used
 Transmission Sequence Number
• Governs transmission of messages, detection of message loss
 Stream Identification/Stream Sequence Number
• Determines the sequence of delivery of received data
 This allows separating streams affected from message loss from unaffected
streams

Chapter 4: Transport Layer 4-69

4.4 SCTP Multi-Homing
 Ability for a single endpoint to support multiple IP addresses
 Used for redundancy (not for load sharing up to now)
 E.g.laptop could be connected via LAN, WLAN and UMTS to the
Internet
 Failure of one network will not cause a failure of the association
 One address chosen as primary IP address
 Destination for all DATA chunks for normal transmission
 Retransmitted DATA chunks use alternate address(es)
 Continued failure of primary address results in transmitting all
DATA chunks to alternate address (until heartbeats can
reestablish primary address)

Chapter 4: Transport Layer 4-70

4.4 SCTP Packet Format

Chapter 4: Transport Layer 4-71

4.4 SCTP Packet Format
 Ports
 16 bit as used in TCP, UDP
 Verification Tag
 Validation of the sender, set to the value of the Initiate Tag
received from the peer during association initialization
 Set to 0 in packets with INIT chunk
 See RFC for use during SHUTDOWN and ABORT

 Checksum
 Calculated over the whole SCTP packet including common
header (with checksum initialized to 0) and all chunks
 Invalid packets are typically silently discarded

Chapter 4: Transport Layer 4-72

4.5 Datagram Congestion Control Protocol
 Key motivation
 rapid growth of applications using UDP
 streaming media, on-line games, internet telephony
 apps preferring timeliness instead of reliability or short start-up
delay
 non TCP-friendly behaviour of UDP poses threat to the health of
the Internet
 clean, understandable, low-overhead, minimal protocol
 Key features
 unreliable flow of datagrams, end-to-end congestion control,
simpler firewall traversal, parameter negotiation

Chapter 4: Transport Layer 4-73

4.5 DCCP vs TCP/UDP
 Choice of congestion control mechanisms, even different per half-
connection (eg TCP-like, TCP-friendly Rate Control etc.)
 Feature negotiation mechanism
 Per packet sequence numbers
 Different ACK formats (Still: no reliability! Up to the app to decide!)
 DoS protection (e.g. cookies against flooding)
 Distinguishing of different kinds of loss
 Corruption, receiver buffer overflow…
 No receive window, simultaneous open, half-closed states…
 …
 Very roughly
 DCCP = TCP – bytestream semantics - reliability
 DCCP = UDP + congestion control + handshake + acknowledgements

Chapter 4: Transport Layer 4-74

4.5 Comparing the different protocols
UDP DCCP TCP SCTP
Connection-oriented service X X X

Connectionless service X

Ordered X X

Partially Ordered X

Unordered
Reliable X X

Partially Reliable X

Unreliable X X

With congestion control X X X

Without congestion control X

Multicast support X X

Multihoming support X
Chapter 4: Transport Layer 4-75