4.8k 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 | 4.8k 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??
+2

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

Ans is option A .

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 Byte/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 sent 2^24 Byte data is 2^24/2^26=250 ms. So 2^24 Byte takes 2^24 sequence number . (2^24 * 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 by
+2

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 :)
0
@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.
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?

Because TCP is a byte-oriented protocol, each byte of data has a sequence number; the SequenceNum field contains the
sequence number for the first byte of data carried in that segment.

Now we have a $32$ bit sequence number field and to avoid the wraparound problem -- a byte getting an already used sequence number of an earlier byte which is still alive on the network -- we need to restrict the bandwidth such that no more than $2^{32}$ bytes are generated in the network during a TCP packet (segment) lifetime which here is 64s. So, maximum permissible bandwidth

$= \frac{2^{32}}{64} = 2^{26} \approx 64 \times 10^6 = 512 MBps.$

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 -

Now, lets assume the question meant "maximum" and not "minimum".

Let the initial sequence number be say 100 and that of the following segments be 600, 1200, 1500 etc. This goes on increasing and the maximum allowed bandwidth takes care of wraparound issue. But here the clock causes another issue when a new connection comes. The sequence number range allocated to the new connection must not interfere with the already used one. So lets discuss this:

1. We know that segment with sequence number 100 is on the network for 64s.

2. The clock increments after 1 millisecond and the new clock value will be 101.

3. Suppose a new connection request comes, it cannot be given the sequence number 101. But what else can be given?

edited by
0
@arjun sir
To be safe from WAT problem can we increase the sequence no(In worst case can we take it from the available option BYTES?)??