Transport Layer

25. Mar. 2004 1 INF-3190: Transport Layer

Transport Layer

Foreleser: Carsten GriwodzEmail: [email protected]


TCPReliability and Ordering

Duplicates


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


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


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?


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“



• 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



• 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


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


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


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


TCPReliability and Ordering

Initial sequence number allocation


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


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


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


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


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


Flow Control


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


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)


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


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


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


Credit Mechanism• Dynamic adjustment to

• Buffer situation• Number of open connections• Type of connections

• high throughput: many buffers• low throughput: few buffers


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


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


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


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


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

Transport Layer

Documents

Transcript of Transport Layer