Stumbling on a Reliable UDP implementation

Question

I received an assignment from the College where I have to implement a reliable transfer through UDP aka. TCP Over UDP (I know, reinvent the wheel since this has already been implemented on TCP) to know in deep how TCP works. Some of the requirements are: 3-Way Handshake, Congestion Control (TCP Tahoe, in particular) and Waved Hands . I think about doing this with Java or Python.

Some more specific requirements are:

After each ACK is received:

• (Slow start) If CWND < SS-THRESH: CWND += 512
• (Congestion Avoidance) If CWND >= SS-THRESH: CWND += (512 * 512) / CWND
• After timeout, set SS-THRESH -> CWND / 2 , CWND -> 512 , and retransmit data after the last acknowledged byte.

I couldn't find more specific information about the TCP Tahoe implementation. But from what I understand, TCP Tahoe is based on Go-Back-N, so I found the following pseudo algorithm for sender and receiver:

My question is the Slow Start and Congestion Avoidance phase should happen right after if sendbase == nextseqnum ? That is, right after confirming the receipt of an expected ACK?

My other question is about the Window Size, Go-Back-N uses a fixed window whereas TCP Tahoe uses a dynamic window. How can I calculate window size based on cwnd?

Answer 1

Note: your pictures are unreadable, please provide a higher resolution images

1. I don't think that algorithm is correct. A timer should be associated with each packet and stopped when ACK for this packet is received. Congestion control is triggered when the timer for any of the packets fires.

2. TCP is not exactly Go-Back-N receiver. In TCP receiver has a buffer too. This does not require any changes at the sender Go-Back-N. However, TCP is also supposed to implement flow control, in which the receiver tells the sender how much space in its buffer remains, and the sender adjusts its window accordingly.

3. Note, that Go-Back-N sequence number count packets, and TCP sequence numbers count bytes in the packets, you have to change your algorithm accordingly.

4. I would advice to get somewhat familiar with rfc793. It does not have congestion control, but it specifies how other TCP mechanics is supposed to work. Also this link has a nice illustration of TCP window and all variables associated with it.

My question is the Slow Start and Congestion Avoidance phase should happen right after if sendbase == nextseqnum? That is, right after confirming the receipt of an expected ACK?

your algorithm only does something when it receives ACK for the last packet. As I said, this is incorrect.

Regardless. Every ACK that acknowledges new packet shoult trigger window increase. You can do check this by checking if send_base was increased as the result of an ACK.

Dunno if every Tahoe implementation does this, but you may need this also. After three consequtive duplicate ACKs, ie, ACKs that do not increase send_base you trigger congestion response.

My other question is about the Window Size, Go-Back-N uses a fixed window whereas TCP Tahoe uses a dynamic window. How can I calculate window size based on cwnd?

you make the N variable instead of constant, and assign congestion window to it.

in a real TCP with flow control you do N = min (cwnd, receiver_window) .