Can someone explain it to me as to why in selective repeat it's not possible for an acknowledgment to come for a packet that falls outside the current window? Because it may be possible that there is some delayed acknowledgment. It's possible in all sliding window protocols then why is statement 2 only true?
Moreover, in the solution, they mentioned that statement 2 is true because GBN has cumulative ack because of which if we receive ack 2 then the sender will assume that both packets 1 and 2 have been received successfully and so it slides the window to remove 1 and 2 from it but later we might get ack 1 which I feel is not possible because here we are talking about cumulative ack not independent.
So how is this reason valid?
Let's start from the back. Cummulative acknowledgments do not imply that there are delayed acknowledgements. GoBackN can in theory not acknowledge every single packet, but this is an optimization of practical protocols. So, I would assume, that GoBackN acknowledges every single packet.
Assuming that GoBackN acknowledges every single packet, the situation you are describing can happen. The receiver has received all packets in order, and send ACKs to every single packet in order. The channel however does not guaranty (reliable) in order delivery, i.e., the ACKs can arrive in arbitrary order. If two ACKs were reordered, exactly what they describe will happen.
In selective repeat each packet acknowledges only the packet received. And this only happens if the packet was sent. And the packet can only be sent as a part of sender window. Also, since ACKs are not cummulative, if the ACK for the second packet in the window is received first, the window will not move (since first packet is not acknowledged).
edit Actually, what could happen in selective repeat is following. Sender sends a packet, and receives no ACK. Then the timer fires, and the packet is retransmitted. And after the timer has fired, the first ACK has arrived. The window moves. Then, some time after the second ACK arrives, and it is outside the window. This can happen if the timer is set incorrectly, or if the ACK spent too much time somewhere in transit (which should be covered by the channel model). So, I guess you are correct, saying that it is possible.
Also, delayed ACKs usually refer to a TCP receiver, that does not acknowledge every received packet, but instead sends a single ACK for several of them. With cummulative acknowledgements this works trivially, since ACK for every single packet is not required. I don't see any way to implement delay acknowledgements for selective repeat, expect send 2 acks in the same packet, but then these ACKs will be for packets inside a window.
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).
While refreshing some old theory, and solving couple of problems, one instance had me confused: "7 packages (0 to 6) with window size 3 are sent. Packet no. 2 ACK is lost the first time it is sent, and packet number 4 gets lost the first time it is sent"
I am aware that the window size will now encompass packets [2,3,4] since ACK2 has not been received a timeout would occur, and that same window will be re-sent. But Packet 4 is lost.
I have tried to depict, what I think happens. Forgive my sketching skills:
For completeness. Lost acknowledge will not cause retransmission, because acknowledgement for next packet will implicitly ack the missing one.
Can somebody just simplely describe the retransmission mechanism in TCP?
I want to know how it deal in this situation?
A send a packet to B:
A send a packet.
B receive and send ack,but this ack is lose.
A timeout and resend.
In this situation B will receive 2 same packets, how can B do to avoid dealing the same packet again?
Thanks.
Each packet has a sequence number associated with it. As data is sent, the sequence number is incremented by the amount of original data in the packet. You can think of the sequence number as the offset of the first byte in the packet from the beginning of the data stream although it may not, likely will not, start at zero. When A sends the retry, it will use the same sequence number it used the first time. B tracks the sequence numbers as it receives data and can know that it has seen the retry's sequence number before. If it has already made that data available to the (upper layer) client, then it knows that it should not do so again.
I'm currently studying fairly basic networking, and I'm currently on the subject of reliable transmission. I'm using the book Computer Networking by Kurrose & Ross, and two of the review questions were as follows:
With the selective-repeat/go-back-n protocol, it is possible for the
sender to receive an ACK for a packet that falls outside of its
current window?
For the SR version, my answer to the question was as follows:
Yes, if the window size is too big for the sequence number space. For
example, a receiver gets a number of packets equal to the space of the
sequence numbers. Its receive window has thus moved so that it is
expecting a new set of packets with the same sequence numbers as the
last one. The receiver now sends an ACK for each of the packets, but
all of them are lost along the way. This eventually causes the sender
to timeout for each of the previous set of packets, and retransmits
each of them. The receiver think that this duplicate set of packets
are really the new ones that it is expecting, and it sends ACKs for
each of them that successfully reaches the sender. The sender now
experiences a similar kind of confusion, where it thinks that the ACKs
are confirmations that each of the old packets have been received,
when they are really ACKs meant for the new, yet-to-be-sent packets.
I'm pretty sure this is correct (otherwise, please tell me!), since this kind of scenario seems to be the classic justification of why window size should be less than or equal to half the size of the sequence number space when it comes to SR protocols, but what about GBN?
Can the same kind of wraparound issue occur for it, making the answers mostly identical? If not, are there any other cases that can cause a typical GBN sender to receive an ACK outside of its window?
Regarding the later, the only example I can think of is the following:
A GBN sender sends packets A & B in order. The receiver receives both in order, and sends one cumulative ACK covering every packet before and up to A, and then another one covering every packet before and up to B (including A). The first one is so heavily delayed that the second one arrives first to the sender, causing its window to slide beyond A & B. When the first one finally arrives, it needlessly acknowledges that everything up to A has been correctly received, when A is already outside of the sender's window.
This example seems rather harmless and unlikely in contrast to the previous one, so I doubt that its correct (but again, correct me if I'm wrong, please!).
In practical world, how about a duplicated ACK delayed long enough to fall out of the window?
The protocol is between the sender and the receiver, but it does not have control over how the media (network path) behaves.
The protocol would still be reliable according to design but the implementation shall be able to handle such out-of-window duplicated ACKs.
I try to understand the difference between Congestion window and Receive window.
As I understand, the receiver window is a buffer where the receiver can get the packets. The same is with the Congestion window which tell us the bound of the Receiver's abilities, and change according to lost packets, etc.
So what is the diffrence between them?
To give a short answer: the receive window is managed by the receiver, who sends out window sizes to the sender. The window sizes announce the number of bytes still free in the receiver buffer, i.e. the number of bytes the sender can still send without needing an acknowledgement from the receiver.
The congestion window is a sender imposed window that was implemented to avoid overrunning some routers in the middle of the network path. The sender, with each segment sent, increases the congestion window slightly, i.e. the sender will allow itself more outstanding sent data. But if the sender detects packet loss, it will cut the window in half. The rationale behind this is that the sender assumes that packet loss has occurred because of a buffer overflow somewhere (which is almost always true), so the sender wants to keep less data "in flight" to avoid further packet loss in the future.
For more, start here: http://en.wikipedia.org/wiki/Slow-start
Initially, CongWindow is set equal to one packet. It then sends the first packet into the network and waits for an acknowledgment. If the acknowledgment for this packet arrives before the timer runs out, the sender increases CongWindow by one packet and sends out two packets. Once all of these packets are acknowledged before their timeouts, CongWindow is increased by two—one for each of the acknowledged segments. Now the size of CongWindow is four packets, and thus, the sender transmits four packets. Such an exponential increase continues as long as the size of CongWindow is below the threshold and acknowledgments are received before their corresponding timeouts expire.One important difference is that CongWindow changes in size but receive window size is always constant.