8.2k views

Assume that the bandwidth for a $TCP$ connection  is $1048560$ bits/sec. Let $\alpha$ be the value of RTT in milliseconds (rounded off to the nearest integer) after which the $TCP$ window scale option is needed. Let $\beta$ be the maximum possible window size with window scale option. Then the values of $\alpha$ and $\beta$ are

1. $63$ milliseconds, $65535$ $\times$2$^{14}$
2. $63$ milliseconds, $65535$ $\times$2$^{16}$
3. $500$ milliseconds, $65535$ $\times$2$^{14}$
4. $500$ milliseconds, $65535$ $\times$2$^{16}$
edited | 8.2k views
+1
sir round trip time is time of data from sender to receiver+ and time of ack from sender to receiver, since nothing is said about propagation time, u took transfer time only while counting turn around time  but sir why have u not  multiply it by 2. and for the second part the window size if generally  16 bits but it can be increased by 14 bits making it 30 bits. So sir answer should be 2^30 which is 65536*2^14, why 65536 *2^14
+8

Following Link can be useful for understanding the concept of window scaling quite well.

http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/

0

Notice --> Some options may only be sent when SYN is set; they are indicated below as [SYN]

https://en.wikipedia.org/wiki/Transmission_Control_Protocol

0
the bandwidth delay product is calculated for one side alone right its the maximum amount of data that can be present on the link before we get the ack for data sent hence 2*Tp*BW right @Arjun sir this is same as channel capacity in case of full duplex connections
0

+1
Why have we taken sequence no 16 bits as in TCP sequence no is of 32 bits?
0
it is not sequence number....it is maximum window size

In TCP when the bandwidth delay product increases beyond $64$K receiver window scaling is needed.

The bandwidth delay product is the maximum amount of data on the network circuit at any time and is measured as RTT * Bandwidth. This is not the time for sending data rather just the time for sending data without acknowledgement.

So, here, we have bandwidth delay product = ($1048560$ / $8$) B * α = $64$ K
α = ($64$ K * $8$ ) / $1048560$ = $0.5$ s = $500$ milliseconds.

When window scaling happens, a $14$ bit shift count is used in $TCP$ header. So, the maximum possible window size gets increased from $2$16-$1$ to ($2$16-$1$) * $2$14 or from $65535$ to $65535$ * $2$14

http://en.wikipedia.org/wiki/TCP_window_scale_option

edited by
+4
When window scaling happens, a 14 bit shift count is used in TCP header.
sir why 14 bit only ?? any reason or just an assumption ??
+2

No idea why, but only 14 bits are allotted for this. Should have some practical significance.

https://technet.microsoft.com/en-us/library/cc938219.aspx

0
why only 64 kb is used
+1
arjun sir in RFC its mentioned that max window size after scaling is 2^30 - 1 that is aroung 1GB. Why you took it as (2^16-1)*2^14. It evaluates to 2^30-2^14 which is much less than 1G??
0
How much less?
0
less by 2^14. Isnt??
0
yes, but percentage wise?
0
2^14/2^30 * 100 %??? Sir am i wrong?
+1
U r subtacting 16kb from 1 gb ... not a significant difference..
+1
@Arjun

Sir, Bandwidth is given in Bits/Second and alpha is in milliseconds. So while multiplying why they are not converted to a common unit ?
0
0
One practical significance why window scale factor is limited to value of 14 because, then final window size would be

$2^{16}.2^{14}=2^{30}\,Bytes$ and maximum sequence numbers we can have is $2^{32}$.
+1
The reason why maximum value is 14 is because (2^16)*(2^14) = 1,073,741,824. If it increases beyond this then it will surpass the Sequence no#. Sequence no# is 4 bytes (2^32) and the size of the window can't go beyond the maximum value of the sequence no#.

because TCP window scale option is needed when size increases more than 65535 B. it means alpha (RTT) should be the time taken to send 65535 B to the receiver.

Time to send 65535 B = 65535 * 8/1048560 *1000 = 500 ms.

so alpha will be 500.

maximum window size with window scale option is possible in TCP is 1073725440 B which is 65535*2^14 .

http://en.wikipedia.org/wiki/TCP_window_scale_option

0

because TCP window scale option is needed when size increases more than 65535 B. it means alpha (RTT) should be the time taken to send 65535 B to the receiver.

Time to send 65535 B = 65535 * 8/1048560 *1000 = 500 ms.

IT SHOULD BE: // Time to send 65535 B = 65535 * 8*1000/1048560 = 500 ms.

so alpha will be 500.

maximum window size with window scale option is possible in TCP is 1073725440 B which is 65535*2^14 .

http://en.wikipedia.org/wiki/TCP_window_scale_option

Basically We are not utilizing the given bandwidth at its fullest. Sticking to the question, it causes due to the delay caused in sending the data.

(You can consider the example of satellite link , It causes much delay for acknowledgement to arrived after sending data equal to current window size)

One of the solution is we can consider upgrading window size that will pack the data , utilizing maximum of the given bandwidth.

The units we consider for data is in Bytes and delay in "ms"

Lets have a look at our Question.

Given,

B = (1048560/8) B/s

RTT ( alpha ) = X ms ( say)

Current ( default) window size, RWIN = 65535 B

( RWIN = Reciver window )

Using Bandwidth * Delay product ,

B * X = 65535 ,

X = 500 ms.

To use the given Bandwidth  to ita fullest , we can scale our window upto 1GB ( fixed standard)

i.e with scaling factor of 2^14 B

(i.e Shifting 14 bits to left )

So, scaled window size becomes,

65535 * 2^ 14.

(2^16 * 2^ 14 = 2^30 , i.e 1GB )

https://www.speedguide.net/faq/what-is-the-bandwidth-delay-product-185

https://networklessons.com/cisco/ccnp-route/bandwidth-delay-product/

1