Ece 4450 427 527 computer networks spring 2014
This presentation is the property of its rightful owner.
Sponsored Links
1 / 38

ECE 4450:427/527 - Computer Networks Spring 2014 PowerPoint PPT Presentation


  • 106 Views
  • Uploaded on
  • Presentation posted in: General

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!

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ece 4450 427 527 computer networks spring 2014

ECE 4450:427/527 - Computer NetworksSpring 2014

Dr. Nghi Tran

Department of Electrical & Computer Engineering

Lecture 5.3: Reliable Transmission

ECE 4450:427/527


Link layer five common problems

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


Discussions

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


Acknowledgement

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


Timeout

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


Stop and wait

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


Stop and wait protocol

Stop-and-Wait Protocol

  • Let assume we transmit a frame. How many scenarios we can have with Stop-and-Wait?

ECE 4450:427/527


Stop and wait protocol issue

Stop-and-Wait Protocol: Issue

  • ACK is lost or arrives after timeout: what happen?

ECE 4450:427/527


Stop and wait protocol issue1

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


Stop and wait protocol inefficiency

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


Sliding window protocol

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


Sliding window protocol1

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


Sliding window protocol2

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


Sliding window protocol algorithm

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


Sliding window protocol3

Sliding-Window Protocol

Sliding Window on Sender

ECE 4450:427/527


Sliding window protocol4

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


Sliding window protocol example

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


Sliding window protocol5

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


Sliding window protocol6

Sliding-Window Protocol

  • Receiver also maintains the following invariant

    LAF – LFR ≤ RWS

Sliding Window on Receiver

ECE 4450:427/527


Sliding window protocol7

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


Sliding window protocol8

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


Sliding window protocol9

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


Sliding window protocol issues

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


Sliding window protocol issues1

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


Sliding window comment settings

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


Maximum sequence number maxseqnum

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


Maximum sequence number maxseqnum1

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


    Maximum sequence number maxseqnum2

    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


    Sliding window protocol summary

    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


    Sliding window protocol summary1

    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


    Sliding window protocol example 1

    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


    Sliding window protocol example 2

    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


    Sliding window comment settings1

    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


    Go back n protocol

    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


    Selective repeat

    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


    Example with selective repeat

    Example with Selective Repeat

    Demo: http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/SR/index.html

    ECE 4450:427/527


    Sliding window protocol10

    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


    Sliding window protocol11

    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


  • Login