7.4k views

While opening a $TCP$ connection, the initial sequence number is to be derived using a time-of-day (ToD) clock that keeps running even when the host is down. The low order $32$ bits of the counter of the ToD clock is to be used for the initial sequence numbers. The clock counter increments once per milliseconds. The maximum packet lifetime is given to be $64$s.

Which one of the choices given below is closest to the minimum permissible rate at which sequence numbers used for packets of a connection can increase?

1. $0.015$/s
2. $0.064$/s
3. $0.135$/s
4. $0.327$/s
edited | 7.4k views
0
Someone plz explain this
0
@arjun sir,pls explain this question
0
@arjun sir,can you pls explain this??why do we need to inc seq. no. by 1 each 64 sec??
+4

Sorry. No idea. I'm not getting the meaning of the last sentence of question.

the minimum permissible rate at which sequence numbers used for packets of a connection can increase

This seems wrong because for "minimum" it should be "should increase" and not "can increase". The question was like this only on paper -

Don't know if marks were given to all or not as no answer keys were released in 2009.

0
ook.thankyou sir

One of the very rare ambiguous question in GATE. It is ambiguous what the question asks for

minimum permissible rate at which sequence numbers used for packets of a connection can increase

It is not meaningful to use "minimum" with "can increase" - should be either "maximum" with "can" or "minimum" with "should/must"

Now the second problem,

rate at which sequence numbers used for packets of a connection

In TCP, once the Initial Sequence Number(ISN) is set, the increase in sequence number is determined by the data sent rate - for every 8 bits, it increases by $1.$ If the question is asking for this rate, then it is independent of the ISN and depends on the packet lifetime and number of possible sequence numbers. With $32$ bits we have $2^{32}$ sequence numbers possible and to avoid using the same sequence number while a packet with one is still alive, we should ensure no more than $2^{32}$ sequence numbers in a packet lifetime which is given as $64s$. So, maximum increase possible for sequence number will be $2^{32}$ in $64s$ which will be $2^{26} /s= 64M/s$ corresponding to a data rate of $64 \times 8 = 512 Mbps.$ This is not in the option.

Now the other possible meaning of the question is the rate at which the ISN of a packet can increase. This problem comes when a connection gets aborted and re-established (i.e., same IP and Port addresses at sender and receiver) very soon. In this case, receiver might get confused if it gets any sequence number which might have been used by the old connection. To, avoid this the new sequence number must be used only after all previous ones are dead. i.e., only after Maximum Life time of a packet which is $64s$. (Page 29, TCP Specification) This ensure that ISN can change only once in $64s$ giving the rate change as $1/64 = 0.015/s$ which is option A. (Even though, the ISN is changing only once, as per the question the new ISN is not old ISN +1 but old ISN + time passed in milliseconds)

Option A.

edited by
0

Please explain the last part, I am not getting it.

To, avoid this the new sequence number must be used only after all previous ones are dead. i.e., only after Maximum Life time of a packet which is 64s. (Page 29, TCP Specification) This ensure that ISN can change only once in 64s giving the rate change as 1/64=0.015/s which is option A. (Even though, the ISN is changing only once, as per the question the new ISN is not old ISN +1 but old ISN + time passed in milliseconds)

$3$ information present in the question.

1. The low order $32$ $bits$ of the counter of the ToD clock is to be used for the initial sequence numbers - That means only $32$ $bits$ are used to represent a sequence number. So, we have$2^{32}$ different sequence number.
2. The maximum packet lifetime is $64s$. So, by $1$ & $2$ we can calculate maximum data rate possible(bandwidth) to avoid the wraparound= $2^{32}/64= 2^{26}$ Bytes/sec.
3. The clock counter increments once per milliseconds -That means when then counter increments next possible sequence number is generated.

Suppose we make a TCP connection by picking initial sequence number that is derived by clock.If the connection terminate after sending few bytes of data then to avoid the ambiguity of sequence number we don't reestablish the connection immediately because of counter increment happen after $1$ msec.

Suppose the sender sends $2^{24}$ Byte data.

Time required to send $2^{24}$ Bytes data is $2^{24}/2^{26} =250$ ms. So, $2^{24}$ Bytes takes $2^{24}$ sequence number . ($2^{24} \times 1)$ ms required to increment the counter .

So, the permissible rate of sequence number used for packets is in 64 sec we use only sequence number .

So, $1/64= 0.015$ (approx) which is option A here.

edited
+5

gari

the packet life time is 64 seconds.. and after this 64 seconds next sequence number is come. So that means in this 64 seconds  only 1  sequence number is generated .

Hence the minimum rate is =1/64 = 0.015/sec.

+1
Thanku so much sir :)
+1
@Bikram Sir,

Then what is the role of the statement "Clock counter increments once per millisecond" ?Is it to create confussion ?
0
that statement means  when the counter increments next possible sequence number is generated.
0
Yes that is true.But where are we using this information that clock generates 1 sequence per millisecond .This is what it is saying?
+1

for a lifetime of 64s it will increment 64000 times...(because in 64 sec there are 64000 ms) and rather to increment these many times the minimum no of times it can increment is 1 time.

only 1 sequence no is generated in a packet lifetime .

packet life time is 64 seconds.. and after this 64 seconds next sequence number is come. So that means in this 64 seconds  only 1  sequence number is generated .

0
So that is what i am saying that the statement that it increment once per millisecond is not useful? Because if we are assuming it increments once per 64 sec.
0
yes, you can say that.
0
@bikram sir then why is the use of data they have given 32 bits of ToD clock to be used for initial sequencde numbers???
0
Can someone please help me, please? As far as I can understand, Max possible Bandwidth is 2^26 Bytes/sec. Since, TCP gives a sequence number to every byte, 2^26 sequence numbers are needed in a second. But the counter only generates 1000 sequence numbers in a second.

How is the counter generates only 1 sequence number in the packet lifetime of 64seconds. I mean if 1000 sequence numbers are generated in a second, wouldnt it be like 64000 sequence numbers in a packet lifetime?

Is ToD counter controlled by TCP? How is it that 2^24ms is needed to increment the counter when it is clearly stated that the counter gets incremented every 1 ms?

A. Because sequence number is incremented once every 64 sec.

Rate = 1/64=0.015

0
I also think so. But I am confused a bit as answer on many websites is given 0.064/s without any convincing explanation. So can you discuss it please or site some reference so that we are sure about the chosen answer.

Thank You
0

No, I don't know any reference for that. But that's the first thing that comes to mind.
Yes, on most of the places it is 0.064 without explanation, that must be given in gate key I think.

0
0
Why is sequence number incremented once every 64seconds?
0
It is incremented once 64 sec the only it will satisfy wrap around time condition if a seqence number is generated before 64 sec they map to same value since TCP used random intial sequence genarator
To find the minimum permissible rate of sequence no, we need to consider the packet life time. We need at least the rate such that it generate only one sequence no in packet life time i.e in 64 sec.

So , the minimum rate is =1/64 = 0.015/sec.
0
What is the meaning of Permissible rate?
Here not any problem like ambiguity.

since if we increment 1 per 1ms and life time of packet is given 64s. But i think question is not asking in this scenario.TCP uses Sliding Window Protocol.

Here Minimum Permissible rate may be confusing but think like that if life time of packet is given 64s so this is max . Means if we increment seq.no per 64 sec is allowed but more than 64s should not be allowed. If we keep more than 64s for 1 sequence number we need to wait for next sequence without any reason.

so ans should be=1/64s = 0.015/s
reshown by
0
@papesh,

"sequence number used for a packets of a connection" does it mean that we are not talking about a single byte or single packet but packets of a connection in SWP. But for each byte of a packet withing 65 sec we have to increment seq number then why we are not considering this fact.OR we are just considering the seq number of packet.

for eg A connection of TCP sending two packets with 100 bytes in each packet and intial seq number of packet is 100.then

Packet 1(seq number from 100 to 199)

and packet 2(seq number from 200 to 299)

withing 64 sec these seq number will be live so after that for a new connection we have to assign new seq number for packets.If we increment before 64 sec then there is no problem still the new connection will get a seq number.BUT if we wait suppose for 70 sec then for establishing a new connection we have to wait for 6 more sec to get a seq number for our connection.

Is my understanding correct or I am missing something?

1
2
3
4
5
6