1 / 38

ECE 4450:427/527 - Computer Networks Spring 2014

ECE 4450:427/527 - Computer Networks Spring 2014. Dr. Nghi Tran Department of Electrical & Computer Engineering. Lecture 5.3: Reliable Transmission. Link Layer: Five Common Problems. Basic problem: you can’t just send IP datagrams over the link!

iain
Télécharger la présentation

ECE 4450:427/527 - Computer Networks Spring 2014

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. ECE 4450:427/527 - Computer NetworksSpring 2014 Dr. Nghi Tran Department of Electrical & Computer Engineering Lecture 5.3: Reliable Transmission ECE 4450:427/527

  2. Link Layer: Five Common Problems • Basic problem: you can’t just send IP datagrams over the link! • We first consider how to encode bits into the signal at the source and recover bits at the receiving node • Once it is possible to transmit bits, we need to figure out how to package these bits into FRAME • Assume each node is able to recognize the collections of bits making up a frame, the third problem is to determine if those bits are in error: Error Detection and Correction • If frames arriving at destination contain errors, how to recover from such losses: ARQ • Final problem related to multiple-access link: how mediate access to a shared link so that all nodes have a chance to transmit: We focus on Ethernet ECE 4450:427/527

  3. Discussions • We have learned so far: • Error Detection to detect errors in Frames • Error Correction to correct errors in Frames • But sometimes, errors are too severe to be corrected and corrupted frames must be discarded. • Now we consider a link-level protocol to deal with this issue so that frames can be delivered reliably: • A combination of two fundamental mechanisms: Acknowledgement (ACK) and Timeout – AutomaticRepeatreQuest (ARQ). • Error detection? ECE 4450:427/527

  4. Acknowledgement • An acknowledgement (ACK for short) is a small control frame that a protocol sends back to its peer saying that it has received the earlier frame. • A control frame is a frame with header only (no data). • The receipt of an acknowledgement indicates to the sender of the original frame that its frame was successfully delivered. ECE 4450:427/527

  5. Timeout • If the sender does not receive an acknowledgment after a reasonable amount of time, then it retransmits the original frame. • The action of waiting a reasonable amount of time is called a timeout. • The general strategy of using acknowledgements and timeouts to implement reliable delivery is sometimes called AutomaticRepeatreQuest (ARQ). • We now study different ARQ algorithms. We shall use generic language, i.e., do not give detail about header fields. ECE 4450:427/527

  6. Stop-and-Wait • Idea of stop-and-wait protocol is straightforward • After transmitting one frame, the sender waits for an acknowledgement before transmitting the next frame. • If the acknowledgement does not arrive after a certain period of time, the sender times out and retransmits the original frame ECE 4450:427/527

  7. Stop-and-Wait Protocol • Let assume we transmit a frame. How many scenarios we can have with Stop-and-Wait? ECE 4450:427/527

  8. Stop-and-Wait Protocol: Issue • ACK is lost or arrives after timeout: what happen? ECE 4450:427/527

  9. Stop-and-Wait Protocol: Issue • How to deal with this issue: duplicate copies of frames will be delivered • Use 1 bit sequence number (0 or 1) in the header • When the sender retransmits frame 0, the receiver can determine that it is seeing a second copy of frame 0 rather than the first copy of frame 1 and therefore can ignore it (the receiver still acknowledges it, in case the first acknowledgement was lost) ECE 4450:427/527

  10. Stop-and-Wait Protocol: Inefficiency • How many outstanding frames on the link at a time? • This may be far below the link’s capacity • Consider a 1.5 Mbps link with a 45 ms RTT • The link has a delay  bandwidth product of 67.5 Kb or approximately 8 KB • Since the sender can send only one frame per RTT and assuming a frame size of 1 KB • Maximum Sending rate • Bits per frame  Time per frame = 1024  8  0.045 = 182 Kbps Or about one-eighth of the link’s capacity • How can we use the link fully? ECE 4450:427/527

  11. Sliding-Window Protocol Main idea: Leave up to N frames unacknowledged at any given time: Sender ready to send (N+1)th frame at the same moment ACK for the first frame arrives sender receiver first packet bit transmitted last packet bit transmitted first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next Packet ECE 4450:427/527

  12. Sliding-Window Protocol Main idea: Leave up to N frames/packets unacknowledged at any given time: Sender ready to send (N+1)th frame at the same moment ACK for the first frame arrives sender receiver first packet bit transmitted last bit transmitted first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R ECE 4450:427/527

  13. Sliding-Window Protocol • Perhaps the best known algorithm in computer networking: Need to understanding it thoroughly!!! • It can be used to serve different roles in different layers: • Reliable delivery at Link Layer • Flow control: managing the rate of data transmission between two nodes to prevent a fast sender from outrunning a slow receiver • TCP: Also reliable deliver • We shall consider those later on ECE 4450:427/527

  14. Sliding-Window Protocol: Algorithm • Sender assigns a sequence number denoted as SeqNum to each frame • Sender maintains three variables • Sending Window Size (SWS) • Upper bound on the number of outstanding (unacknowledged) frames that the sender can transmit • Last Acknowledgement Received (LAR) • Sequence number of the last acknowledgement received • Last Frame Sent (LFS) • Sequence number of the last frame sent • Sender also maintains the following invariant • LFS – LAR ≤ SWS ECE 4450:427/527

  15. Sliding-Window Protocol Sliding Window on Sender ECE 4450:427/527

  16. Sliding-Window Protocol • When an acknowledgement arrives • the sender moves LAR to right, thereby allowing the sender to transmit another frame • Also the sender associates a timer with each frame it transmits • It retransmits the frame if the timer expires before the ACK is received • Note that the sender has to be willing to buffer up to SWS frames • WHY? ECE 4450:427/527

  17. Sliding-Window Protocol: Example sender receiver first packet bit transmitted last bit transmitted first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK ACK arrives, send next packet ECE 4450:427/527

  18. Sliding-Window Protocol • Receiver maintains three variables • Receiving Window Size (RWS) • Upper bound on the number of out-of-order frames that the receiver is willing to accept • Largest Acceptable Frame (LAF) • Sequence number of the largest acceptable frame • Last Frame Received (LFR) • Sequence number of the last frame received (and ACK to the sender) ECE 4450:427/527

  19. Sliding-Window Protocol • Receiver also maintains the following invariant LAF – LFR ≤ RWS Sliding Window on Receiver ECE 4450:427/527

  20. Sliding-Window Protocol • When a frame with sequence number SeqNum arrives, what does the receiver do? • If SeqNum ≤ LFR or SeqNum > LAF • Discard it (the frame is outside the receiver window) • If LFR < SeqNum ≤ LAF • Accept it • Now the receiver needs to decide whether or not to send an ACK ECE 4450:427/527

  21. Sliding-Window Protocol • Let SeqNumToAck • Denote the largest sequence number not yet acknowledged, such that all frames with sequence number less than or equal to SeqNumToAck have been received • The receiver acknowledges the receipt of SeqNumToAck . This acknowledgement is said to be cumulative. • The receiver then sets • LFR = SeqNumToAck and adjusts • LAF = LFR + RWS ECE 4450:427/527

  22. Sliding-Window Protocol • For example, suppose LFR = 5 and RWS = 4 ->LAF = 9 (i.e. the last ACK that the receiver sent was for seq. no. 5) If frames 7 and 8 arrive, they will be buffered because they are within the receiver window But no ACK will be sent since frame 6 is yet to arrive Frames 7 and 8 are out of order Frame 6 arrives (it is late for some reason) Now Receiver Acknowledges Frame 8 and bumps LFR to 8 and LAF to 12 ECE 4450:427/527

  23. Sliding-Window Protocol: Issues • When timeout occurs, the amount of data in transit decreases • Since the sender is unable to advance its window • When the packet loss occurs, this scheme is no longer keeping the pipe full • The longer it takes to notice that a packet loss has occurred, the more severe the problem becomes • How to improve this • Negative Acknowledgement (NAK) • Additional Acknowledgement • Selective Acknowledgement ECE 4450:427/527

  24. Sliding-Window Protocol: Issues • Negative Acknowledgement (NAK) • Receiver sends NAK for frame 6 as soon as frame 7 arrive (in the previous example) • Additional Acknowledgement • Receiver sends additional ACK for frame 5 when frame 7 arrives • Sender uses duplicate ACK as a clue for frame loss • Selective Acknowledgement • Receiver will acknowledge exactly those frames it has received, rather than the highest number frames • Receiver will acknowledge frames 7 and 8 • Sender knows frame 6 is lost • Sender can keep the pipe full, but…..?? ECE 4450:427/527

  25. Sliding-Window: Comment Settings • In practice, how to select SWS? • Depending on a quite number of factors (which?) • Now for RWS: • RWS=1: Go-back-N protocol. But what does this mean if RWS=1? • Should we set RWS>SWS? • RWS=SWS with Selective ACK: Selective Repeat ECE 4450:427/527

  26. Maximum Sequence Number MaxSeqNum • We already discussed Stop-and-Wait: We need only 1 bit-header: Two sequence numbers 0 and 1, and reuse them - MaxSeqNum=2; • Now, for Sliding-Window Protocol: Should sequence numbers go to infinity? • We have a finite sequence number: • Example, 3-bit header: 8 sequences • Need to reuse or wrap around • So how we select MaxSeqNum? ECE 4450:427/527

  27. Maximum Sequence Number MaxSeqNum SWS + 1 ≤ MaxSeqNum • Is this sufficient? • Depends on RWS • If RWS = 1, then sufficient • If RWS = SWS, then not good enough • For example, we have eight sequence numbers 0, 1, 2, 3, 4, 5, 6, 7 RWS = SWS = 7 Sender sends 0, 1, …, 6 Receiver receives 0, 1, … ,6 Receiver acknowledges 0, 1, …, 6 ACK (0, 1, …, 6) are lost Sender retransmits 0, 1, …, 6 Receiver is expecting 7, 0, …., 5 ECE 4450:427/527

  28. Maximum Sequence Number MaxSeqNum • To avoid this, If RWS = SWS SWS < (MaxSeqNum + 1)/2 • Note that this rule is specific to the situation where RWS=SWS. We might see a more general rule for arbitrary values of RWS and SWS in assignment • Also, at this moment, we assume frames are not re-ordered in transit, which is ony correct for direct point to point. For different environment, we need another rule (e.g., in TCP). ECE 4450:427/527

  29. Sliding Window Protocol: Summary • Sender maintains three variables • Sending Window Size (SWS) • Last Acknowledgement Received (LAR) • Last Frame Sent (LFS) • Sender also maintains the following invariant • LFS – LAR ≤ SWS • When ACK arrives • Move LAR to right, transmit another frame • Retransmit frame if time expires (time out) ECE 4450:427/527

  30. Sliding-Window Protocol: Summary • Receiver maintains three variables • Receiving Window Size (RWS) • Largest Acceptable Frame (LAF) • Last Frame Received (LFR) • Receiver also maintains the following invariant • LAF – LFR ≤ RWS • When a frame with sequence number SeqNum arrives, only accept it if • If LFR < SeqNum ≤ LAF • ACK? • SeqNumToAck : The largest sequence number not yet acknowledged, such that all frames with sequence number less than or equal to SeqNumToAck have been received • The receiver then sets • LFR = SeqNumToAck and adjusts LAF = LFR + RWS ECE 4450:427/527

  31. Sliding-Window Protocol: Example 1 • Considering the case that SWS=RWS=3. Timeout interval is about 2RTT. Draw a timeline diagram of the following • Frame 4 is lost • Frames 4-6 are lost ECE 4450:427/527

  32. Sliding-Window Protocol: Example 2 • In the following example, we will see the efficiency of using NAK or additional ACK • Considering the case that SWS=RWS=4 and frame 2 is lost. Timeout interval is about 2RTT. • First, draw a timeline diagram with re-tranmission taking place upon time out as usual • Now, assume NAK[2]/DUPACK[2] is sent after frame 3 is received. Re-transmission now take paces either upon time out or upon receipt of NAK[2]/DUPACK[2] ECE 4450:427/527

  33. Sliding-Window: Comment Settings • In practice, how to select SWS? • Depending on a quite number of factors!! • Now for RWS: • RWS=1: Go-back-N protocol • Should we set RWS>SWS? • RWS=SWS with Selective ACK: Selective Repeat ECE 4450:427/527

  34. Go-Back-N Protocol • It is Sliding Window Protocol with RWS=1: Receiver will not buffer any frames that arrive out of order Demo: http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/go-back-n/index.html ECE 4450:427/527

  35. Selective Repeat • Window size can be very large for nets with large delay x bandwidth • Inefficient to retransmit all N frames if one is lost • Selective repeat allows the re-transmission of only the lost packets • Accepts out-of-order packets • Simply increase the RWS up to SWS (does not make sense to allow for RWS > SWS) ECE 4450:427/527

  36. Example with Selective Repeat Demo: http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/SR/index.html ECE 4450:427/527

  37. Sliding-Window Protocol • Perhaps the best known algorithm in computer networking • Serves three different roles • Reliable • Preserve the order: The receiver makes sure that it does not pass a frame up to the next higher-level protocol until it has already passed up all frames with a smaller sequence number • Frame control: Receiver is able to throttle sender- Keeps sender from overrunning receiver from transmitting more data than the receiver is able to process ECE 4450:427/527

  38. Sliding-Window Protocol • Perhaps the best known algorithm in computer networking • It can be used to serve different roles in different layers: • Reliable delivery at Link Layer • TCP: Also reliable deliver • Up to now, we already learned quite a few techniques/protocols considered in Transport Layer ECE 4450:427/527

More Related