CS325 Exam #2 Solutions: ------------------------ Problem 1: ---------- a) If the channel is initially idle, the host waits for DIFS and then sends. If it was busy, then even after the transmission ends we wait DIFS *plus* some random waiting. This makes some sense: If all was quiet, maybe we're the only ones competing for access. If we hear even one other host, it's evidence that we've got potential competition and need to be more careful about collisions even though one hasn't yet occurred. b) This is a bad idea. After a transmission ends, the host receiving that transmission is supposed to send an ACK. They're only waiting SIFS, so if you send after waiting SIFS you'll wipe out their ACK. That doesn't do anybody any good -- your packet and the ACK will both be wiped out. It performs worse than a standard implementation. Problem 2: ---------- a) It won't work. For starters, the packet formats are different. The sender is putting a sequence number in each outgoing packet, and it's expecting a sequence number (or ACK number) in each incoming packet, but the receiver isn't using sequence numbers in its packets. Also, the receiver sends NAKs if something goes wrong, but the sender doesn't have any transitions for dealing with incoming NAKs. b) Note that the ACK that the transition is checking for is the *wrong* ACK. So both of those cases are "bad news" -- either the incoming packet was garbled, in which case we don't know what it was trying to tell us, or it was an ACK for the wrong packet. In either case the response should be to (eventually) resend the last outgoing data packet. The sender is lazy, and ignores the bad news for now, counting on the timeout to force the retransmission. c) The data that arrived in that scenario was undamaged, but it was a duplicate. We'd already received data packet #0 and delivered its contents to the layer above or we wouldn't have made it into the "Wait for 1" state. Thus if we get #0 again we should ACK it (to ensure the other side finally gets the news), but we don't want to deliver duplicate data to the layer above. Problem 3: ---------- a) It takes 20 seconds to send the packet (1000 bits / 50 bits/second), so at time t=20 seconds the last bit is being transmitted. It takes another 500 seconds for that final bit to arrive at the submarine (500 miles / 1 mile/second) arriving at the submarine. Assuming immediate turn-around, it would take another 500 seconds for the response to start arriving. That's 20 + 500 + 500 = 1020 seconds in total. b) We were sending for 20 seconds out of 1020. 20/1020 is 1.96%. Ouch. c) We've got 1020 seconds to fill, and it takes 20 seconds per packet. That requires 1020 seconds / 20 seconds/packet --> 51 packets.