Problem 1:
----------

a) A triple-ACK occurs when a TCP packet is damaged or lost, but subsequent data transmissions arrive at their destination undamaged. The receiving side always ACKs incoming data packets, but they carry the sequence number of the last byte received before the gap. If the sender gets three ACKs in a row that carry the same sequence number, it's evidence that there's a missing packet and TCP retransmits the data in question without waiting for timeout. 

b) It does not lead to correctness issues. (After all, Go-Back-N uses a sliding window and the sender and receiver's windows are of vastly different sizes.) It will potentially be less efficient though, when data packets get lost. Imagine a sender with a window size of 10, interacting with a receiver whose window size is 5. If the sender transmits 10 packets but the first packet got damaged or lost, the receiver can only hold the next four while it waits for the missing data. It will therefore have to drop 5 perfectly good packets -- the last 5 sent by the sender -- and those will need to be retransmitted eventually by the sender, leading to less efficient use of the channel.

c) Basically because we can't trust the Network layer. If packets get dropped in the Network layer due to congestion, or go astray due to issues with routing, someone at a layer above the Network layer has to verify reliable delivery.


Problem 2:
----------

a) In both of those cases, the sender is timing out because it didn't get an ACK, so it's time to resend the current data packet. And, in both of those cases, the most recently send data packet is still stored in the sndpkt variable, so we can just do:

	udt_send(sndpkt)
	start_timer
	
b) In both of these cases the sender is waiting for new data to send from the layer above. Any incoming transmissions will be ACKs for duplicate data transmissions, so we can just ignore them. The official notation for that is a capital lambda. I'll approximate it here as:

	^
	
c) The receiver doesn't ever need to send "bad news" about packets that are missing. Worst case, it can keep silent and the sender will retransmit once it times out. In this protocol though, the sender really *is* sending bad news to help speed up the process -- it's just sending an ACK with an incorrect sequence number to indicate missing data.

Problem 3:
----------

a) AIMD is the approach TCP uses to adjust the congestion window. It needs to constantly adjust the window to ensure that it's avoiding congestion at the network layer below, but coming *close* to that point so that it can maximize its transmission rate.

b) AIAD would be slower to resolve congestion once it occurs, which means there will be a bigger backlog of packets to clean up once the network layer gets a chance. Also, AIMD ensured that TCP hosts would eventually share bandwidth evently. With AIAD there would be no such fairness.

c) No. UDP doesn't make any effort to restrict its transmission rate, so it has no use for a congestion control mechanism.


Problem 4:
----------

The send() method is called by the layer above (in our case, the WiFi Client). Once it's called, it accepts a packet for transmission, hands it off to the sending thread, and immediately returns to the caller. (The specifics of the "hand off" depend upon your implementation.)