1 / 29

Transport Layer

Transport Layer. Foreleser: Carsten Griwodz Email: griff@ifi.uio.no. TCP Reliability and Ordering. Duplicates. DATA. REL. CR. ACK. ACK. CC. CC. Duplicates. Initial Situation: Problem Network has Varying transit times for packets Certain loss rate Storage capabilities

Download Presentation

Transport Layer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Transport Layer Foreleser: Carsten Griwodz Email: griff@ifi.uio.no 1

  2. TCPReliability and Ordering Duplicates 2

  3. DATA REL CR ACK ACK CC CC 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 Money transfer CR DUP Money transfer is repeated DATA DUP DUP REL time time

  4. 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 ACK CC CR DUP DATA DUP DUP REL Duplicates

  5. 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?

  6. 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“

  7. 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

  8. 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

  9. Example 1 (in principle) MSG(s) t MSG(s) t T=2t+e Example 2: Request/response Taking processing time into account REQ(s) t Emax RES(s) t T=2t+Emax Duplicates: Limiting Packet Lifetime • Enabling the above Method 3Identify 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

  10. 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

  11. 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

  12. TCPReliability and Ordering Initial sequence number allocation 12

  13. 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

  14. 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) T e.g. 232-1 Wraparound ISN ISN SeqNo time ISN Initial Sequence Number “Forbidden Region” Width T (max. theoretic packet lifetime)

  15. T T T SeqNo time 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

  16. Handling of Consecutive Connections T T T Same SeqNo Within T SeqNo 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 • Curve of the consecutively allocated sequence numbers steeper than ISN curve (enters from underneath)

  17. 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

  18. Flow Control 18

  19. 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

  20. 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)

  21. 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

  22. 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

  23. TCP Flow Control Sender Receiver A wants 8 buffers <req 8 buffers> B grants messages 0-3 only A has 3 buffers left <cred=4> Message lost <seq=0, data=m0> A has 2 buffers left <seq=1, data=m1> B acknowledges 0 and 1 permits 2-4 Message lost but A thinks it has 1 left <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 <seq=2, data=m2> B found a new buffer somewhere A times out and retransmits <ack=4, cred=0> <ack=4, cred=1> A still blocked A has 1 buffer left <ack=4, cred=2> A may now send next msg. <seq=5, data=m5> A is now blocked again <seq=6, data=m6> A has 1 buffer left <ack=6, cred=0> <ack=6, cred=4> A is now blocked again time time A still blocked

  24. Credit Mechanism • Dynamic adjustment to • Buffer situation • Number of open connections • Type of connections • high throughput: many buffers • low throughput: few buffers

  25. Data 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 Sequence number and acknowledgements Version IHL Type of service PRE ToS Total length Identification D M Fragment offset Time to live Protocol Header checksum Source address Credit Destination Address Options Source port Destination port Sequence number THL – TCP header length U: URG – urgent A: ACK – acknowledgement P: PSH – push R: RST – reset S: SYN – sync F: FIN – finalize Piggyback acknowledgement THL unused U A P R S F Window Checksum Urgent pointer Options (0 or more 32 bit words)

  26. 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

  27. 2K / SEQ=0 ACK=2048 WIN=2048 2K / SEQ=2048 ACK=4096 WIN=0 ACK=4096 WIN=2048 1K / SEQ=4096 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 time 1K 2K

  28. 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

  29. Sender window size=0 Receive buffer full Application reads one byte Room for one byte Window update segment sent Header Header New byte arrives 1 byte Receive buffer full 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

More Related