Documente Academic
Documente Profesional
Documente Cultură
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.2
Design Issues
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.3
Design
g Issues
● Characteristics of the layers below the
Transport
p Layer
y OSI Reference Model
● Available on the hosts and on the routers Application Layer
● Operate in a hop-to-hop fashion
Presentation Layer
● Typically
T i ll unreliable
li bl
● Characteristics of the Transport Layer Session Layer
● Available only on the hosts
Transport Layer
● Operate in a end-to-end fashion
● It has to operate like a pipe Network Layer
● Services provided to the upper layers
Data Link Layer
● Connection-oriented service
● Connectionless service Ph sical Layer
Physical La e
● Convenient interface for application
programmers
● Berkeley
B k l sockets
k t
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.4
Services Provided to the Upper
pp Layers
y
● Services provided to the upper layers
● Goal is to provide an efficient, reliable, and cost
cost-effective
effective service
● Transport entity is responsible to provide that service
● Maybe located in the operating system kernel, user process, library package, or network
interface card
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.5
Transport
p Service Primitives
● Some terminology
● Messages from transport entities: Transport Protocol Data Unit (TPDU)
● TPDUs are contained in network layer packets
● Packets are contained in data link layer frames
Packet payload
Frame payload
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.6
Transport
p Service Primitives
● Processes on the application layer expect 100% reliable connections
● They are not interested in acknowledgements, lost packets, congestions, …
● Transport layer provides
● Unreliable datagram service (Connectionless)
● Reliable connection-oriented service
● Three phases: establishment, communication, termination
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.7
Transport
p Service Primitives
Client Server
Listen
Connect
Connection-Req.
Connection-Accepted Receive
Send
Data
Receive
Send
Data
Disconnect Receive
Disconnection-Req.
Receive Disconnect
Disconnection-Accepted
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.8
Transport
p Service Primitives
● A state diagram for a simple connection management scheme
● Transitions labeled 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
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.9
Transport
p Protocol
Transport protocol
● Transport service is implemented between transport entities by a transport
protocol
● Similar to the protocols studied in chapter “Data Link Layer”
● Have to deal with: error control, sequencing, and flow control
● Environment of the data link layer ● Environment of the transport layer
● On DLL two router communicate ● On TL channel is given by the subnet
directly via a physical channel ● Explicit addressing of the destination
● No explicit addressing is required is required
● Channel always there ● Channel is not always there
● Connection establishment is
complicated
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.10
Transport
p Protocol: Addressing
g
● Addressing on the transport layer
● To which process connect to?
● Transport Service Access Point (TSAP)
● Network Service Access Point (NSAP)
● Questions
● How does the process on Host 1 know
the TSAP of Server 1 on Host 2?
● Solution
S l
● TSAPs are stored in a specific file:
● Unix: /etc/services
● Windows: \system32\drivers\etc\services
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.11
Transport
p Protocol: Addressing
g
● Disadvantage of previous solution
● For small number of servers the
solution with specific files works
fine.
● Problem
● 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 Servers starts the server for
the desired service and passes the
connection to it
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.12
Transport
p Protocol: Addressing
g
● Disadvantage of previous solution
● What happens if server cannot be
started, i.e., service depends on the
process? Name
● Solution
Server
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.13
Transport
p 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 TSAPs
● Restrict packet life time, e.g., by a TTL field, timestamp, …
● Solution of Tomlinson, Sunshine, and Dalal (Three-way Handshake)
● Each computer has a clock (time of day)
● Clocks do not need to be synchronized
● Clock has to run even when the computer crashes or is switched off
● Idea: Put sequence numbers into TPDUs and two TPDUs with the same
sequence number may not outstand at the same time
● Each connection starts with a different initial sequence number
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.14
Transport
p Protocol: Connection Establishment
Assumption: After T time
units TPDU and Ack are
dead and have no effect.
TPDUs may
y not enter the forbidden y
The resynchronization problem
p
region
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.15
Transport
p Protocol: Connection Establishment
● Connection Establishment with the Three-way Handshake
● Three protocol scenarios for establishing a connection using a three-way
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
Host 1
does not
know x,
thus
rejects.
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.16
Transport
p 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 off two independent unicast
connections
● Each peer has to terminate the
connection explicitly
● Data can be received by in the non-
terminated direction
● Problem:
P bl Data
D t lloss can happen
h
on both cases
Abrupt disconnection with
●Q
Question: Is there an optimal
p loss of data.
data
solution? DR denotes Disconnect Request
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.17
Transport
p Protocol: Connection Release
● Famous example to illustrate the problem of controlled (reliable)
connection termination: The two-army
y problem
p
● The Blue armies can only communicate with messengers, i.e., soldiers running
through the valley
● Messengers are subject to loss Messengers of the
Blue armies
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.18
Transport
p Protocol: Connection Release
Four protocol scenarios for releasing a connection Disconnect
Request (DR)
(a) Normal case of a three
three-way
way handshake
(b) final ACK lost
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.19
Transport
p Protocol: Connection Release
● Four protocol scenarios for releasing a connection
c) Response lost
d) Response lost and subsequent DRs lost
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.20
Transport
p Protocol: Multiplexing
p g
● 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
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.21
Transport
p Protocol: Crash Recoveryy
● If hosts and routers are subject to
crashes, recovery becomes an issue
Cli t
Client S
Server
● Scenario
● A client sends a large file to a server DATA #1/N
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.22
Transport
p Protocol: Crash Recoveryy
● Processing strategies of server Crash can occur
● Strategy 1: First send ack, then write to application between
bet ee the
t e two
t o
● Strategy 2: First write to application, then send ack different operations!
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.23
Transport Protocols in the TCP/IP
Reference Model
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.24
Transport
p Protocols in the TCP/IP Reference Model
Connection-oriented Connectionless
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.25
The Transport
p Layer:
y TCP and 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
IP network
Client
process Server
process
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.26
User Datagram Protocol (UDP)
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.27
The User Datagram
g Protocol (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
p , sequence
● Duplication, q order permutation,
p , and packet
p loss are possible
p
● The checksum offers the only possibility of testing the packets on transfer errors
● Possible: ACKs and retransmissions are controlled by the application
● Use
U ini multicast
lti t ((nott possible
ibl with
ith TCP)
● Why at all UDP?
● Onlyy the addition of a p
port to a network address marks communication unique
q
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.28
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
h f it
i can be
b a meaningful
i f l addition
ddi i here
h
● The same procedure as in TCP
● Data: The payload,
payload it is filled up if necessary to an even byte number,
number
since message length counts in 32-bit words
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Data
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.29
UDP-based Applications
pp
Routing Information
Automatic Address Assignment
Network Management
Name service
Fil Transfer
File T f
DNS BOOTP TFTP SNMP RIP
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.31
Socket Programming
g g with UDP
create socket,
port x
port=x, create socket,
for incoming request: clientSocket = DatagramSocket()
serverSocket = DatagramSocket()
Create,, address (hostid,
( , port=x),
p ),
send datagram request
read request from using clientSocket
serverSocket
write reply to
serverSocket
read reply from
specifying client
host address, clientSocket
port number
close clientSocket
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.32
Example:
p Java Client (UDP)
( )
import java.io.*;
import java.net.*;
class UDPClient {
public static void main(String arg []) throws Exception
{
BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));
DatagramSocket clientSocket = new DatagramSocket();
InetAddress IPAddress = InetAddress.getByName(
InetAddress getByName(“hostname”);
hostname );
byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];
String sentence = inFromUser.readLine();
sendData = sentence.getBytes ();
D
DatagramPacket
P k send_pack
d k = new DatagramPacket(sendData,
D P k ( dD sendData.length,
dD l h
IPAddress, 9876);
clientSocket.send(send_pack);
DatagramPacket
g receivePacket = new DatagramPacket(receiveData,
g receiveData.length);
g
clientSocket.receive(receivePacket);
String modifiedSentence = new String(receivePacket.getData());
System.out.println(“FROM SERVER:” + modifiedSentence);
clientSocket.close();
}
}
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.33
Example:
p Java Server (UDP)
( )
import java.io.*;
import java.net.*;
class UDPServer {
public static void main(String args[]) throws Exception
{
DatagramSocket
g serverSocket = new DatagramSocket(9876);
g ( );
while (true)
{
DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
String sentence = new String(receivePacket.getData());
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
DatagramPacket
g sendPacket = new DatagramPacket(sendData,
g ( , sendData.length,
g ,
IPAddress, port);
serverSocket.send(sendPacket);
}
}
}
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.34
Transmission Control Protocol (TCP)
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.35
Characteristics of TCP
● Connection-oriented and reliable (error-free, keeps packet order, without duplicates)
● Error handling, acknowledgements, flow control (Sliding Window procedure)
● B
Byte stream, not message stream, i.e.,
i message boundaries
b d i are not preserved d
● Segmentation (max. segment size of 64 KByte)
● “Urgent”-messages outside of flow control
● Li it d QoS
Limited Q S
● Addressing of the application by port numbers
● Port numbers below 1024 are called well-known ports, these are reserved for standard
services
Network layer
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.36
TCP as a Reliable Connection
If the server port is unknown, the use of a process server (Initial Connection
Protocol) is possible:
Application Process
Client Server Server
P t number
Port b layer
Transport
IP address layer
Network layer
Data link
Process server hands layer
over new connections Physical
t th
to the iinquired
i d server layer
Alt
Alternatively:
ti l N Name server ((comparable
bl tto a phone
h b
book)
k) returns
t th
the d
destination
ti ti portt
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.37
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
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.38
TCP: Overview
RFCs: 793,, 1122,, 1323,, 2018,, 2581
● Point-to-point ● Full duplex data
● One sender, one receiver ● Bi
Bi-directional
directional data flow in same
● Reliable, in-order byte steam: connection
● No “message boundaries” ● MSS: maximum segment size
● Pipelined ● Connection-oriented
C ti i t d
● TCP congestion and flow control set ● Handshaking (exchange of control
window size msgs) init’s sender, receiver state
before data exchange
● Send & receive buffers
● Flow controlled
Application Application ● Sender will not overwhelm receiver
writes data reads data
segment
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.39
Transmission Control Protocol (TCP)
Socket Programming in TCP
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.40
Socket Programming
g g in TCP
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.41
Socket Primitives in TCP
● For communication via TCP, a set of primitives exists which an
application
pp p
programmer
g can use for initializing
g and carrying
y g out a
communication.
● The essential primitives are:
Primitive Meaning
SOCKET Creation of a new network access point
BIND Assign a local address with the socket
LISTEN Wait for arriving connecting requests
ACCEPT Accept a connecting request
CONNECT Attempt of a connection establishment
SEND Send data over the connection
RECEIVE Receive data on the connection
CLOSE Release of the connection
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.42
Socket p
programming
g g in TCP
Server (on host hostid) Client
create socket,
k
port=x, for incoming request:
welcomeSocket = ServerSocket ()
create socket,
TCP
wait for incoming connect to hostid, port=x
Connection establishment
connection request
q cclientSocket
e tSoc et = Soc
Socket
et ()
connectionSocket =
welcomeSocket.accept ()
write reply to
connectionSocket
ti S k t read reply from
clientSocket
close
connectionSocket close
clientSocket
li tS k t
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.43
Example:
p Java Client (TCP)
( )
import java.io.*;
import java.net.*;
class TCPClient {
public static void main(string argv[]) throws Exception
{
String sentence;
String
g modifiedSentence;
;
BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket(“hostname”, 6789);
DataOutputStream outToServer = new
DataOutputStream(clientSocket.getOutputStream ());
sentence = inFromUser.readLine();
outToServer.writeBytes(sentence + “\ n”);
modifiedSentence = inFromServer.readLine();
System.out.println(“FROM SERVER: ” + modifiedSentence);
clientSocket.close();
}
}
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.44
Example:
p Java Server (TCP)
( )
import java.io.*;
import java.net.*;
class TCPServer {
public static void main(string arg []) throws Exception
{
String clientSentence;
String capitalizedSentence;
ServerSocket welcomeSocket = new ServerSocket(6789);
while (true) {
Socket connectionSocket = welcomeSocket.accept();
welcomeSocket accept();
BufferedReader inFromClient =
new BufferedReader(new
InputStreamReader(connectionSocket.getInputStream()));
DataOutputStream
D t O t tSt outToClient
tT Cli t = new
DataOutputStream(connectionSocket.getOutputStream());
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + “\ n”;
outToClient.writeBytes(capitalizedSentence);
}
welcomeSocket.close();
}
}
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.45
Transmission Control Protocol (TCP)
The TCP Header
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.46
TCP-based Applications
pp
Routing information
Virtual terminal
World Wide Web
File transfer
Electronic
l Maill
1024
FTP telnet SMTP HTTP BGP
20/21 23 25 80 179
● 20 byte header
● Plus
Pl options
ti
● Up to 65495 data bytes
Counting Reserved
by bytes
of data
(not segments!)
Number of bytes
y
receiver willing
to accept
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.48
The TCP Header
● 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
mix-up
up of old (late) segments.
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.
length The length is counted in 32
32-bit
bit words.
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
p to this value.
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.49
The TCP Header
● Flags:
● URG: Signaling
g g of special
p important
p data,, e.g.,
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
connection, e.g.,
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:
FIN sett tto 1 ffor connection
ti ttermination
i ti
● 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 g windows of up
p to 230 bytes
y
● 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 the
data field
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.50
TCP Pseudo Header
● Checksum: serves among other things for the verification that the packet
was delivered to the correct device.
● The checksum is computed using a pseudo header. The pseudo header is
placed in front of the TCP header, the checksum is computed based on both
headers (the checksum field is here 0)
0).
● The checksum is computed as the 1-complement of the sum of all 16-bit words of the
segment including the pseudo header.
● The receiver also places the pseudo header in front of the received TCP header
and executes the same algorithm (the result must be 0).
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.51
Transmission Control Protocol (TCP)
Connection Management
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.52
TCP Connection Management:
1. Connection Establishment
Client Server ● 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).
(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,
j
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
client’ss SYN segment
segment.
● The client sends an acknowledgement for the
SYN segment of the server. The connection is
Three Way Handshake established.
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.53
TCP Connection Management:
Irregular
g Connection Establishment
Client/Server Client/Server
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.54
TCP Connection Management:
2. Data Transmission
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.55
TCP Connection Management:
3. Connection Termination
Client Server
● Termination as two simplex
connections
● Send a FIN segment
● If the FIN segment is confirmed, the
direction is “switched
switched off”.
off . The
opposite direction remains however
still open, data can be still further sent.
● Half-open
Half open connections!
● Use of timers to protect against packet
loss.
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.56
TCP Connection Management
g
TCP server
lifecycle
TCP client
lifecycle
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.57
The Entire TCP Connection
Normal path of server Normal
path of
client
li t
Unusual
events
Event/action pair
● Event: System call by user,
arrival of segment, timeout
● Action: Send a control segment
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.58
States during
g a TCP Session
State Description
CLOSED N active
No ti communications
i ti
LISTEN The server waits for a connection request
SYN RCVD A connection request was received and processed, wait for
the last ACK of the connection establishment
SYN SENT Application began to open a connection
ESTABLISHED Connection established,
established transmit data
FIN WAIT 1 Application starts a connection termination
FIN WAIT 2 The other side confirms the connection termination
TIME WAIT Wait for late packets
CLOSING Connection termination
CLOSE WAIT The other side initiates a connection termination
LAST ACK Wait for late packets
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.59
Transmission Control Protocol (TCP)
Timer Management
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.60
Timer Management
g with TCP
● 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:
obability eit
it
rscheinlichke
Proscheinlichke
0.2
0.2 ● T1 is too small:
bability
too many
retransmissions
Pro
Wahrs
Wahr
0.1
0.1
● T2 is too large:
0 inefficient for
0
10 20 30 40 50
10 20 30 40 50 actual packet loss
Roundtrip-Time
Round Trip Time [ms]
[ms]
Round Trip Time [ms]
Roundtrip-Time [ms]
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.61
Timer Management
g with TCP: Example
p RTT estimation
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
300
250
onds)
RTT (milliseco
200
150
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.62
Timer Management
g with TCP: Example
p RTT estimation
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.63
Timer Management
g with TCP
● How to set TCP timeout value?
● Longer than RTT
● But RTT varies
● Too short: premature timeout
● Unnecessary
U retransmissions
t i i
● Too long: slow reaction to segment loss
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.64
Timer Management
g with TCP: Retransmission Timer
● Solution: dynamic algorithm, which adapts the timer by current
measurements of the network performance.
p
● Algorithm of Jacobson (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
g needs and initiates a retransmission if necessary.
y
● 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
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.65
Timer Management
g with TCP
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.66
Timer Management
g with TCP: Retransmission Timer
● Improvement (Jacobson): set timer proportionally to the standard
deviation of the arrival time of acknowledgements
g
● Computation of standard deviation:
y γ = 0.75
● Typically
yp
● 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.
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.67
Timer Management
g with TCP
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.68
Timer Management
g with TCP: Retransmission Timer
● Karn‘s Algorithm
● Very simple proposal, which is used in most TCP implementations (optional)
● Do not update RTT on any segments that have been retransmitted.
● The timeout is doubled on each failure until the segments get through.
ACK #1
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.69
Timer Management
g with TCP: Other Timers
Persistence timer
● Prevents a deadlock with a loss of the buffer release message g 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.
g
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
p function,, not often implemented.
p
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.70
Transmission Control Protocol (TCP)
Reliable Data Transfer
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.71
TCP Reliable Data Transfer
● Reliable transfer with TCP
● TCP creates reliable data transfer service on top of IP’s
IP s unreliable service
● Pipelined segments
● Cumulative acks
● TCP uses single retransmission timer
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.72
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
k l d previously
i l unacked
k d segments
t
● Update what is known to be acked
● Start timer if there are outstanding segments
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.73
TCP Sender (simplified)
( p )
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
switch(event)
Comment:
• SendBase-1: last cumulatively ack’ed byte
p
Example:
• SendBase-1 = 71; y= 73, so the rcvr wants 73+; y > SendBase, so that new data is acked
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.74
TCP Retransmission Scenarios
meout
ut
Timeou
Seq=92 tim
X
loss
Sendbase
= 100
out
SendBase
Seq=92 timeo
= 120
S
SendBase
= 100 SendBase
= 120
Time
Time
Lost ACK scenario Premature timeout
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.75
TCP Retransmission Scenarios
Host A Host B
Timeout
X
loss
SendBase
= 120
Time
C
Cumulative
l ti ACK scenario
i
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.76
TCP ACK g
generation [RFC
[ 1122,, RFC 2581]]
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.77
Transmission Control Protocol (TCP)
Flow Control
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.78
TCP Flow Control: Sliding
g Window
● To provide reliable data transfer, as on Layer 2, a sliding window
mechanism is used.
Initial window
● Differences:
● Sender sends bytes
according
di to the
h window
i d size
i 1 2 3 4 5 6 7 8 9 10
● Window is shifted by n byte
as soon as an ACK for n bytes
y
arrives
● Exception: Urgent data Segment 1, 2, and 3 acknowledged
(URGENT flag is set) are sent
immediately
Window slides
● Characteristic:
the window size
can be changed 1 2 3 4 5 6 7 8 9 10
during the
transmission phase
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.79
TCP Flow Control: Sliding
g Window,, Example
p
2K
ACK=2048 WIN=2048
Application
writes
it 2 KB
2K SEQ = 2048
Full
Sender is ACK 4096 WIN=0
ACK=4096 WIN 0
blocked Application
reads 2 KB
ACK=4096 WIN=2048 2K
Sender can
transfer up
to 2 KB
1K SEQ = 4096
1K 2K
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.80
“Sillyy Window” Syndrome
y
1 byte
Solution of Clark:
The receiver must wait with the next window actualization until the receiver buffer
again is reasonably empty.
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.81
The whole TCP Session
Client Server
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.82
Flow Control: Network Bottlenecks
Assumption:
packet loss is rarely because of
transmission errors, rather
because of overload situations.
Necessary:
Congestion Control
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.83
Principles of Congestion Control
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.84
Principles
p of Congestion
g Control
● Congestion:
● Informally: “too
too many sources sending too much data too fast for network to
handle”
● Different from flow control!
● Manifestations:
M if t ti
● Lost packets (buffer overflow at routers)
● Long delays (queueing in router buffers)
● A top-10 problem!
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.85
Causes/costs of congestion:
g Scenario 1
● Two senders, two receivers Host A λout
● One router
router, infinite buffers λin : original data
● No retransmission
Host B unlimited shared
output link buffers
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.86
Causes/costs of congestion:
g Scenario 2
● One router, finite buffers
● Sender retransmission of lost packet
● Offered load λ’in: Original data + retransmitted data
C
Capacity
it off link
li k R
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.87
Causes/costs of congestion:
g Scenario 2
● Always: λin=λout (goodput)
● “perfect”
perfect retransmission only when loss: λλ’in
i = λoutt
● Retransmission of delayed (not lost) packet makes λ’in larger (than perfect
case) for same λout
R/3
λout
λout
λout
R/4
● “Costs” of congestion:
● More work (retrans) for given “goodput”
● Unneeded retransmissions: link carries multiple copies of packet
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.88
Causes/costs of congestion:
g Scenario 3
● Four senders What happens as λ
and λ increase?
in
● Multi
Multi-hop
hop paths
in
● Timeout/retransmit
Host A λout
λin : original data
λ'in : original data, plus
retransmitted data
finite shared
output link
buffers
Host B
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.89
Causes/costs of congestion:
g Scenario 3
H λ
o
o
s
u
t
A t
H
o
s
t
B
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.90
Approaches
pp towards congestion
g control
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.91
Case study:
y ATM ABR congestion
g control
● ABR: available bit rate: ● RM (resource management) cells:
● “elastic
elastic service”
service ● Sent by sender, interspersed with
● If sender’s path “underloaded”: data cells
● Sender should use available ● Bits in RM cell set by switches
bandwidth ((“network-assisted”)
network-assisted )
● If sender’s path congested: ● NI bit: no increase in rate
● Sender throttled to minimum (mild congestion)
guaranteed
t d ratet ● CI bit: congestion indication
● RM cells returned to sender by
receiver, with bits intact
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.92
Case study:
y ATM ABR congestion
g control
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.93
Transmission Control Protocol (TCP)
Congestion control
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.94
TCP congestion control:
additive increase,, multiplicative
p 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
Addi i Increase
Additive I Multiplicative
M l i li i Decrease
D (AIMD)
16 Kbytes
8 Kbytes
Time
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.95
TCP Congestion
g Control: Details
● Sender limits transmission: ● How does sender perceive
LastByteSent
a y d ≤ CongWin
- LastByteAcked
a y o g congestion?
g
Loss event = Timeout or
3 duplicate acks
● Roughly:
rate =
CongWin
Bytes/sec
● TCP sender reduces rate
RTT (CongWin)
g after loss event
● Three mechanisms:
● CongWin is dynamic, function of
● AIMD
perceived network congestion
● Slow start
● Conservative after timeout events
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.96
TCP Slow Start
● When connection begins, CongWin = 1 MSS
● Example: MSS = 500 bytes & RTT = 200 msec
● Initial rate = 20 kbps
● When connection begins, increase rate exponentially fast until first loss
event
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.97
TCP Slow Start
● Each sender maintains two windows for the number of bytes which can be
sent:
● Flow
Fl C
Control
t l Wi
Window:
d granted
t d receiver
i buffer
b ff
● Congestion Window: “network granted” capacity (cwnd)
● Minimum of both windows is the maximum number of bytes that can be sent
● With connection
ti establishment,
t bli h t the
th sender
d initializes
i iti li the
th congestion
ti window
i d
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
value. Thus a “grope”
grope takes place up to the
transmission capacity.
● Enlargement stops with reaching the flow control window
● Refinement byy 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
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.98
TCP Slow Start
RTT
● Double CongWin
g everyy RTT
● Done by incrementing CongWin
for every ACK received
● Summary:
●Initial rate is slow but ramps
up exponentially fast
time
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.99
TCP Slow Start
Congestion Avoidance, Overload assumed,
groping to the reduce the data
maximum capacity amount
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.101
Fast Retransmit and Fast Recoveryy
● Slow Start is not well suited when only a single packet is lost…
● Time
Time-out
out period often relatively long ¨ Long delay before resending lost packet
● Fast Retransmit
● The receiver sends a duplicate ACK immediately when an out-of-order segment
arrives
● When the sender has received 3 duplicate
p ACKs,, it retransmits the missing
g
segment.
● Hopefully, the acknowledgement for the repeated segment arrives before a timeout
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.102
Fast Retransmit
Host A Host B
Timeout
T
Time
● Implementation:
p
● Variable Threshold
● At loss event, Threshold is set to
1/2 of CongWin just before loss
event
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.104
Fast Retransmit and Fast Recoveryy
● 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
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.105
Fast Retransmit and Fast Recoveryy
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.106
Summary:
y TCP Congestion
g Control
● 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,
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.
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.107
TCP sender congestion
g control
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.108
Transmission Control Protocol (TCP)
TCP Throughput
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.109
TCP throughput
g p
● 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 throughout: (W/RTT+W/2RTT)/2 ¨ 0.75W/RTT
0 75W/RTT
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.110
TCP Futures: TCP over “long,
g, fat pipes”
pp
● Example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput
● Requires window size W = 83,333
83 333 in-flight
in flight segments
● Throughput in terms of loss rate:
1.22 ⋅ MSS
SS
RTT L
¨L = 2·10-10
● New versions of TCP for high-speed
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.111
Transmission Control Protocol (TCP)
Fairness
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.112
TCP Fairness
● Fairness goal: if k TCP sessions share same bottleneck link of bandwidth
R,, each should have average
g rate of R/K
TCP connection
ti 1
bottleneck
router
capacity R
TCP
connection 2
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.113
Whyy is TCP fair?
Connection 1 throughput
R
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.114
Fairness (more)
( )
● Fairness and UDP ● Fairness and parallel TCP
● Multimedia apps often do not use connections
TCP ● nothing prevents app from opening
● do not want rate throttled by parallel connections between 2
congestion control hosts
hosts.
● Instead use UDP: ● Web browsers do this
● pump audio/video at constant rate, ● Example: link of rate R supporting 9
tolerate packet loss connections;
ti
● Research area: TCP friendly ● new app asks for 1 TCP, gets rate
R/10
● new app asks for 11 TCPs, gets R/2
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.115
Transmission Control Protocol (TCP)
TCP in Wireless Networks
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.116
TCP in Wireless Networks
● Theoretically the transport layer protocol should be independent of lower
layers
y
● But TCP is optimized for wired networks
● TCP assumes that packet loss is due to congestion in the network
● In
I wireless
i l networks
k packet
k loss
l occurs due
d to the
h medium
di
● Thus, performance of TCP in wireless networks is poor
● Many approaches to solve the performance problem
● Indirect TCP (as an example)
● The end-to-end connection is broken in two parts
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.117
Transmission Control Protocol (TCP)
TCP and Security
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.118
TCP and Security:
y Syn-Flood
y
● During connection establishment Client Server
the client does not finish the
Three Way Handshake procedure
● A half open connection Normal
● Operating
Ope ting system
tem reserves
e e e scenario
resources
Syn-
Flood
attack
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.119
TCP and Security:
y Syn-Flood
y
● Countermeasure: Syn cookies Client Server
● Server does not creates a half-open
half open
connection
y=h()
● Server computes an initial sequence
number y based on a hash function
● This is the cookie
● When client returns with ACK the Check y
server recomputes
t the
th hhash
h
function and checks it
● For legitimate connection the check
will
ill be
b successful
f l
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.120
Some Tools
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.121
Some Tools / netstat
● netstat: Displays protocol statistics and TCP/IP network connections
● Flags
● n: display IP addresses
● b: display executable
● r: routing table
x:\>netstat -n
A ti
Active C
Connections
ti
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.122
Some Tools
● TTCP – Test TCP
● A tool to measure throughput in a network via TCP and UDP
● Iperf
● Similar tool to test network throughput
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.123
Summaryy
● The TCP/IP reference model has only two protocols on the transport layer
● UDP for connectionless, but lightweight protocol
● TCP for connection oriented and reliable communication
● Connection establishment
● Flow
Fl control
t l / congestion
ti control
t l
● Connection termination
● Fairness
● Some tools
● netstat
● iperf
● ttcp
Prof. Dr. Mesut Güneş ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 7: Transport Layer 7.124