CEN445 NetworkProtocolsandAlgorithms
Chapter6 TransportLayer
6.2ElementsofTransportProtocols
Dr. Mostafa Hassan Dahshan
Department of Computer Engineering
College of Computer and Information Sciences
King Saud University
[email protected] http://faculty.ksu.edu.sa/mdahshan
ElementsofTransportProtocols
Transport protocol similar to data link protocols
Both do error control and flow control
However, significant differences exist
Environment of the data link layer Environment of the transport layer
2
ElementsofTransportProtocols
Data link layer Transport layer
Communication directly via physical channel over the entire network
Addressing no need to specify address. explicit addressing of
Just select outgoing line destination is required
Connection over a wire is simple more complicated
establishment
Delay frame either arrives or lost, fackets might be stored for
not stored and delayed seconds and delivered later
Buffering and simpler more complicated;
flow control large and dynamic number of
simultaneous connections
Addressing
Specify which host process to connect to
TSAP: Transport Service Access Point
In TCP, UDP, called ports
Analogy: NSAP. Example: IP address
Client or server app attaches to TSAP
Connections run through NSAP
TSAP to distinguish endpoints sharing NSAP
4
Addressing
Addressing
How host1 process knows TSAP # at host2?
Stable TSAP # listed in wellknown places
e.g. /etc/services in UNIX list permanent #s
mail server: 25, web server: 80
Alternatively, special process: portmapper
listen on wellknown TSAP
user conn to portmapper, specify service name
portmapper sends back TSAP address
similar to directory service ()
6
Addressing
Many server processes used only rarely
Waste if each process listen to TSAP all day
Instead, use initial connection protocol
Spec process server listens all known TSAP
Act as proxy for lightly used servers
e.g. inted, xinetd on UNIX
Addressing
User does CONNECT request Process server spawns request server
8
ConnectionEstablishment
Sounds easy; surprisingly tricky!
Just send REQUEST, wait for ACCEPTED?
Can lose, delay, corrupt, duplicate packets
Duplicate may transfer bank money again!
Protocols must work correct all cases
Implemented efficiently in common cases
Main problem is delayed duplicates
Cannot prevent; must deal with (reject)
9
ConnectionEstablishment
Solutions for delayed duplicates
Not reuse transport address (TSAP)
problem difficult to connect to process
Give each connection unique ID
seq # chosen by initiating party
update table listing obsolete connections
check new connections against table
problems requires maintain certain amount of history
if machine crashes, no longer identify old con
10
ConnectionEstablishment
To simplify problem, restrict packet lifetime
restricted network design: prevent looping
mostly used hop counter in each packet: 1 at each hop
timestamp in each packet: clock must be synced
Must also guarantee ACKs are dead
Assume a value T of max packet lifetime
T sec after packet sent, sure traces are gone
In the Internet, T is usually 120 seconds
11
ConnectionEstablishment
New method with packet lifetime bounded
Label segments with seq # not reused in T
T and packet rate determine size of seq #s
1 packet w given seq # may be outstanding
Duplicates may still occur, but discarded dst
Not possible to have delayed duplicate old
packet with same seq # accepted at dest
12
ConnectionEstablishment
How to deal with losing memory after crash?
Each host has timeofday clock
clocks at different host need not be synced
binary counter increments uniform intervals
no. of bits must be of seq #
clock must be running even if host goes down
Initial seq # (kbits) low kbits of clock
Seq space must be so large
by time # wrap, old pkts w same # are long gone
13
ConnectionEstablishment
Clock method work within connection
Host dont remember # across connections
Cant know if CONN REQUEST with initial
seq # is a duplicate of a recent connection
To solve this, use threeway handshake
Check with other peer that con req is current
Used in TCP, with 32bit seq #
Clock not used in TCP; attacker can predict
14
ConnectionEstablishment
CR = Connection Request
Normal Procedure
H1 choses initial s# x
H2 replies
ACKs x
announce own s# y
H1replies
ACKs y
with 1st data segment
15
ConnectionEstablishment
Abnormal situations
Delayed duplicate CR
H2 sends ACK to H1
X
H1 rejects
H2 knows it was tricked
Worst case
DD CR, old ACK floating
H2 gets delayed CR, replies
X
H1 rejects
X
H2 gets old DATA, discards
(z received instead of y) 16
ConnectionRelease
Easier than establish
However, some pitfalls
Asymmetric release
each con term separately
abrupt; may cause data loss
better protocol needed
17
ConnectionRelease
Symmetric release
Each direction is released independently
Can receive data after sending DISCONNECT
H1: I am done, are you done too?
H2: I am done too, goodbye
Twoarmy problem: unreliable channel
18
ConnectionRelease
Twoarmy problem
each blue army < white army, but together are larger
need to sync attack
however, only com channel is the valley (unreliable)
3way handshake? B1 cant know ACK arrived
making 4way handshake doesnt help either
Attack? Attack?
19
ConnectionRelease
Let each side independently decide its done
Easier to solve
Normal release sequence
H1 send DR, start timer
H2 responds with DR
when H1 recv DR, release
when H2 recv ACK, release
20
ConnectionRelease
Error cases, handled by timers, retransmissions
Final ACK lost: Lost DR: Extreme:
Host 2 times out H1 starts over Many lost DRs
both release after N
21
ConnectionRelease
Protocol usually suffices; can fail in theory
after N lost attempts; half open connection
Not allowing give up, can go on forever
To kill half open connections, automatically
disconnect if no received segments in X sec
Must have timer reset after each segment
Send dummy segments to keep con alive
TCP normally does symmetric close, with
each side independently close con w FIN 22
Multiplexing
Transport, network sharing can either be:
Multiplexing: connections share a network address
Inverse multiplexing: addresses share a connection
Multiplexing Inverse Multiplexing 23
