Download presentation
Presentation is loading. Please wait.
Published byOscar Lester Houston Modified over 9 years ago
1
CS 453 Computer Networks Lecture 11 Layer 2 – Data Link Layer Protocols
2
Data Link Protocols Previously, we talked about Data Link Layer (DLL) protocols and the software to implement them We looked at a Simplex protocol,… … A Simplex protocol with flow control… … and a Simplex protocol with flow control and error control (at least to a limited degree)
3
Data Link Protocols Recall that in the previously presented protocols we had a number of requirements and assumptions that we had to deal with… Data flowed in one direction (sort of) Data flowed in one direction (sort of) Is this realistic? At DLL a communications channel is “wire- like” At DLL a communications channel is “wire- like” What does this mean?
4
Data Link Protocols As we have already seen – we can implement a level of error control by sending return acknowledgement (ack) frames When we send acks back to the sender we are transmitting bidirectionally or… Full Duplex
5
Data Link Protocols An interlude- As network designers, engineers, or developers… As network designers, engineers, or developers… It’s OK to use expensive communications channels… It’s OK to use expensive communications channels… …and use them very inefficiently… …and use them very inefficiently… Right? Right? Wrong! Wrong! What do we mean by inefficiently? What do we mean by inefficiently?
6
Data Link Protocols So how we send acks back… We can build and send ack frames… or… We can build and send ack frames… or… We can attach ack to data frames that are going back anyway We can attach ack to data frames that are going back anyway This is called Piggybacking One issue with piggybacking is that we must be able to deal with situations when there are no returning frames on which to piggyback What do you suppose we do about this?
7
Data Link Protocols So far, we have implicitly assumed that frame delivery time and acknowledgement delivery time is instantaneous or at least, inconsequential Is that realistic? Try Ping sometime
8
Data Link Protocols Stop-and-wait protocol Sender send a frame… Sender send a frame… …and blocks until it receives an acknowledgement (ack) from receiver that it was received ok …and blocks until it receives an acknowledgement (ack) from receiver that it was received ok When receiver receives the frame and it is ok, it transmits an acknowledgment to sender When receiver receives the frame and it is ok, it transmits an acknowledgment to sender When sender receives the ack from the receiver it unblocks and send next frame When sender receives the ack from the receiver it unblocks and send next frame
9
Data Link Protocols Stop-and-wait protocol From: Peterson & Davie, Computer Networks (2003) Morgan Kaufman, pg. 100
10
Data Link Protocols Consider this… 50kbs communications link 50kbs communications link 500 msec roundtrip (r) propagation time 500 msec roundtrip (r) propagation time Frame launch to ack receipt 1000 bit frames 1000 bit frames t=0 msec sender initiatives transmission of data frame t=0 msec sender initiatives transmission of data frame t=20 msec full data frame is on it way t=20 msec full data frame is on it way t= 270 frame fully arrives at receiver (r/2) t= 270 frame fully arrives at receiver (r/2) Ack sent from receiver to sender Ack sent from receiver to sender Ack arrives at sender at t=? Ack arrives at sender at t=?
11
Data Link Protocols Consider this… So, the ack is received by the sender at t=520 So, the ack is received by the sender at t=520 recall that (in the protocols discussed so far) the sender can’t send the next frame until the last frame has been acknowledged recall that (in the protocols discussed so far) the sender can’t send the next frame until the last frame has been acknowledged The next frame can start at t=520 frame the start of the last frame The next frame can start at t=520 frame the start of the last frame So, the sender used the channel for 20 msec… So, the sender used the channel for 20 msec… then had to wait 500 msecs to start another tranmission… then had to wait 500 msecs to start another tranmission… So, … So, …
12
Data Link Protocols Consider this… what was the channel utilization? what was the channel utilization? about 4% Then, what was the effective bandwidth Then, what was the effective bandwidth 4% of 50kbs = 2000 bps not too good, right not too good, right What can we do about this? What can we do about this?
13
Data Link Protocols Pipelining Lets eliminate the requirement that the sender has to wait for an acknowledgement from the receiver before sending the next frame? Lets eliminate the requirement that the sender has to wait for an acknowledgement from the receiver before sending the next frame? This is called Pipelining This is called Pipelining Establish a window of n frames Sender can send up to frames before requiring an acknowledge Frames are still acknowledged on per frame basis but the sender can send n of them before halting (blocking) transmission for lack of an acknowledgement Look at the last example again
14
Data Link Protocols Pipelining At 50kbs it takes how long to launch a 1000 bit frame? At 50kbs it takes how long to launch a 1000 bit frame? 20 msec The ack for the first frame will arrive at sender when? The ack for the first frame will arrive at sender when?t=520 So, at 20 msec/frame how many frames can the sender put “in the pipe” by the time the first ack returns? So, at 20 msec/frame how many frames can the sender put “in the pipe” by the time the first ack returns?26 So we make the window size 26 frames So we make the window size 26 frames
15
Data Link Protocols Pipelining Where – Where – l = frames size in bits b = data rate in bits/sec R = roundtrip transit time l/b = time to transmit one frame R/2 – data transit time from sender to receiver R/2 – ack transit time from receiver to sender In stop and wait mode (previous protocols) channel utilization = l /(l+bR) with pipelining channel utilization (effective bandwidth) can approach 100%
16
Data Link Protocols Pipelining From: Peterson & Davie, Computer Networks (2003) Morgan Kaufman, pg. 100
17
Data Link Protocols But if we use a pipeline protocol what do we do if we have a frame error?
18
Data Link Protocols Sliding Window Protocols A class of protocols where more than one frame is transmitted before an ack is received A class of protocols where more than one frame is transmitted before an ack is received Generally it works like this- Generally it works like this- Sender assigns a sequence number to each frame Receiver acks frames by sequence number Sender and receiver maintain a window For sender window is range of unacknowledged transmitted frames For sender window is range of unacknowledged transmitted frames For receiver window is range of frames/sequence numbers it can accept For receiver window is range of frames/sequence numbers it can accept
19
Data Link Protocols Sliding Window Protocols When sender transmits a frame it increments the upper end of the window (last frame sent) When sender transmits a frame it increments the upper end of the window (last frame sent) When sender receives an ack it increments the lower end of the window (last frame acknowledged) When sender receives an ack it increments the lower end of the window (last frame acknowledged) When receiver receives a frame (correct) it returns an ack and increment the lower end of its receive window (last frame received),… When receiver receives a frame (correct) it returns an ack and increment the lower end of its receive window (last frame received),… … and increments the upper end of it receive window (last acceptable frame) - because the window is a certain size – no necessarily fixed … and increments the upper end of it receive window (last acceptable frame) - because the window is a certain size – no necessarily fixed
20
Data Link Protocols Sliding Window Protocols Some terms (for next diagram) Some terms (for next diagram) LAR – last ack received LFS – last frame sent LFR – last frame received LAF – last acceptable frame
21
Data Link Protocols Sliding Window Protocols < SWS LARLFS ■ ■ ■ ─ RWS LFRLAF ■ ■ ■ < ─ Sender Window Receiver Window From: Peterson & Davie, Computer Networks (2003) Morgan Kaufman, pg. 102
22
Data Link Protocols Sliding Window Protocols Thought question – Thought question – What do you use for frame sequence number? What do you use for frame sequence number? 0-n … where n is the total number of frames-1 Modulo M
23
Data Link Protocols Go back n protocol Sender continues to send frames within constraint of send window Sender continues to send frames within constraint of send window Keeps track of oldest unacknowledged frame Keeps track of oldest unacknowledged frame if Time-out on oldest unacknowledged frame – if Time-out on oldest unacknowledged frame – resend all frames from oldest unacknowledged frame to last frame in other words, backup to oldest unacknowledged frame and resend everything trash potentially good frames sent after unacknowledged frame
24
Data Link Protocols Go back n protocol from Tanenbaum (2003) pg. 218
25
Data Link Protocols Selective resend/Frame buffering What if we toss out the wire rule What if we toss out the wire rule Sender sends sequence numbered frames up to the window size n Sender sends sequence numbered frames up to the window size n Receiver receives frames and for each frame Receiver receives frames and for each frame if no error returns an ack if error (out of sequence), sends nak If sender receives no ack or a nak for a specific frame it resends that frame only If sender receives no ack or a nak for a specific frame it resends that frame only
26
Data Link Protocols Selective resend/Frame buffering from Tanenbaum (2003) pg. 218
27
Data Link Protocols Selective resend/Frame buffering This means that frames can arrive at DLL out of sequence, however… they still must be passed to the Network layer in sequence, so The sender must buffer all frames in window, so it can resend any of them The receiver must buffer all incoming frames in window, so it can resequence them when they arrive out of sequence
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.