© Janice Regan, CMPT 128, CMPT 371 Data Communications and Networking Principles of reliable data transfer 0

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 Janice Regan © Sept

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 Janice Regan © Sept

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) Janice Regan © Sept

Finite State Machine  reliable channel, no flow control Janice Regan © Sept Source Receiver Build segment send segment From initial state extract data deliver to application To final state From initial state IDLE Waiting for data from network layer segment IDLE Waiting for data from application

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 Janice Regan © Sept

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 Janice Regan © Sept

Stop and Wait ARQ Reliable Delivery ARQ: Automatic Retransmission Request ERROR FREE CASE  Source entity (sender), S 1, transmits segment  Destination entity (receiver), S 2, receives segment  Destination entity sends acknowledgement  Source entity receives acknowledgement  Source entity is now ready to start the cycle again Janice Regan © Sept

Stop and Wait ARQ: error free Janice Regan © Sept Error Free Transmission Send F Send ACK S1S1 S2S2

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

Error Free Stop and Wait: Utilization (1)  S 1 sends frame F 1 which takes time t FRAME to transmit t FRAME = (Length of Frame) / (Data Rate) = L / R  F 1 reaches S 2 after propagating for time t PROP t PROP = (Propagation Distance) / (Propagation Velocity) = d/V  F 1 is queued and processed by S 2 in time t QF + t PROCF Janice Regan © Sept

Error Free Stop and Wait: Utilization (2)  S 2 sends an acknowledgement (ACK) which takes time t ACK to transmit  The ACK reaches S 1 after propagating for time t PROP  S 1 queues and processes the ACK in time t PROCA +t QA  The total time to send one frame of data is T t = t FRAME + t PROP + t PROCF + t QF + t ACK + t PROP + t PROCA + t QA Janice Regan © Sept

Error Free Stop and Wait: Utilization (3)  Utilization, U, is the fraction of the total available transmission time, T t, that is used to transmit data.  The total time to send N frames of data is T t = N × { t FRAME + t ACK + ( 2 × t PROP ) + t PROCF + t QF + t PROCA + t QA }  The total time spent transmitting N data frames is T f = N × t FRAME  The link utilization, U, of the channel in the absence of errors and losses is U = T f / T t = T f / (T f + RTT) Janice Regan © Sept

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 Janice Regan © Sept

Stop and Wait ARQ: bit errors  Source entity (sender), S 1, transmits a frame  Destination entity (receiver), S 2, 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 Janice Regan © Sept

Stop and Wait ARQ: bit errors  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 Janice Regan © Sept Stop and wait with NACK F F X ACK NACK F ACK F ACK F ACK Frame with bit errors arrives

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

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? Janice Regan © Sept

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 Janice Regan © Sept

Better Solution  Retransmit the last segment sent when a corrupted ACK or NACK segment 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 Janice Regan © Sept

Stop and Wait ARQ: bit errors  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) Janice Regan © Sept ACK Stop and wait with NACK F1 F0 X ACK F1 ACK F0 ACK F1 ACK ACK with bit errors arrives

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

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

Stop and Wait ARQ: bit errors  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 Janice Regan © Sept ACK 1 Stop and wait with NACK F1 F0 X ACK0 F1 ACK 1 F0 ACK 0 F1 ACK 1 ACK with bit errors arrives

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

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

Stop and Wait ARQ Utilization: (1)  If errors and losses make retransmissions necessary then U = T f / ( N r × T t ) If no timers expire, N r,, is the average number of transmissions per frame, N a. Otherwise N r is a function f(N a )  Let P f 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, N a, 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 Janice Regan © Sept

Stop and Wait ARQ Utilization: (2)  Assume that no ACKs or NACKs are lost or damaged, and that the timeout timer never expires  Then N r 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. Janice Regan © Sept U = (1-P f )T f / T t U = (1-P f ) / (1+2a)

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 Janice Regan © Sept

Timeout (lost segments or ACK s)  Source entity (sender), S 1, transmits a frame and starts a timer  Destination entity (receiver), S 2, 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 Janice Regan © Sept

Stop and Wait : problems  Possible problems caused by errors  Damaged frame (corrupted data)  Lost frame (not received)  Damaged / Lost ACK  Delayed ACK Janice Regan © Sept Transmission with losses and errors Send F1 Send F0 Send F1 Send F0 Send ACK1 delayed Send ACK0 * Send ACK1 Send F1 * Send ACK0

Stop and Wait ARQ: lost segment  Lost Frame  Must wait for timeout  No NACK would be sent, segment did not arrive Janice Regan © Sept Stop and wait: lost frame F1F0* ACK0 Timeout expired F1 ACK1 F0 ACK0

Stop and Wait ARQ: lost ACK  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 Janice Regan © Sept Stop and wait: lost ACK and duplicate frame F1F0ACK0 ACK1 F1 ACK1 F0 ACK0 * Timeout expired

Stop and Wait ARQ delayed 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. Janice Regan © Sept Stop and wait: duplicate ACK F0 ACK0 Timeout expired F1 ACK1 ACK0 F1 ACK1 Delay sending ACK F0 delay

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

Stop and Wait Utilization: examples (1)  Assume protocol has the following properties  Processing and queuing time are negligible (t QF ≈ 0, t QA ≈ 0, t PROCF ≈ 0, t PROCA ≈ 0)  The ACK frame is small compared to the data frame (t FRAME >> t ACK or t FRAME + t ACK ≈ t FRAME )  No errors or losses Janice Regan © Sept

Stop and Wait Utilization: examples (2)  The maximum link utilization, U, is U = T f / T t = t FRAME /{ t FRAME + t ACK + ( 2 × t PROP ) + t PROCF + t PROCA } = t FRAME / { t FRAME + 2 × t PROP } = 1 / (1+2a)  Where a = t PROP / t FRAME = ( R × d ) / ( V × L ) Janice Regan © Sept

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 Janice Regan © Sept

Stop and Wait : problems TCP  Possible problems caused by errors  Damaged frame (corrupted data)  Lost frame (not received)  Damaged / Lost ACK  Delayed ACK Janice Regan © Sept Transmission with losses and errors Send F1 Send F0 Send F1 Send F0 Send ACK0 delayed Send ACK1 * Send ACK0 Send F1 * Send ACK1