Here is my question, in sliding window protocol for flow control in l2 osi model, it is necessary to establish a full duplex connection?
because i think at the same time that frames are sending ACK from receiver should transmit for example if window size is 5 when 3th frame is sending ACK of 1th one should sent by receiver!
that is right??
Related
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?
Note: your pictures are unreadable, please provide a higher resolution images
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.
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.
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.
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, i.e., 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).
Host A is sending data to host B over a full duplex
link. A and B are using the sliding window
protocol for flow control. The send and receive
window sizes are 5 packets each. Data packets
(sent only from A to B) are all 1000 bytes long
and the transmission time for such a packet is
50 ps. Acknowledgment packets (sent only from
B to A) are very small and require negligible
transmission time. The propagation delay over
the link is 200 trrs. What is the maximum
achievable throughput in this communication?
This question was asked in gate my question. I have calculated it, but what is the meaning of word 'maximum'? The calculation was just for throughput. How would one calculate minimum throughput?
I think maximum means assuming no packets loss and therefore no retries. Also, no additional transmission time above the 50ms. Basically, given the above transmission time and propagation delay, how many bytes can be sent and acknowledged per sec?
My intuition is to figure out how long it takes to send 5 packets to fill up the window with the propagation delay added. Then add the time for the acknowledgement for the first packet to arrive at the sender. That's your basic window send and acknowledgement time because as soon as the acknowledgement arrives the window will slide forward by one packet.
Since the window is 5 packets and each packet is 1,000 bytes then the maximum throughput should be 5,000 bytes / the time you calculated for the above cycle.
I'm sending 1k data using TCP/IP (using FreeRTOS + LwiP). From documents I understood that TCP/IP protocol has its flow control inside its stack itself, but this flow control is dependent on the Network buffers. I'm not sure how this can be handled in my scenario which is described below.
Receive data of 1k size using TCP/IP from wifi (this data rate will be in 20Mb/s)
The received Wifi data is put into a queue of 10k size10 block, each block having a size of 1K
From the queue, each block is taken and send to another interface at lower rate 1Mb/s
So in this scenario, do I have to implement flow control manually between data from wifi <-> queue? How can I achieve this?
No you do not have to implement flow control yourself, the TCP algorithm takes care of it internally.
Basically what happens is that when a TCP segment is received from your sender LwIP will send back an ACK that includes the available space remaining in its buffers (the window size). Since the data is arriving faster than you can process it the stack will eventually send back an ACK with a window size of zero. This tells the sender's stack to back off and try again later, which it will do automatically. When you get around to extracting more data from the network buffers the stack should re-ACK the last segment it received, only this time it opens up the window to say that it can receive more data.
What you want to avoid is something called silly window syndrome because it can have a drastic effect on your network utilisation and performance. Try to read data off the network in big chunks if you can. Avoid tight loops that fill a buffer 1-byte at a time.
Consider a long flow being transmitted in 1 kB packets by a transport protocol that (only) uses AIMD to control the window size. Initially, the window size is 10 kB. Every time the window opens to 20 kB, the last packet in the window is dropped, which is detected exactly after one round-trip time, and re transmitted. How many packets are sent up to and including the first packet that is dropped?
The answer is 165 packets 10+11+12+13+14+15+16+17+18+19+20=165 as
Window will add one pkt each time till it gets a massage of dropping a pkt.
I'm going through some revision and I've been stumped by a TCP question. Maybe someone can give me a quick hint or push in the right direction, just so I can get passed this section.
"Why does the sending entity in TCP need to consider the size of the congestion window when determining the sliding window size? "
"Why does the sending entity in TCP need to consider the size of the congestion window when determining the sliding window size? "
This is because the size of the congestion window represents the possible congestion in the network. This is one of the key features offered by TCP. This window is updated in three stages.
In the first stage, when TCP starts, it starts with congestion windows as 1 MSS (Max Segment Size) and then ramps it up in a slow-start manner. TCP sender starts with this value because it is "estimating" how many packets it can send in the network. This phase is also known as slow-start phase. Btw, even though it is called slow-start, TCP increases the packet by doubling the congestion window and the increase happens upon reception of ACKs.
In the second stage, when the congestion window reaches slow-start (ss) threshold (yep, there is one!), TCP sender grows its cogestion window additively -- this is congestion avoidance phase. Here, the sender becomes more cautious. Once again, the increase happens upon reception of ACKs.
In the third stage, when a packet is dropped (one reason would be that a retransmission timeout happened), then TCP cuts its congestion window back to 1 MSS and restarts to grow it again. This is done because a likely congestion was encountered and so cutting back the congestion window would likely freeup the congestion situation along the path. Unlike other stages, the decrease happens due to lack of reception of ACKs.
TCP can use sliding window method to regulate the packets which need to be sent to the receiver. The receiver can also preserve a sliding window to keep track of which packets have been received and which have acked. When determining the sliding window size at the sender side, we should take the congestion window size into account, as we don't want to overwhelm the network channel. The actual traffic in the network is min{awnd,cwnd}, where awnd is the window size which is advertised by the receiver to the receiver, cwnd stands for the congestion window size, whose maximum value will change according to the network condition.