1 / 39

CMPT 371

CMPT 371. Data Communications and Networking Principles of reliable data transfer. Transport Layer. Common protocols TCP and UDP UDP is best effort, no reliable delivery TCP insures reliable delivery

josh
Download Presentation

CMPT 371

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. CMPT 371 Data Communications and Networking Principles of reliable data transfer

  2. Transport Layer • Common protocols TCP and UDP • UDP is best effort, no reliable delivery • TCP insures reliable delivery • Remember the Transport layer is above a network layer that does provides an unreliable transmission channel • TCP must compensate for the underlying unreliable channel to provide reliable transmission. This makes TCP much more complicated

  3. Best Effort Delivery (Error free) • Coordinate the amount of data that can be sent • Data must arrive at the receiver no faster than it can be processed • No flow control (UDP, best effort transmission): • Send data and hope receiver can process fast enough or buffer. • Slowing send speed enough to ensure reception will reduce utilization (efficiency) of the link

  4. Design of protocols • Consider what TCP needs to do • Many things, overwhelming to think about how the design was done? • Let’s start simple and work up to see how protocols can be designed • For a first try let’s and make the assumption that the underlying communication channel is reliable • We have a sending host and a receiving hosts, what rules should they follow? How to design a protocol? • We are sending data from source to destination (unidirectional protocol)

  5. Finite State Machine Receiver Source From initial state From initial state IDLE Waiting for data from application IDLE Waiting for data from network layer segment To final state • Build segment • send segment • extract data • deliver to application To final state reliable channel, no flow control

  6. Our first protocol • If correct delivery of segments is guaranteed out protocol will work • What sort of problems might occur • Source host is transmitting too fast for the destination host to receive and process segments • Data segments arrive (that’s guaranteed) they can be corrupted during transmission • Next let us consider how to take care of these possible problems above in our protocol

  7. Want a reliable transmission If we have a completely reliable channel we know all segments arrive, we do not need this confirmed, so our first protocol would work Realistic channels will have bit errors so we will want to know if the segment arrived without being corrupted in any way. First step to being able to verify if the segment arrived without corruption is to verify that the segment arrived

  8. Stop and Wait ARQReliable Delivery ARQ: Automatic Retransmission Request ERROR FREE CASE Source entity (sender), S1, transmits segment Destination entity (receiver), S2, receives segment Destination entity sends acknowledgement Source entity receives acknowledgement Source entity is now ready to start the cycle again

  9. Stop and Wait ARQ: error free Send F Send ACK Send F Send ACK Send F Send ACK Send F Send ACK Send F Send ACK Send F Send ACK Send F Send ACK S1 S2 Error Free Transmission

  10. Finite State Machine: Stop and Wait Source Receiver • extract data • deliver to application • Build ACK • Send ACK From initial state From initial state Made and sent segment IDLE Waiting for data from application WAIT Wait for ACK IDLE Waiting for data from network layer segment Received ACK To final state To final state ARQ reliable channel (no errors or loss, segments acked)

  11. Error Free Stop and Wait: Utilization (1) • S1sends frame F1 which takes time tFRAME to transmit tFRAME = (Length of Frame) / (Data Rate) = L / R • F1 reaches S2 after propagating for timetPROP tPROP = (Propagation Distance) / (Propagation Velocity) = d/V • F1 is queuedand processed by S2 in time tQF+ tPROCF

  12. Error Free Stop and Wait: Utilization (2) S2sends an acknowledgement (ACK) which takes time tACKto transmit The ACK reaches S1 after propagating for time tPROP S1queues and processes the ACK in time tPROCA+tQA The total time to send one frame of data is Tt= tFRAME + tPROP+ tPROCF+ tQF + tACK+ tPROP+ tPROCA+ tQA

  13. Error Free Stop and Wait: Utilization (3) Utilization, U, is the fraction of the total available transmission time, Tt, that is used to transmit data. The total time to send N frames of data is Tt = N × { tFRAME + tACK+ ( 2 ×tPROP)+ tPROCF+ tQF + tPROCA+ tQA} The total time spent transmitting N data frames is Tf= N × tFRAME The link utilization, U, of the channel in the absence of errors and losses is U = Tf / Tt= Tf / (Tf+ RTT)

  14. Want a reliable transmission • Realistic channels will have bit errors so we will want to know if the segment arrived without being corrupted in any way. • Now we can acknowledge a correct segment • Next let’s add a negative acknowledgement for a segment that arrives with bit errors • We are still assuming that there are few errors so we can still recognize that the corrupted segment is a segment • We are still assuming no segments are lost

  15. Stop and Wait ARQ: bit errors Source entity (sender), S1, transmits a frame Destination entity (receiver), S2, receives a frame Destination entity processes the frame and finds that there are bit errors in the frame Destination entity sends an NACK to indicate the contents of the segment have not arrived intact, and drops the segment Source entity receives the NACK The source entity resends the same segment

  16. Stop and Wait ARQ: bit errors Stop and wait with NACK F ACK F X Frame with bit errors arrives NACK F ACK F ACK F ACK • Damaged frame (incorrect data): problems with NACK • Must know address is correct to use NACK mechanism • If there are bit errors this may not be a good idea, the bit errors may be in the address field we do not know • For now assume this is not a problem

  17. FSM: Stop and Wait No segment loss, no corrupted ACKs /NAKs Source Receiver • Segment corrupted • Build NACK • Send NACK From initial state From initial state segment Made and Transmitted: IDLE Waiting for data from network Layer IDLE Waiting for data from application WAIT Waiting for ACK or NACK To final state Received ACK: • Segment not corrupted • extract data • deliver to application • Build ACK, Send ACK Received NACK: Retransmit the same segment To final state For transmission in a channel in which bit errors may occur in segments

  18. Want a reliable transmission Realistic channels will have bit errors so we will want to know if the segment arrived without being corrupted in any way. Now we can acknowledge a correct segment, or send a NACK to acknowledge a corrupted segment and cause it to be resent But what happens if an ACK or a NACK is corrupted?

  19. Possible solutions • Use checksum and error correction with enough bits to correct a reasonable number of errors • Would work if no segment ever had more that the specified number of bit errors (dangerous assumption) • Would work if no segments were ever lost. • We know with best effort delivery segments can be dropped by intermediate routers and not get to the destination at all • Request resending of ACK ? This is an infinite progression, each resent ACK can be corrupted and in turn need to request retransmission

  20. Better Solution • Retransmit the last segment sent when a corrupted ACK or NACKsegment is received. • Sending host knows which segment was sent last so it can resend the correct segment • PROBLEMS • When the resent segment arrives at the destination, the destination assumes it is the next segment, not a copy of the previous segment • We need to use sequence to fix this problem. For now two numbers 1 and 0 will do

  21. Stop and Wait ARQ: bit errors Stop and wait with NACK F0 ACK F1 ACK X ACK with bit errors arrives F1 ACK F0 ACK F1 ACK • Damaged ACK or NACK (incorrect data): possible solution 1 • When the receiver receives a corrupt segment it sends a NACK • When the sender receives a corrupted segment it resends the last segment sent • When the resent segment reaches the destination it is the second copy of that segment received • Use sequence number to tell if it is the same segment as the last one received (new segment or retransmission)

  22. FSM: Source (no segment loss) From initial state IDLE 0 Waiting for data from application Received NACK or Corrupted ACK/NACK Retransmit segment WAIT Waiting for ACK or NACK Make and Transmit segment: F0 Received NACK or Corrupted ACK/NACK Retransmit segment Received ACK: Received ACK: WAIT Waiting for ACK or NACK IDLE 1 Waiting for data from application Make and Transmit segment: F1 in a channel in which bit errors may occur in ACKs, segments

  23. Finite State Machine: Receiver Received F1 Make and Send ACK From initial state Received F0 Make and Send ACK IDLE 0 Waiting for data from network Layer Receive segment: F0 Deliver Data Make and send ACK IDLE 1 Waiting for data from network Layer Receivesegment: F1 Deliver data Make and send ACK Received corrupted segment Send NACK Received corrupted segment Send NACK in a channel in which bit errors may occur in ACKs, segments

  24. Stop and Wait ARQ: bit errors Stop and wait with NACK F0 ACK0 F1 ACK 1 X ACK with bit errors arrives F1 ACK 1 F0 ACK 0 F1 ACK 1 • Damaged ACK or NACK (incorrect data): possible solution 2 • When the receiver receives a corrupt segment it sends an ACK for the last segment received without error • When the sender receives duplicate ACK it knows the previous segment did not arrive at the destination and can resend the lost segment • Need to use sequence numbers for ACKs as well as for data segments • No problem if error is in address

  25. FSM: Source (no segment loss) From initial state IDLE 0 Waiting for data from application Received ACK1 or Corrupted ACK Retransmit segment WAIT Waiting for ACK 0 Make and Transmit segment: F0 Received ACK 0 or Corrupted ACK Retransmit segment Received ACK 1: Received ACK 0: WAIT Waiting for ACK 1 IDLE 1 Waiting for data from application Make and Transmit segment: F1 in a channel in which bit errors may occur in ACKs, segments

  26. Finite State Machine: Receiver From initial state IDLE 0 Waiting for data from network Layer Receive segment: F0 Deliver Data Make and send ACK 0 IDLE 1 Waiting for data from network Layer Receivesegment: F1 Deliver data Make and send ACK 1 Received corrupted segment Or receive F1 Send ACK 1 Received corrupted segment or receive F0 Send ACK 0 in a channel in which bit errors may occur in ACKs, segments

  27. Stop and Wait ARQ Utilization: (1) • If errors and losses make retransmissions necessary then U = Tf / ( Nr× Tt) If no timers expire, Nr,,is the average number of transmissions per frame, Na. Otherwise Nr is a function f(Na) • Let Pf be the probability that a given frame contains errors. • The probability that it will take i attempts to transmit the frame is • The average number of retransmissions, Na, is the sum for all possible values of the number of transmissions needed multiplied by the probability that that number of transmissions will be needed

  28. Stop and Wait ARQ Utilization: (2) • Assume that no ACKs or NACKs are lost or damaged, and that the timeout timer never expires • Then Nr is the average number of transmissions per frame and the channel utilization is • Also assuming that • Processing time is negligible • The acknowledgment frame is small compared to the data frame . U = (1-Pf )Tf / Tt U = (1-Pf ) / (1+2a)

  29. Want a reliable transmission We have accounted for a channel with minimal bit loss (even with incorrect bits in address) Now consider what happens if the segment is so corrupted we can not identify it as a segment, or if the segment does not reach the destination. We know that an acknowledgement should arrive about 1 RTT after sending a segment. If it does not arrive we will assume the segment did not arrive or the acknowledgement was lost

  30. Timeout (lost segments or ACKs) Source entity (sender), S1, transmits a frame and starts a timer Destination entity (receiver), S2, receives a frame Destination entity sends an ACK Source entity receives ACK and stops timer Source entity is now ready to start the cycle again for a new frame If timer expires before the source entity receives the ACK from the destination entity repeat the steps above for the same frame

  31. Stop and Wait : problems Send F0 Send ACK0 * Send F1 Send F1 Send ACK1 Send F0 * Send ACK0 Send F0 Send ACK0 Send F1 Send ACK1 delayed Send F1 Send ACK1 Transmission with losses and errors • Possible problems caused by errors • Damaged frame (corrupted data) • Lost frame (not received) • Damaged / Lost ACK • Delayed ACK

  32. Stop and Wait ARQ: lost segment F0 ACK0 F1 * Timeout expired F1 ACK1 F0 ACK0 Stop and wait: lost frame • Lost Frame • Must wait for timeout • No NACK would be sent, segment did not arrive

  33. Stop and Wait ARQ: lost ACK F0 ACK0 F1 Timeout expired * ACK1 F1 ACK1 F0 ACK0 Stop and wait: lost ACK and duplicate frame • Lost Frame or ACK • Must wait for timeout • Damaged / Lost ACK causes duplicate reception of frame. • Alternate labeling of frames F1 and F0 allows for identification of duplicates

  34. Stop and Wait ARQ delayed ACK F0 ACK0 F1 Delay sending ACK Timeout expired delay F1 ACK1 F0 ACK1 ACK0 Stop and wait: duplicate ACK • Delayed ACK • Must wait for timeout • Delay in sending ACK causes duplicate reception of ACK by Sender. • Alternate labeling of frames F1 and F0, and ACKS, ACK0 and ACK1 allows for identification and elimination of duplicates. Without it ACKs may be mismatched with frames, and a later lost frame may go undetected.

  35. Finite State Machine: Source From initial state Received ACK1 or Corrupted ACK/NACK Received segment IDLE 0 Waiting for data from application WAIT Waiting for ACK 0 Timeout expired Retransmit segment Reset timer Make and Transmit segment: F0 Received ACK 0 Stop timer: Received ACK 1 Stop Timer: IDLE 1 Waiting for data from application Timeout Expired Retransmit segment Reset Timer Received segment WAIT Waiting for ACK 1 Make and Transmit segment: F1 Received ACK 0 or Corrupted ACK/NACK in a channel in which bit errors and segment loss may occur

  36. Stop and Wait Utilization: examples (1) • Assume protocol has the following properties • Processing and queuing time are negligible (tQF≈ 0, tQA≈ 0, tPROCF≈ 0, tPROCA≈ 0) • The ACK frame is small compared to the data frame (tFRAME>> tACKor tFRAME+ tACK≈tFRAME) • No errors or losses

  37. Stop and Wait Utilization: examples (2) • The maximum link utilization, U, is U = Tf / Tt = tFRAME/{ tFRAME + tACK+ ( 2 ×tPROP) + tPROCF+ tPROCA} = tFRAME/ { tFRAME + 2 × tPROP} = 1 / (1+2a) • Where a = tPROP/ tFRAME = ( R × d ) / ( V × L )

  38. Preview of TCP TCP uses cumulative ACKS similar to those in this protocol TCP’s uses ACK numbers that indicate the next segment (octet) it expects to receive, not the last segment (octet) it has already received

  39. Stop and Wait : problems TCP Send F0 Send ACK1 * Send F1 Send F1 Send ACK0 Send F0 * Send ACK1 Send F0 Send ACK1 Send F1 Send ACK0 delayed Send F1 Send ACK0 Transmission with losses and errors • Possible problems caused by errors • Damaged frame (corrupted data) • Lost frame (not received) • Damaged / Lost ACK • Delayed ACK

More Related