Transport Layer Foreleser Carsten Griwodz Email griffifi uio

Transport Layer Foreleser: Carsten Griwodz Email: griff@ifi. uio. no 25. Mar. 2004 1 INF-3190: Transport Layer

TCP Reliability and Ordering Duplicates 25. Mar. 2004 2 INF-3190: Transport Layer

Duplicates • • Network has • • • Varying transit times for packets Certain loss rate Storage capabilities CC DATA • Manipulated Duplicated Resent by the original system after timeout 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 Money transfer ACK REL DUP CR CC In the following, uniform term: "Duplicate“ • Bank CR Packets can be • • Customer Initial Situation: Problem 3 D DUP ATA ACK Money transfer is repeated DUP REL time INF-3190: Transport Layer

Duplicates • Possible error causes and consequences • Cause • Network capabilities • • • Man-in-the-middle attack Packets are captured and replayed Consequence • • 25. Mar. 2004 ACK DUP REL Duplication of sender’s packets Duplicates arrive in the same order as originals Cause • D DUP ATA Flood-and-prune approach to routing in wireless networks All acknowledgements lost Consequence • • DUP CR CC 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 • • MS G(s ) G(s S M Otherwise new packet may be wrongfully confirmed or non-confirmed by delayed ACK (N-ACK) • Limited packet lifetime I. e. introduction of a respective parameter T t t T=2 t+e Example 2: Request/response Taking processing time into account REQ Mandatory prerequisite for this solution • ) i. e. , ACK (N-ACK) have to be included • • All packets with this sequence number or references to this sequence number are extinct Example 1 (in principle) (s) t Emax RES (s) t T=2 t+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 Seq. No 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 Seq. No 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 Seq. No Same Seq. No 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=m 0> Message lost <seq=1, data=m 1> B acknowledges 0 and 1 permits 2 -4 <seq=2, data=m 2> <ack=1, cred=3> A has 1 buffer left <seq=3, data=m 3> Everything acknowledged but no free buffers <seq=4, data=m 4> A has 0 buffer left, must stop A times out and retransmits <seq=2, data=m 2> <ack=4, cred=1> A still blocked A may now send next msg. B found a new buffer somewhere <ack=4, cred=0> <ack=4, cred=2> A has 1 buffer left <seq=5, data=m 5> A is now blocked again <seq=6, data=m 6> A has 1 buffer left <ack=6, cred=0> <ack=6, cred=4> A is now blocked again A still blocked 25. Mar. 2004 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 To. S 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 Application does a 2 K write Receiver 4 K buffer 2 K / SEQ=0 Sender is blocked IN=2048 2 K 8 W ACK=204 Application does a 2 K write 2 K / SEQ=2 048 6 WIN= ACK=409 Sender is blocked 0 Application reads 2 K IN=2048 6 W ACK=409 Sender could send 2 K but application does only a 1 K write 1 K / SEQ=4 096 time 25. Mar. 2004 2 K time 28 1 K 2 K 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