Transcript Transport Layer Foreleser: Carsten Griwodz Email:

Transport Layer
Foreleser: Carsten Griwodz
Email: [email protected]
25. Mar. 2004
1
INF-3190: Transport Layer
TCP
Reliability and Ordering
Duplicates
25. Mar. 2004
2
INF-3190: Transport Layer
Duplicates
•
Initial Situation: Problem
•
•
•
Varying transit times for packets
Certain loss rate
Storage capabilities
Money
transfer
Packets can be
•
•
•
•
Manipulated
Duplicated
Resent by the original system after
timeout
DUP
In the following, uniform term:
"Duplicate“
•
•
Bank
Network has
•
•
Customer
A duplicate originates due to one of
the above mentioned reasons
and
Is at a later (undesired) point in time
passed to the receiver
25. Mar. 2004
3
Money
transfer
is repeated
DUP
DUP
time
time
INF-3190: Transport Layer
Duplicates
•
Possible error causes and
consequences
•
Cause
•
Network capabilities
•
•
•
DUP
Flood-and-prune approach to
routing in wireless networks
All acknowledgements lost
Consequence
•
•
•
DUP
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
•
•
25. Mar. 2004
DUP
Controlled duplication of sender’s
packets
Duplicates arrive in an order
expected by the application
4
•
Result
•
Without additional means
•
•
Receiver cannot
differentiate between
correct data and
duplicated data
Would re-execute the
transaction
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 connections
or
Connections which are being re-established after a crash?
What can be done to ensure that a connection that
has been established
•
•
25. Mar. 2004
Has actually been initiated by
and
With the knowledge of both communicating parties?
5
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
•
•
25. Mar. 2004
Server is reached via a designated port
Some ports always exist as "well known“
6
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
7
INF-3190: Transport Layer
Duplicates: Methods of Resolution
•
Identify packets individually
•
•
Method
•
•
•
Individual sequential numbers for each packet
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
8
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
•
•
i.e., ACK (N-ACK) have to be included
•
•
All packets with this sequence number
or references to this sequence number
are extinct
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
t
T=2t+e
Example 2: Request/response
Taking processing time into account
t
Emax
t
T=2t+Emax
25. Mar. 2004
9
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
10
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
•
25. Mar. 2004
2 minutes
11
INF-3190: Transport Layer
TCP
Reliability and Ordering
Initial sequence number allocation
25. Mar. 2004
12
INF-3190: Transport Layer
Handling of Consecutive Connections
•
TCP’s approach
•
•
•
Duplicate handling through individual sequential numbers
•
•
•
•
Individual sequential numbers per connection
Connection identified by (cl addr, cl port, srv address, srv port, TCPid)
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
•
25. Mar. 2004
Within an MSL
13
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)
e.g. 232-1
T
Wraparound
ISN
SeqNo
ISN
ISN
Initial Sequence Number
25. Mar. 2004
time
“Forbidden Region”
Width T (max. theoretic packet lifetime)
14
INF-3190: Transport Layer
Handling of Consecutive Connections
T
T
SeqNo
T
time
•
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
25. Mar. 2004
15
INF-3190: Transport Layer
Handling of Consecutive Connections
T
T
T
SeqNo
Same SeqNo
Within T
Packet rate
Too high
time
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
•
•
25. Mar. 2004
Curve of the consecutively allocated sequence numbers steeper
than ISN curve (enters from underneath)
16
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
•
•

Use PAWS
•
•
•
•
"Protect Against Wrapped Sequence Numbers“
"TCP extensions for highspeed paths“
Use TCP 32-bit timestamp option in each packet
Reject packet
•
•
today at 1 Gbps
in 17 sec
If timestamp is lower than last recorded
and 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
17
INF-3190: Transport Layer
Flow Control
25. Mar. 2004
18
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
19
INF-3190: Transport Layer
Sliding Window / Static Buffer Allocation
•
Flow control
•
•
Buffer reservation
•
•
Sliding window - mechanism with window size w
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
•
25. Mar. 2004
(e.g. interactive applications)
20
INF-3190: Transport Layer
Sliding Window / No Buffer Allocation
•
Flow control
•
•
Buffer reservation
•
•
•
•
•
Sliding window (or no flow control)
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
21
INF-3190: Transport Layer
Credit Mechanism
•
Flow control
•
•
Buffer reservation
•
•
•
Credit mechanism
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
22
INF-3190: Transport Layer
TCP Flow Control
Sender
Receiver
A wants 8 buffers
<req 8 buffers>
A has 3 buffers left
A has 2 buffers left
Message lost but A thinks it has 1 left
B grants messages 0-3 only
<cred=4>
<seq=0, data=m0>
Message lost
<seq=1, data=m1>
B acknowledges 0 and 1
permits 2-4
<seq=2, data=m2>
<ack=1, cred=3>
A has 1 buffer left
<seq=3, data=m3>
Everything acknowledged
but no free buffers
<seq=4, data=m4>
A has 0 buffer left, must stop
A times out and retransmits
<seq=2, data=m2>
<ack=4, cred=1>
A still blocked
A may now send next msg.
A has 1 buffer left
<ack=4, cred=2>
25. Mar. 2004
A has 1 buffer left
<seq=5, data=m5>
A is now blocked again
<seq=6, data=m6>
<ack=6, cred=0>
<ack=6, cred=4>
A is now blocked again
A still blocked
B found a new buffer
somewhere
<ack=4, cred=0>
time
time
23
INF-3190: Transport Layer
Credit Mechanism
•
Dynamic adjustment to
•
•
•
Buffer situation
Number of open connections
Type of connections
•
•
25. Mar. 2004
high throughput: many buffers
low throughput: few buffers
24
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
Version
IHL
Type
PRE of service
ToS
Total length
Identification
DM
Fragment offset
Time to live
Protocol
Header checksum
Source address
Destination Address
Options
Source port
Destination port
Sequence number
Piggyback acknowledgement
THL
unused U A P R S F
Window
Checksum
Urgent pointer
Options (0 or more 32 bit words)
Data
25. Mar. 2004
25
Sequence number and
acknowledgements
Credit
THL – TCP header length
U: URG – urgent
A: ACK – acknowledgement
P: PSH – push
R: RST – reset
S: SYN – sync
F: FIN – finalize
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
•
•
•
25. Mar. 2004
Byte position in the data stream up to which all data has been received
correctly
Reduction of overhead
More tolerable to lost acknowledgements
27
INF-3190: Transport Layer
TCP Flow Control
Sender
Receiver
Application does
a 2K write
4K buffer
Sender is blocked
2K
Application does
a 2K write
Sender is blocked
Application reads 2K
2K
Sender could send 2K
but application does
only a 1K write
time
25. Mar. 2004
time
28
1K
2K
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
•
•
•
•
•
Approach often used
•
•
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
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
•
25. Mar. 2004
Effect at e.g. X-windows: jerky pointer movements
29
INF-3190: Transport Layer
TCP Flow Control: Special Cases
Sender
window size=0
Receive buffer full
Application reads one byte
Room for one byte
Header
Window update segment sent
Header
New byte arrives
1 byte
•
Receive buffer full
Silly window syndrome (Clark, 1982)
•
Problem
•
•
•
Clark’s solution
•
•
•
Data on sending side arrives in large blocks
But receiving side reads data at one byte at a time only
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 establishment
Y = buffer / 2
25. Mar. 2004
30
INF-3190: Transport Layer