SOLUTION QUIZ 5 CMPT 371 Consider flow control in TCP. Explain ...

SOLUTION QUIZ 5 CMPT 371 Consider flow control in TCP. Explain ... SOLUTION QUIZ 5 CMPT 371 Consider flow control in TCP. Explain ...

31.01.2013 Views

SOLUTION QUIZ 5 CMPT 371 Consider flow control in TCP. Explain two of the following mechanisms in detail a) Fast retransmit b) Use of sequence numbers and acknowledgement numbers c) Cumulative acknowledgements SOLUTION a) Fast retransmit is a mechanism used by TCP to improve TCP’s efficiency. TCP does not use NACKs so the only obvious way to know if a packet needs to be retransmitted is to wait for the retransmission timer for the packet to expire. The duration of the waiting period for the ACK (the duration of the retransmission timer) may be large. In fact it may be large enough that the contents of the entire sliding window (or congestion window if it is smaller) has been transmitted before the waiting period expires. Then, the time between the end of the transmission of the data in the sliding window (or congestions window) and the expiration of the timeout timer is not used for transmission. Not using this time for transmission reduces the efficiency of TCP transport. To improve the efficiency of TCP transport an alternate method of instigating retransmission of a lost packet is used. This alternate method is known as fast retransmission. Fast retransmission relies upon the acknowledgements that are received as a result of the receiver’s receipt of packets after the lost packet. Each time the receiver receives a packet it will send an acknowledgement to the source. This acknowledgement will indicate the next octet of data the receiver expects (the first octet in the lost packet). If a packet has been lost the packets following it will send the same ACK as the packet that preceded it because the receiver is still waiting for the same next packet of data. The duplicate ACKs received also implicitly tell the source that a packet that is not the next expected packet has been received. If three duplicate ACKs are received (the original, then three identical copies of the same ACK) the source will take this to mean that a packet has been lost, and will automatically retransmit the next packet the receiver is expecting (as indicated in the duplicate ACKs. This alternate mechanism to cause retransmission is called fast retransmit.)

<strong>SOLUTION</strong> <strong>QUIZ</strong> 5 <strong>CMPT</strong> <strong>371</strong><br />

<strong>Consider</strong> <strong>flow</strong> <strong>control</strong> <strong>in</strong> <strong>TCP</strong>. Expla<strong>in</strong> two of the follow<strong>in</strong>g mechanisms <strong>in</strong> detail<br />

a) Fast retransmit<br />

b) Use of sequence numbers and acknowledgement numbers<br />

c) Cumulative acknowledgements<br />

<strong>SOLUTION</strong><br />

a)<br />

Fast retransmit is a mechanism used by <strong>TCP</strong> to improve <strong>TCP</strong>’s efficiency. <strong>TCP</strong> does not use<br />

NACKs so the only obvious way to know if a packet needs to be retransmitted is to wait for the<br />

retransmission timer for the packet to expire. The duration of the wait<strong>in</strong>g period for the ACK<br />

(the duration of the retransmission timer) may be large. In fact it may be large enough that the<br />

contents of the entire slid<strong>in</strong>g w<strong>in</strong>dow (or congestion w<strong>in</strong>dow if it is smaller) has been transmitted<br />

before the wait<strong>in</strong>g period expires. Then, the time between the end of the transmission of the data<br />

<strong>in</strong> the slid<strong>in</strong>g w<strong>in</strong>dow (or congestions w<strong>in</strong>dow) and the expiration of the timeout timer is not<br />

used for transmission. Not us<strong>in</strong>g this time for transmission reduces the efficiency of <strong>TCP</strong><br />

transport. To improve the efficiency of <strong>TCP</strong> transport an alternate method of <strong>in</strong>stigat<strong>in</strong>g<br />

retransmission of a lost packet is used. This alternate method is known as fast retransmission.<br />

Fast retransmission relies upon the acknowledgements that are received as a result of the<br />

receiver’s receipt of packets after the lost packet. Each time the receiver receives a packet it will<br />

send an acknowledgement to the source. This acknowledgement will <strong>in</strong>dicate the next octet of<br />

data the receiver expects (the first octet <strong>in</strong> the lost packet). If a packet has been lost the packets<br />

follow<strong>in</strong>g it will send the same ACK as the packet that preceded it because the receiver is still<br />

wait<strong>in</strong>g for the same next packet of data. The duplicate ACKs received also implicitly tell the<br />

source that a packet that is not the next expected packet has been received. If three duplicate<br />

ACKs are received (the orig<strong>in</strong>al, then three identical copies of the same ACK) the source will<br />

take this to mean that a packet has been lost, and will automatically retransmit the next packet<br />

the receiver is expect<strong>in</strong>g (as <strong>in</strong>dicated <strong>in</strong> the duplicate ACKs. This alternate mechanism to cause<br />

retransmission is called fast retransmit.)


) <strong>TCP</strong> uses cumulate acknowledgements (ACKs). Each time a packet is received, the receiver<br />

sends an ACK is to the source. That ACK <strong>in</strong>dicates the next octet of data (from the stream go<strong>in</strong>g<br />

from the source to the dest<strong>in</strong>ation) the receiver expects to receive from the source. If a packet is<br />

received out of order the next expected octet (the same one as before) is still given <strong>in</strong> the ACK.<br />

Rather than acknowledge the particular octet that has just arrived the receiver will acknowledge<br />

the next octet of data expected. When that packet arrives the system will aga<strong>in</strong> acknowledge the<br />

(new) next octet of data required.


c) Each <strong>TCP</strong> packet conta<strong>in</strong>s two fields the sequence number and the ACK number. These two<br />

fields <strong>in</strong>dicate which data is <strong>in</strong> the packet and/or which data is expected next respectively. <strong>TCP</strong> is<br />

a full duplex protocol, this means that data can <strong>flow</strong> <strong>in</strong> both directions simultaneously. <strong>Consider</strong><br />

data <strong>flow</strong><strong>in</strong>g from Host A to Host B above as a cont<strong>in</strong>uous stream broken <strong>in</strong>to octets (8 bit<br />

chunks). The first octet sent will have a randomly chosen octet number.<br />

The octet number <strong>in</strong>dicates the location of the octet <strong>in</strong> the stream. If the first octet is 42, the<br />

second will be 43, the third octet 44, and so on. The sequence number of a packet go<strong>in</strong>g from<br />

Host A to Host B is the number of the first octet of data from the data stream <strong>flow</strong><strong>in</strong>g from Host<br />

A to Host B that is <strong>in</strong> that packet. Next consider data <strong>flow</strong><strong>in</strong>g from Host B to Host A above as a<br />

cont<strong>in</strong>uous stream broken <strong>in</strong>to octets (8 bit chunks). The first octet sent will have a randomly<br />

chosen octet number (<strong>in</strong> the diagram above octet 79). The sequence number of a packet go<strong>in</strong>g<br />

from Host B to Host A is the number of the first octet of data from the data stream <strong>flow</strong><strong>in</strong>g from<br />

Host B to Host A that is carried <strong>in</strong> that packet. Next, aga<strong>in</strong> consider the stream of data from A to<br />

B. Each time A sends a packet to B it will expect to receive an ACK from B <strong>in</strong>dicat<strong>in</strong>g that B has<br />

received the packet. The ACK that B sends to A will have the ACK bit set <strong>in</strong> the <strong>TCP</strong> header (to<br />

<strong>in</strong>dicate it is an ACK). When the ACK bit <strong>in</strong> a packet go<strong>in</strong>g from B to A is set then the ACK<br />

number <strong>in</strong> the <strong>TCP</strong> header <strong>in</strong>dicates the next octet of data (from the data stream go<strong>in</strong>g from A to<br />

B) that the receiver expects to receive. F<strong>in</strong>ally, consider aga<strong>in</strong> the stream of data from B to A.<br />

Each time B sends a packet to A it will expect to receive an ACK from A <strong>in</strong>dicat<strong>in</strong>g that A has<br />

received the packet. The ACK that A sends to B will have the ACK bit set <strong>in</strong> the <strong>TCP</strong> header (to<br />

<strong>in</strong>dicate it is an ACK). When the ACK bit <strong>in</strong> a packet go<strong>in</strong>g from A to B is set then the ACK<br />

number <strong>in</strong> the <strong>TCP</strong> header <strong>in</strong>dicates the next octet of data (from the data stream go<strong>in</strong>g from B to<br />

A) that the receiver expects to receive.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!