420 likes | 620 Views
Data Link Layer. Concerned with the tranmission of “frames” between two directly connected IMP’s. We follow [Tannenbaum]. Note that (prove for ec) -> +5 IMP=interface message processor (nod or station). IMP. IMP. IMP. Host. IMP. Host. HOST. HOST. IMP. IMP. HOST. Host.
E N D
Data Link Layer • Concerned with the tranmission of “frames” between two directly connected IMP’s. We follow [Tannenbaum]. Note that (prove for ec) -> +5 • IMP=interface message processor (nod or station) IMP IMP IMP Host IMP Host HOST HOST IMP IMP HOST Host
DLL doesn’t worry about which other IMP [network layer] • DLL doesn’t worry about how to xmit bits [physical layer] • frame = block of data • frame -> sync bits, header, info field, error checking. • header -> kind, seq, ack. • seq = sequence number. • kind = classification • ack = acknowledge (used in two way communications) • DLL is layer 2
Sending IMP Sending IMP virtual connection net layer net layer data link layer data link layer physical layer physical layer physical connection
The DLL gets packets from the net layer (getp). It sends frames to the other DLL (sendf). The other DLL gets the frames (recf) and returns them to the higher net layer (givep). The receiver has a procedure called wait.
wait getp(packet) frame recf frame.info <- packet packet frame sendf(frame) givep sender 1 receiver 1
An unrestricted simplex protocol (protocol 1)->problem: could swamp the reciever, no error recovery A simplex stop-and-wait protocol (protocol 2)
wait event getp(packet) frame.info <-packet no event sendf(frame) =frame arrival? set timer wait (event) yes timout no recf(frame) event=ack givep(frame_info) yes sendf(ack) sender 2 reciever 2
With networks you must have distributed algorithms. The problem with simplex stop and wait, the return channel may have an error. Let s=sender, r=receiver • s, sends a frame to r. • r sends an ack to s but it is not recieved by s. • s times out and retransmits • r obtains 2nd copy of the frame • This is known as a duplication error! • To stop duplication errors we add sequence number, e.g. 0,1,2,3...
What is the smallest frame identifier we can use? We would like to use the min. number of sequence numbers. Could use 0,1,0,1... because of the stop and wait protocal.
Known as a “positive acknowledgement/retransmission protocal (par)” [Tanenbaum 89], or sometimes called “complete stop and wait”. This allows data to be transmitted in one direction (half duplex) over a noisy communication channel that garbles and loses frames. • If frame m is lost of damaged, the receiver will not ack and the sender keeps trying. • If the receiver gets the wrong seq number, it is rejected as a duplicate.
The sender waits for a positive ack before advancing to the next frame. It requires the timeout to be long enough to prevent premature times outs, to prevent dups.
The only ambiguity is between frame m and m+1. If the sender times out too early, while an ack is on the way a dup frame will be sent. The ack arrives and the sender is fooled into thinking the ack is for the frame just sent (not the dup). If the next frame is is lost, the sender will not try to retransmit and the protocol fails. PAR can deadlock if the sender times out too early.
Sliding window Protocols • For TFTP [Stevens] the frames and acks are numbered. timeouts occur for any frame, frames are transmitted continuously. No deadlocks can occur. Sliding window protocols remain synchronized in the face of garbled or lost frames. They can handle premature timeouts.
In TFTP a seperate ACK is always sent when a frame arrives. This is a half-duplex xmission. If transmission were full-duplex, we could improve throughput via piggy backing. • This involves adding a frame ack code to the next outgoing frame. This means hold up the xmission of the ack till the next frame is ready. If we wait beyond the timeout, the rexmission occurs.
send DATA(n) receive DATA(n) send ACK(n) (time out) retransmit DATA(n) receive DATA(n) (duplicate) receive ACK(n) send DATA(n+1) send ACK(n) (duplicate) receive ACK(n) duplicate receive DATA(n+1) send ACK(n+1) receive ACK(n+1) send DATA(n+2) receive DATA(n+2) send ACK(n+2)
n 2 - 1 • TFTP takes (with comments and command line processing) 2000 lines of C code. • The max sequence number is • , where n=length of the ack field in the frame. For TFTP packets, an ACK takes 4 bytes. Two bytes for the op-code, two bytes for the sequence number. Data blocks may be 512 bytes long.
n 512 ( 2 - 1 ) = 33 , 553 , 920 • TFTP will run out of sequence numbers after • bytes are sent without ack. • Stop-and-wait uses n=1 so that sequence number are 0 and 1. • A one Bit Sliding Window Protocol. This is stop-and-wait since the sender transmits a frame and waits for its ack. Protocal 4 withstands errors and timeouts
receive DATAL(0) send DATAL(0) send DATAR(0) ACK(0) (time out) retransmit DATAL(0) receive DATAL(0) (duplicate) send DATAR(0) ACK(0) receive DATAR(0) ACK(0) (duplicate) send DATAR(1) ACK(0) receive DATAR(0) ACK(0) receive DATAL(1) ACK(0) (drop on floor) send DATAR(1) ACK(1) receive DATAL(1) ACK(1) send DATA(0) ACK(1) receive DATAL(0) send ACK(0)
B gets(0,1,A0) B sends(0,0,B0) B gets(1,0,A1) B sends(1,1,B1) B gets(0,1,A2) B sends(0,0,B2) A sends(0,1,A0) A gets(0,0,B0) A sends(1,0,A1) • 1-bit sliding window protocol. ack=#of last frm rcvd. A gets(1,1,B1) A sends(0,1,A2) A gets(0,0,B2) A sends(1,0,A3) B gets(1,0,A3) (seq,ack,pack#) B sends(1,1,B3)
A sends(0,1,A0) B sends(0,1,B0) B gets(0,1,A0) A gets(0,1,B0) B sends(0,0,B0) A sends(0,0,A0) • protocol fails if both xmit at same time, half the frames contain dups. B gets(0,0,A0) B sends(1,0,B1) A gets(0,0,B0) A sends(1,0,A1) B gets(1,0,A1) B sends(1,1,B1) A gets(1,0,B1) A sends(1,1,A1) B gets(1,1,A1) (seq,ack,pack#) B sends (0,1,B2)
Go Back N Protocol • Suppose the transmission time required for a frame to arrive at the receiver plus the transmission time for the ack to come back is non-trivial. • E.g. a 50 kbps satellite channel could have a 500 ms round trip time. To xmit a 1000 bit frame takes 20 ms, but it is not until 520 ms that the sender gets an ack and so is blocked 500/520 = 96% of the time.
Let w=#of frames to xmit before blocking. • at 20 ms per frame and 500 ms/ack we should set w=(500+20)/20=26 frames (at least) • This is known as pipelining
let • b= channel capacity (bps) • l = frame size (bits) • R=round-trip propagation time (sec) • l/b=time to xmit a frame (sec) • U=channel utilization (efficiency) • In stop-and-wait, the line is busy for l/b seconds and idle for R seconds. l 1000 500 U = = = . 0384 1 = - + - 3 l bR 520 + 1000 50000 500 10 * * if l = bR then U = . 5 < if l < bR then U . 5
1 0.9 0.8 • U varies in inverse proportion to the bR product. 0.7 0.6 0.5 0.4 x 0 500 1e+03 1.5e+03 2e+03 0.3 1000 [ ] U = , X Î 0 . 2000 1000 + X
The reciever in the data link layer is required to hand packets to the network layer IN SEQUENCE. If you pipe line then there may be problems: • A frame is damaged...or lost • Many frames may fall on the floor w/o feedback to the sender • What should be done with frames following a damaged frame?
We have seen that TFTP can have 30MB in a pipe w/o repeating a sequence number...should I drop the pipe if I get a bad frame? • Go back N and Selective repeat are two solutions to these problems.
With go back n, the receiver lets all the bits coming out of the pipe fall on the floor, sending no acks. This corresponds to a window size of 1. • With selective repeat, only the bad frame falls on the floor, the rexmit takes a while, but when it does happen, an assembled in-order sequence is passed to the net layer. This corresponds to a window size of larger than 1. If the window is large (e.g. tftp) the buffer can be big (30 MB) esp if the time out time is long.
This is an example of trading space for bandwidth. • If MaxSeq=7 then • 1. The sender sends frames 0-7 • 2. a piggyback ack for frm 7 arrives at the sender • 3. the sender sends another 8 frms, again with seq#’s0-7 • 4. Now another ack for frame 7 comes in.
Question: did all 8 frames in the 2nd batch arrive, or get lost? There is no way to tell, so the number of outstanding frames must be Š MaxSeq. • Multiple timers are needed for multiple frames.
Selective Repeat • If the line is poor, the pipe line is big (like TFTP) and the timeouts large, you waste bandwidth. • To save the pipe, we rexmit selective frames. A list of frames is kept by the recvr. New frame are admitted. Dups are discarded. Frames arrive in any order, up to MaxSeq. • Problem: the sender sends MaxSeq frames, the rcvr acks are all lost...the sender rexmits and the rcvr gets dups. • Fix: let the window size = (MaxSeq+1)/2.
Only frames within the window are accepted. • If we piggyback on the reverse channel and traffic is light ack length will be long. In protocal 5, after MaxSeq frames, the protocol blocks. Protocal 6 sends a NAK to indicate chksum err. • In either net TCP does the flow control, connections, checkums, ack, timeouts, dup detecting and sequencing.
IP establishes message boundaries. UDP does this too. • IP and UDP are connectionless, unreliable datagram services. Therefore you choose TCP/IP or TCP/UDP [Stevens]. • Protocol performance • Performance of the Stop-and-wait Protocol
A = # of bits in an ACK C = channel capacity in BPS D = # of data bits per frame E = prob . of a bit being in error F = D + H ( total frame length ) • An unrestricted simplex protocol has U=1 since sender runs flat out. • Suppose stop-and-wait has fixed-length frames and no piggybacking like Protocol 3 (par) postive ack/rexmit protocol. • NOTATION
H = # of bits in the frame header I = interrupt and service time + prop . delay L = prob . that a frame or its ACK is lost or damaged P = prob . that a data frame is lost or damaged 1 P = prob . that an ACK frame is lost or damaged 2 R = mean number of rexmissions per data frame T = time out interval U = channel utilization ( efficiency ) W = window size Assume that the channel is perfect ( )
D U = + + + H D A 2 CI • It takes F/C seconds to xmit a frame and F/C+I seconds for the frame to arrive and get serviced. In F/C + A/C +2I seconds the sender has finished processing the ACK. • Only D data bits were sent in 2I + (F+A)/C seconds.
for a perfect channel. Therefore H+A+2CI are the overhead in the protocol (which contribute nothing if the channel is error free). • Channels have errors, however. The sender timesout in F/C + T seconds, this uses F+CT bits of bandwidth.
R ( F + CT ) + ( F + A + 2 CI ) prob _ of _ successful _ xmission = ( 1 - P ) ( 1 - P ) 1 L = 1 - ( 1 - P ) ( 1 - P ) 1 2 k - 1 prob _ of _ k _ attempts = ( 1 - L ) L å E [ X ] º x P ( x ) i X i i ¥ 1 k - 1 å avg _ # attempts = k ( 1 - L ) L = 1 - L • 1 k = where (1) 2 • Total channel cap. for R (=avg #bad frames) and 1 good one is (2) (3) since The avg number of transmissions per frame is
¥ ¥ ¥ 1 k - 1 k k å å å k ( 1 - L ) L = kL - kL ¥ L k å kL = 2 ( L - 1 ) k = 1 • proof: • (3a) L k = 1 k = 1 k = 1 • (3b) subst. (3b) into (3a) (3c) ¥ ¥ 1 1 L L 1 - L 1 k k å å kL - kL = - = = 2 2 2 L L 1 - L ( L - 1 ) ( L - 1 ) ( L - 1 ) k = 1 k = 1 Q.E.D.
L R = 1 - L R ( F + CT ) + ( F + A + 2 CI ) • The average number of retransmissions per frame is one less, or: • (4) using (4) and the fact that: Total channel cap. for R (=avg #bad frames) and 1 good one is D (5) U = ( L / ( 1 - L ) ) ( F + CT ) + ( F + A + 2 CI ) if the variance of I is low then (6) subst (6) into (5) gives: D (6a) U = ( L / ( 1 - L ) ) ( F + A + 2 CI ) + ( F + A + 2 CI )