25. Mar. 2004 1 INF-3190: Transport Layer
Transport Layer
Foreleser: Carsten GriwodzEmail: [email protected]
25. Mar. 2004 2 INF-3190: Transport Layer
TCPReliability and Ordering
Duplicates
25. Mar. 2004 3 INF-3190: Transport Layer
Duplicates• Initial Situation: Problem
• Network has• Varying transit times for packets• Certain loss rate• Storage capabilities
• Packets can be• Manipulated• Duplicated• Resent by the original system
after timeout• In the following, uniform term:
"Duplicate“• A duplicate originates due to one
of the above mentioned reasonsand
• Is at a later (undesired) point in time passed to the receiver
Customer Bank
time time
CR
CC
DATA
ACK
REL
CC
ACK
CR
DATA
REL
DUP
DUP
DUP
Moneytransfer
Moneytransferis repeated
25. Mar. 2004 4 INF-3190: Transport Layer
Duplicates• Possible error causes and
consequences• Cause
• Network capabilities• Flood-and-prune approach to
routing in wireless networks• All acknowledgements lost
• Consequence• Duplication of sender’s packets • Duplicates arrive in the same
order as originals
• Cause• Man-in-the-middle attack• Packets are captured and
replayed• Consequence
• Controlled duplication of sender’s packets
• Duplicates arrive in an order expected by the application
• Result• Without additional
means• Receiver cannot
differentiate between correct data and duplicated data
• Would re-execute the transaction
CC
ACK
CR
DATA
REL
DUP
DUP
DUP
25. Mar. 2004 5 INF-3190: Transport Layer
Duplicates: Problematic Issues• 3 somehow disjoint problems
• How to handle duplicates within a connection?
• What characteristics have to be taken into account regarding
• Consecutive connectionsor
• Connections which are being re-established after a crash?
• What can be done to ensure that a connection that has been established
• Has actually been initiated byand
• With the knowledge of both communicating parties?
25. Mar. 2004 6 INF-3190: Transport Layer
Duplicates: Methods of Resolution
• Using temporary valid ports• Method
• Port valid for one connection only• Generate always new port
• Evaluation• In general not applicable:
process server addressing method not possible, because
• Server is reached via a designated port• Some ports always exist as "well known“
25. Mar. 2004 7 INF-3190: Transport Layer
Duplicates: Methods of Resolution
• Identify connections individually• Method
• Each individual connection is assigned a new sequence number and
• End-systems remember already assigned sequence number
• Evaluation• End-systems must be capable of storing this information• Prerequisite
• Connection oriented system• End-systems, however, will be switched off and
it is necessary that the information is reliably available whenever needed
25. Mar. 2004 8 INF-3190: Transport Layer
Duplicates: Methods of Resolution
• Identify packets individually• Individual sequential numbers for each packet
• Method• Sequence number basically never gets reset• e.g. 48 bit at 1000 msg/sec: reiteration after ~8930
years
• Evaluation• Higher usage of bandwidth and memory• Sensible choice of the sequential number range
depends on• The packet rate• A packet’s probable "lifetime" within the network
• Discussed in more detail in the following
25. Mar. 2004 9 INF-3190: Transport Layer
Duplicates: Limiting Packet Lifetime• Enabling the above Method 3
Identify packets individually: individual sequential numbers for each packet
• Sequence number only reissued if• All packets with this sequence
numberor references to this sequence number are extinct
• i.e., ACK (N-ACK) have to be included• Otherwise new packet may be
wrongfully confirmed or non-confirmed by delayed ACK (N-ACK)
• Mandatory prerequisite for this solution
• Limited packet lifetime• I.e. introduction of a respective
parameter T
Example 1 (in principle)
T=2t+
MSG(s) t
MSG(s)t
Example 2: Request/responseTaking processing time into account
T=2t+Emax
REQ(s) t
RES(s)t
Emax
25. Mar. 2004 10 INF-3190: Transport Layer
Duplicates: Limiting Packet Lifetime• Limitation by appropriate network design
• Inhibit loops• Limitation of delays in subsystems & adjacent systems
• Hop-counter / time-to-live in each packet• Counts traversed systems• If counter exceeds maximum value
packet is discarded
• Time marker in each packet• Packet exceeds maximum configurable lifetime
packet is discarded• Note: requires "consistent" network time
25. Mar. 2004 11 INF-3190: Transport Layer
Duplicates: Limiting Packet Lifetime• Determining maximum time T, which a
packet may remain in the network• T is a small multiple of the (real maximal)
packet lifetime t• T time units after sending a packet
• The packet itself is no longer valid• All of its (N)ACKs are no longer valid
• TCP/IP term: Maximum Segment Lifetime (MSL)
• To be imposed by IP layer• Defined by and referenced by other protocol
specifications• 2 minutes
25. Mar. 2004 12 INF-3190: Transport Layer
TCPReliability and Ordering
Initial sequence number allocation
25. Mar. 2004 13 INF-3190: Transport Layer
Handling of Consecutive Connections• TCP’s approach
• Individual sequential numbers per connection• Connection identified by (cl addr, cl port, srv address, srv port,
TCPid)
• Duplicate handling through individual sequential numbers• Consecutive sequential numbers from sufficiently large
sequential number range• Resolves problems with duplicates within a single connection• Duplicates are all other packets with the same sequential
number
• Problem• Packets from connections that can not be distinguished?• Due to
• Restart after crash• Reconnect between exactly the same communication entities
• Within an MSL
25. Mar. 2004 14 INF-3190: Transport Layer
Handling of Consecutive Connections• Method
• End-systems timer continues to run at switch-off / system crash• Allocation of initial sequence number (ISN) depends on
• time markers (linear or stepwise curve because of discrete time)• Sequence numbers can be allocated consecutively within a connection
(steadily growing curve)
time
SeqN
o
ISNInitial Sequence Number
“Forbidden Region”Width T (max. theoretic packet lifetime)
e.g. 232-1 Wraparound
ISN ISN
T
25. Mar. 2004 15 INF-3190: Transport Layer
Handling of Consecutive Connections
• No problem, if• “Normal lived” session (shorter than wrap-around time) with
data rate smaller than ISN rate (ascending curve less steep)
• Then, after crash• Reliable continuation of work always ensured• System clock may be used to continue with correct ISN
time
SeqN
o
TT T
25. Mar. 2004 16 INF-3190: Transport Layer
Handling of Consecutive Connections
• Problems• “Long-lived”, “slow” session (longer than wrap-around
time)• Sequence number is used within time period T before it is
used as initial sequence number ”Forbidden Region" - begins T before ISN is generated
• High data rate• Curve of the consecutively allocated sequence numbers
steeper than ISN curve (enters from underneath)
time
SeqN
oTT T
Same SeqNoWithin T
Packet rateToo high
25. Mar. 2004 17 INF-3190: Transport Layer
Handling of Consecutive Connections• Note
• 32 bit sequence numbers with technology considered as sufficient when designing TCP/IP
• Sequence number range exploitation• today at 1 Gbps• in 17 sec
Use PAWS• "Protect Against Wrapped Sequence Numbers“• "TCP extensions for highspeed paths“• Use TCP 32-bit timestamp option in each packet• Reject packet
• If timestamp is lower than last recordedand sequence number is higher
• Further literature in addition to Tanenbaum• RFC 793 (TCP) / Sequence Numbers; "When to keep quiet“• RFC 1185 / Appendix - Protection against Old Duplicates• RFC 1323 / PAWS
25. Mar. 2004 18 INF-3190: Transport Layer
Flow Control
25. Mar. 2004 19 INF-3190: Transport Layer
Flow Control on Transport Layer• Joint characteristics (flow control on data link layer)
• Fast sender shall not flood slow receiver• Sender shall not have to store all not acknowledged
packets
• Differences (flow control on data link layer)• Link layer: router serves few “bitpipes”• Transport layer: end-system contains a multitude of
• Connections• Data transfer sequences
• Transport layer: receiver may store packets
• Strategies• Sliding window / static buffer allocation• Sliding window / no buffer allocation• Credit mechanism / dynamic buffer allocation
25. Mar. 2004 20 INF-3190: Transport Layer
Sliding Window / Static Buffer Allocation
• Flow control• Sliding window - mechanism with window size w
• Buffer reservation• Receiver reserves 2*w buffers per duplex connection
• Characteristics+ Receiver can accept all packets- Buffer requirement may be very high
• proportional to #transp.-connections- Poor buffer utilization for low throughput connections
• I.e.=> Good for traffic with high throughput
• (e.g. data transfer)=> Poor for bursty traffic with low throughput
• (e.g. interactive applications)
25. Mar. 2004 21 INF-3190: Transport Layer
Sliding Window / No Buffer Allocation• Flow control
• Sliding window (or no flow control)
• Buffer reservation• Receivers do not reserve buffers• Buffers allocated out of shared buffer space upon arrival of
packets• Packets are discarded if there are no buffers available• Sender maintains packet buffer until ACK arrives from receiver
• Characteristics+ Optimized storage utilization- Possibly high rate of ignored packets during high traffic load
• I.e.=> Good for bursty traffic with low throughput=> Poor for traffic with high throughput
25. Mar. 2004 22 INF-3190: Transport Layer
Credit Mechanism• Flow control
• Credit mechanism
• Buffer reservation• Receiver allocates buffers dynamically for the
connections• Allocation depends on the actual situation
• Principle• Sender requests required buffer amount• Receiver reserves as many buffers as the actual
situation permits• Receiver returns ACKs and buffer-credits separately
• ACK: confirmation only (does not imply buffer release)• CREDIT: buffer allocation
• Sender is blocked when all credits are used up
25. Mar. 2004 23 INF-3190: Transport Layer
TCP Flow ControlSender Receiver
time time
<req 8 buffers>
<cred=4>
<seq=0, data=m0>
<seq=1, data=m1>
<seq=2, data=m2>
<ack=1, cred=3>
<seq=3, data=m3>
<seq=4, data=m4>
<seq=2, data=m2>
<ack=4, cred=0>
<ack=4, cred=1>
<ack=4, cred=2>
<seq=5, data=m5>
<seq=6, data=m6>
<ack=6, cred=0>
<ack=6, cred=4>
A wants 8 buffers
A has 3 buffers left
A has 2 buffers left
Message lost but A thinks it has 1 left
A has 1 buffer left
A has 0 buffer left, must stop
A times out and retransmits
A still blocked
A may now send next msg.
A has 1 buffer left
A is now blocked again
A still blocked
B grants messages 0-3 only
Message lost
B acknowledges 0 and 1permits 2-4
Everything acknowledgedbut no free buffers
B found a new buffersomewhere
A has 1 buffer left
A is now blocked again
25. Mar. 2004 24 INF-3190: Transport Layer
Credit Mechanism• Dynamic adjustment to
• Buffer situation• Number of open connections• Type of connections
• high throughput: many buffers• low throughput: few buffers
25. Mar. 2004 25 INF-3190: Transport Layer
TCP Flow Control• Variable window sizes (credit mechanism)
• Implementation• The actual window size is also transmitted with each
acknowledgement• Permits dynamic adjustment to existing buffer
Destination AddressSource address
Time to live Protocol Header checksumIdentification DM Fragment offset
Version IHL Type of service Total lengthPRE ToS
Data
OptionsSource port Destination port
Sequence numberPiggyback acknowledgement
THL
THL – TCP header lengthU: URG – urgentA: ACK – acknowledgementP: PSH – pushR: RST – resetS: SYN – syncF: FIN – finalize
F WindowSRPAUunusedChecksum Urgent pointer
Options (0 or more 32 bit words)
Sequence number andacknowledgements
Credit
25. Mar. 2004 27 INF-3190: Transport Layer
TCP Flow Control• “Sliding window” mechanism
• Sequence number space is limited• No buffers longer than 232 possible
• Acknowledgement and sequence number• Acknowledgments refer to byte positions
• Not to whole segment• Sequence numbers refer to the byte position of a TCP
connection
• Positive acknowledgement• Cumulative acknowledgements
• Byte position in the data stream up to which all data has been received correctly
• Reduction of overhead• More tolerable to lost acknowledgements
25. Mar. 2004 28 INF-3190: Transport Layer
TCP Flow ControlSender Receiver
time time
2K / SEQ=0
ACK=2048 WIN=2048
2K / SEQ=2048
ACK=4096 WIN=0
ACK=4096 WIN=2048
1K / SEQ=4096
Application doesa 2K write
Application doesa 2K write
Sender could send 2Kbut application does
only a 1K write
Sender is blocked
Sender is blocked
4K buffer
2K
Application reads 2K
2K1K
2K
25. Mar. 2004 29 INF-3190: Transport Layer
TCP Flow Control: Special Cases• Optimization for low throughput rate
• Problem• Telnet (and ssh) connection to interactive editor reacting on every
keystroke• 1 character typed requires up to 162 byte
• Data: 20 bytes TCP header, 20 bytes IP header, 1 byte payload• ACK: 20 bytes TCP header, 20 bytes IP header• Echo: 20 bytes TCP header, 20 bytes IP header, 1 byte payload• ACK: 20 bytes TCP header, 20 bytes IP header
• Approach often used• Delay acknowledgment and window update by 500 ms (hoping for more
data)
• Nagle’s algorithm, 1984• Algorithm
• Send first byte immediately• Keep on buffering bytes until first byte has been acknowledged• Then send all buffered characters in one TCP segment and start buffering
again• Comment
• Effect at e.g. X-windows: jerky pointer movements
25. Mar. 2004 30 INF-3190: Transport Layer
TCP Flow Control: Special Cases
• Silly window syndrome (Clark, 1982)• Problem
• Data on sending side arrives in large blocks• But receiving side reads data at one byte at a time only
• Clark’s solution• Prevent receiver from sending window update for 1 byte• Certain amount of space must be available in order to send window update
• min(X,Y)X = maximum segment size announced during connection establishmentY = buffer / 2
Senderwindow size=0
Header
Header
1 byte
Receive buffer full
Room for one byte
Receive buffer full
New byte arrives
Window update segment sent
Application reads one byte
Top Related