Table of Contents
2. Source and destination IP addresses in original IP datagram.. 1
3. Source and destination IP addresses in new IP header 2
4. Protocol number in the protocol field of the new IP header 2
1. SYN and ACK numbers in the SYN+ACK packet 2
2. Congestion and receive window sizes. 3
3. Sequence number of the 9th segment 3
4. Segments received successfully by the server prior to announcement 4
1. TCP congestion window size as a function of RTT based on TCP Tahoe protocol 4
2. Intervals of time when TCP Tahoe slow start is operating. 5
3. Intervals of time when TCP congestion avoidance is operating. 5
4. Values of the congestion window size and ssthresh. 5
5. Congestion window size when connection is terminated. 5
6. Congestion window size when connected is terminated if TCP Reno is used. 5
Question 1
1. IPSec datagram protocol
Following are major components of the IPSec datagram protocol:
- Outer IP header: It includes the source and destination addresses of the routers and other standard IP header fields. For instance, it contains the address of RTA and RTB.
- ESP header: This header contains information about ESP protocol. It includes sequence number, security parameter index and other details [1].
- ESP trailer: it includes authentication trailer and padding when there is use of authentication mechanism.
- Inner IP address: it contains the original source and IP address along with information about the original protocol [2].
Figure 1: IPSec datagram protocol
2. Source and destination IP addresses in original IP datagram
In the original datagram:
- Source IP address: 10.28.1.17 – It is the address of the local host located in the headquarter from which data is sent into the network system.
- Destination IP address: 10.28.2.48 – It is the original IP address of the device which is receiving the payload in IPSec communication.
3. Source and destination IP addresses in new IP header
In the new IP header:
- Source address: It is the public IP address of RTA which is 23.1.1.3.
- Destination address: it is the public IP address of the RTB which is 12.1.1.1
4. Protocol number in the protocol field of the new IP header
In new IP header, protocol number is defined according to the encapsulating security payload. Typically, it is set to 50 for this purpose [1].
5. Information and Bob
Bob can extract the outer IP header information and encapsulating header information. However, the outer source and destination address and protocol cannot be directly used to identify the target devices in the network [2]. Therefore, the Bob cannot extract the original IP datagram and its payload along with other specific details.
Question 2A
1. SYN and ACK numbers in the SYN+ACK packet
In three-way handshaking, host H is sending SYN package with sequence number and the server S sends SYN+ACK packet in reply. The server acknowledges the SYN package of the host and starts a new sequence number in response. This response of the server is acknowledged by the client by sending ACK in return [3].
In SYN+ACK packet, a random number is used as the sequence number. Suppose, the initial sequence number is 200 which is used as ACK number in SYN+ACK then at server side, it is increased by 1 and it becomes 201 [4]. The server uses a random number for acknowledge. Suppose, the ACK is 100. Here is the diagrammatic presentation of the values and three-way handshaking:
Figure 2: Three-way handshaking
2. Congestion and receive window sizes
It is given that initially, congestion window is 32KB and receive window is 20KB. Up to the eighth acknowledge, the client sends eight segments where each is of 1KB in size and server acknowledges each segment in communication. Therefore, the congestion window size is increases to maximum segment size for each acknowledgement [3]. It means, the congestion widow size becomes 40KB but the receiving window size remains unchanged at 20KB. Here is the detailed calculation for the same:
CWND after eight ACK = initial CWND + (Maximum segment size x number of ACKS)
= 32KB + (1KB x 8)
= 32KB + 8KB
= 40KB
3. Sequence number of the 9th segment
As indicated in three-way handshaking diagram, the SEQ of the ninth segment to server would be the next in the sequence where each segment is of size 1KB.
SEQ of ninth segment = Initial SEQ + (number of segments sent x Segment size)
= 100KB + (8 x 1KB)
= 100 + 8 x 1024B
= 8292
4. Segments received successfully by the server prior to announcement
The server has receiving window size of 20KB and maximum segment size is 1KB. It means the server can receive maximum 20 segments at once. If RWND is 0, it means the server cannot accept more data and it happens once the server has data in all the 20 segments. Given that the average round trip time is 200ms.
The receiving window will reset = RTT x number of segments received
= 200ms x 20
=4000ms or 4s
Therefore, the server announces RWND=0 after the forth transmission and in these forth transmission, all the 20 segments will be occupied.
Question 2B
1. TCP congestion window size as a function of RTT based on TCP Tahoe protocol
As an early congestion control algorithm, TCP Tahoe utilizes three phases: slow start, congestion avoidance and fast recovery phase [5]. For the given case, the initial slow start threshold was 16 segments and it is assumed that the maximum window size is 32 segments. Here, timeout event is occurring at 3rd RTT and 3-ACKs are occurring after 13th RTT. After 20th RTT, connection is terminated.
In beginning when RTT is 0, CWND is initially set to 1 segment due to slow start but the values increase exponentially during slow start phase, almost double. Initial slow-start threshold is 16 so that the slow-start continues until CWND becomes 16 segments and it happens near 4th RTT. After 3rd RTT, a timeout event occurs due to loss of packets so that ssthresh becomes almost half of the CWND. It becomes 8 segment and CWND becomes 1 segment. From this point, slow-start resumes [6]. Again, slow-start increases and reach a value of 8 segments around RTT 10. After that, the third phase starts and CWND grows linearly during each RTT. 3-ACK event occurs at 13th RTT. It is an indicator that network is recovering from the congestion. After this event, ssthresh is adjusted and CWND is set to ssthresh. The connection continues up to 20th RTT when connection terminated.
Figure 3: TCP congestion window and RTT
2. Intervals of time when TCP Tahoe slow start is operating
In initial phase of the connection, the internal of time occurs when TCP Tohoe slow-start is operating. It is because the congestion window is increasing exponentially, especially up to first three RTTs.
3. Intervals of time when TCP congestion avoidance is operating
It occurs after the slow-start phase and during the internal when the congestion window size increases linearly. It is the time between 4th to 13th RTT.
4. Values of the congestion window size and ssthresh
TCP Tahoe reduces the ssthresh or congestion window size to half of the current size to reach new ssthresh. For example, when three-duplicate ACKs event occurs, the congestion window size becomes half of the current window size and becomes 8 segment and ssthresh is also set to 8 segments [7].
5. Congestion window size when connection is terminated
After 20th RTT when connection terminated, the congestion window size becomes 1 segment again. The slow-start threshold was set to 16 segments initially and it decreases to 1 segment during the slow-start phase.
6. Congestion window size when connected is terminated if TCP Reno is used
The use of TCP Reno can help to prevent the drop of congestion window size to one segment after the three-duplicate ACKs event. The congestion window size will be reduced to a smaller value such as eight segments [7]. Therefore, the congestion window size will be 8 segments instead of one segment during 20th RTT when connection is being terminated.
References
- Snader, J.C., 2015. VPNs Illustrated: Tunnels, VPNs, and IPsec: Tunnels, VPNs, and IPsec. Addison-Wesley Professional.
- Kumar, J., Kumar, M., Pandey, D.K. and Raj, R., 2021. Encryption and Authentication of Data Using the IPSEC Protocol. In Proceedings of the Fourth International Conference on Microelectronics, Computing and Communication Systems: MCCS 2019 (pp. 855-862). Springer Singapore.
- Nath, P.B. and Uddin, M.M., 2015. Tcp-ip model in data communication and networking. American Journal of Engineering Research, 4(10), pp.102-107.
- Shiranzaei, A. and Khan, R.Z., 2015, March. Internet protocol versions—A review. In 2015 2nd International Conference on Computing for Sustainable Global Development (INDIACom) (pp. 397-401). IEEE.
- Taruk, M., Budiman, E. and Setyadi, H.J., 2017, October. Comparison of TCP variants in long term evolution (LTE). In 2017 5th international conference on electrical, electronics and information engineering (ICEEIE) (pp. 131-134). IEEE.
- Jasim, S.I., 2018. Old TAHOE and TAHOE Congestion Control Algorithms for TCP. Network, 1(d1), p.d1.
- Mahmood, O.S., 2018. A comparison study of TCP protocol (RENO and SACK) in WLAN, LAN networks (Doctoral dissertation, Universiti Tun Hussein Onn Malaysia).
Get solved or fresh solution on TCP/IP Questions and many more. 24X7 help, plag free solution. Order online now!
