TCP:

1. What is the IP address and TCP port number used by the client computer (source)
that is transferring the file to gaia.cs.umass.edu? To answer this question, it’s
probably easiest to select an HTTP message and explore the details of the TCP
packet used to carry this HTTP message, using the “details of the selected packet
header window” (refer to Figure 2 in the “Getting Started with Wireshark” Lab if
you’re uncertain about the Wireshark windows.

=> Client IP : 192.168.1.102

=> Port Number: 1161

2. What is the IP address of gaia.cs.umass.edu? On what port number is it sending

and receiving TCP segments for this connection?

=> gaia.cs.umass.edu IP : 128.119.245.12

=> Port Number : 80

3.What is the IP address and TCP port number used by your client computer
(source) to transfer the file to gaia.cs.umass.edu?

=> Client IP : 192.168.1.102

=> Port Number: 1161

4. What is the sequence number of the TCP SYN segment that is used to initiate the
TCP connection between the client computer and gaia.cs.umass.edu? What is it
in the segment that identifies the segment as a SYN segment?

=> Sequence Number of TCP SYN is 0, as it is used to initiate the TCP connection
between client and gaia.cs.umass.edu servers.
=> The flag for SYN is SET, which indicates that this segment is a SYN segment.

5. What is the sequence number of the SYNACK segment sent by gaia.cs.umass.edu

to the client computer in reply to the SYN? What is the value of the
Acknowledgement field in the SYNACK segment? How did gaia.cs.umass.edu
determine that value? What is it in the segment that identifies the segment as a
SYNACK segment?
=> The sequence number of the SYN_ACK segment sent by gaia.cs.umass.edu to the
client in
reply to the SYN is 0
=> The server adds 1 to the client’s previous sequence number of the SYN segment. For
this
case, the previous sequence number of the SYN segment from the client is 0. Thus, the
value of the acknowledgement field in the SYN_ACK segment is 1.
=> A segment will be identified as a SYNACK segment if both SYN and ACK flag are set
to 1.

6. What is the sequence number of the TCP segment containing the HTTP POST
command? Note that in order to find the POST command, you’ll need to dig into
the packet content field at the bottom of the Wireshark window, looking for a
segment with a “POST” within its DATA field.

=> Sequence Number of the TCP segment of HTTP POST is 1.

7. Consider the TCP segment containing the HTTP POST as the first segment in the
TCP connection. What are the sequence numbers of the first six segments in the
TCP connection (including the segment containing the HTTP POST)? At what
time was each segment sent? When was the ACK for each segment received?
Given the difference between when each TCP segment was sent, and when its
acknowledgement was received, what is the RTT value for each of the six
segments? What is the EstimatedRTT value (see Section 3.5.3, page 242 in
text) after the receipt of each ACK? Assume that the value of the
EstimatedRTT is equal to the measured RTT for the first segment, and then is
computed using the EstimatedRTT equation on page 242 for all subsequent
Segments.

Note: Wireshark has a nice feature that allows you to plot the RTT for
each of the TCP segments sent. Select a TCP segment in the “listing of
captured packets” window that is being sent from the client to the
gaia.cs.umass.edu server. Then select: Statistics->TCP Stream Graph-
>Round Trip Time Graph.

=>

Sequence no. Time Length RTT Estimated

RTT
1 0.023265 565 0.027460 0.027460
566 0.041737 1460 0.035557 0.028472
2026 0.054026 1460 0.073825 0.034141
3486 0.054690 1460 0.114428 0.044177
4946 0.077405 1460 0.140005 0.056155
6406 0.078157 1460 0.189645 0.072842

8. What is the length of each of the first six TCP segments?

=> 565
=> 1460
=> 1460
=> 1460
=> 1460
=> 1460
=> 1147

9. What is the minimum amount of available buffer space advertised at the received
for the entire trace? Does the lack of receiver buffer space ever throttle the
Sender?

=> 17520 Bytes

=> No, lack of receiver buffer space doesn’t ever throttle the sender.

10. Are there any retransmitted segments in the trace file? What did you check for (in
the trace) in order to answer this question?

=> No, there are no retransmitted segments in the trace file. This can be explained by
packets
with the same sequence number at different times is not found.

11. How much data does the receiver typically acknowledge in an ACK? Can you
identify cases where the receiver is ACKing every other received segment (see
Table 3.2 on page 250 in the text).
=> As you can see in the picture below, the lines selected (blue ones) have an increase in
ACK numbers :
1, 566, 2026, 3486, 4946..
=>This increase indicates that the receiver is acknowledging the bytes received: 565,
1460, 1460, 1460..
=> No, I cannot identify cases where the receiver is ACKing every other received
segment.

12. What is the throughput (bytes transferred per unit time) for the TCP connection?
Explain how you calculated this value.

Total data = last segment - first segment

= 164091 - 1
= 164090 bytes
Transmission time difference = first - last
= 5.4294 sec

Throughput = data / time

= 30222.4923 Bytes /sc

13. Use the Time-Sequence-Graph(Stevens) plotting tool to view the sequence

number versus time plot of segments being sent from the client to the
gaia.cs.umass.edu server. Can you identify where TCP’s slowstart phase begins
and ends, and where congestion avoidance takes over? Comment on ways in
which the measured data differs from the idealized behavior of TCP that we’ve
studied in the text.

=> The slow start phase begins around zero and ends around 0.13 seconds according to
the graph; after that congestion takes over. The measured data uses only a fraction of the
window size instead of the 1/3 to a half.

14. Answer each of two questions above for the trace that you have gathered when
you transferred a file from your computer to gaia.cs.umass.edu
=> The slow start phase for the following is hard to identify as there is no indication of the
exponential rise in the data packet, but from the previous subplot we can infer that its between
0 - 4.815s

=> There is no observable linear increase to comment on the congestion avoidance phase.

IP:

1. What is the IP address of your computer?

=> 10.30.57.183

2. Within the IP packet header, what is the value in the upper layer protocol field?
=> ICMP (1)

3. How many bytes are in the IP header? How many bytes are in the payload of the
IP datagram? Explain how you determined the number of payload bytes.

=> There are 20 Bytes in IP header.

=> Payload = total length – header length = 56–20 = 36 Bytes

4. Has this IP datagram been fragmented? Explain how you determined whether or
not the datagram has been fragmented.

=> This IP datagram has not fragmented. If fragmented flag is not set , then
datagram is not fragmented.

5. Which fields in the IP datagram always change from one datagram to the next
within this series of ICMP messages sent by your computer?

=> The Identification field.

=> Time To Live field.
=> Header checksum field.

6.Which fields stay constant? Which of the fields must stay constant? Which fields
must change? Why?

=> Source address , destination address, Header length, IP version remains

constant.
=> Whereas identification field, TTL , Header checksum field must change.

7. Describe the pattern you see in the values in the Identification field of the IP
Datagram.
=> Identification value is getting increased by 1.

8. What is the value in the Identification field and the TTL field?

=> The fields are 0x4563 and 6

9. Do these values remain unchanged for all of the ICMP TTL-exceeded replies sent
to your computer by the nearest (first hop) router? Why?

=> The identification field value is changed here in this file but the TTL is unchanged over
all the records.

10. Find the first ICMP Echo Request message that was sent by your computer after
you changed the Packet Size in pingplotter to be 2000. Has that message been
fragmented across more than one IP datagram?

=> Yes , it has 2 fragments.

11. Print out the first fragment of the fragmented IP datagram. What information in
the IP header indicates that the datagram has been fragmented? What information in the IP
header indicates whether this is the first fragment versus a latter fragment?
How long is this IP datagram?

=> [Frame: 204, payload: 0-1479 (1480 bytes)]

=> The flag bits for more fragments is set, indicating that the datagram has been
fragmented. Since the fragment offset is 0, we know that this is the first fragment.
=> The IP datagram is 1480 bytes long

12. Print out the second fragment of the fragmented IP datagram. What information in
the IP header indicates that this is not the first datagram fragment? Are the more
fragments? How can you tell?

=> [Frame: 205, payload: 1480-1979 (500 bytes)]

=> As this is not the first fragment, since the first fragment is 1480. It is the last fragment,
since the more fragments flag is not set.
=> The IP datagram is 500 bytes long

13. What fields change in the IP header between the first and second fragment?

=> IP header fields that changed between the fragments are : Total length, flags, fragment
offset and checksum

14. How many fragments were created from the original datagram?

=> Yes, it has 3 fragments.

15. What fields change in the IP header among the fragments?

=> The IP header fields that changed between all of the packets are: fragment
offset, and checksum. Between the first two packets and the last packet, we
see a change in total length, and also in the flags. The first two packets have
a total length of 1480, with the more fragments bit set to 1, and the last packet
has a total length of 520, with the more fragments bit set to 0.

UDP:
1. Select one UDP packet from your trace. From this packet, determine how many
fields there are in the UDP header.

=> There are total 4 fields :

Source Port ,
Destination Port ,
Length ,
Checksum.
2. By consulting the displayed information in Wireshark’s packet content field for
this packet, determine the length (in bytes) of each of the UDP header fields.

=> (56-48) bytes = 8 bytes

=> Each field has a size of 2 bytes
=> Considering each to be equal size

3. The value in the Length field is the length of what? (You can consult the text for
this answer). Verify your claim with your captured UDP packet.

=> Since the size of the header is 8 bytes and it consists of 4 fields, considering equal
distribution we can say that the size is 2 bytes each.

4. What is the maximum number of bytes that can be included in a UDP payload?
(Hint: the answer to this question can be determined by your answer to 2. above)

=> The largest possible payload source port number is 2^16 -1 = 65535
Header bytes: 8 bytes,
The possible max number of bytes in UDP payload is = 65535 - 8 = 65527 bytes

5. What is the largest possible source port number?

=> The largest possible payload source port number is 2^16 -1 = 65535

6. What is the protocol number for UDP? Give your answer in both hexadecimal and
decimal notation. To answer this question, you’ll need to look into the Protocol
field of the IP datagram containing this UDP segment (see Figure 4.13 in the text,
and the discussion of IP header fields).

=> Protocol number for UDP in decimal = 17

=> Protocol number for UDP in hexadecimal = 11.

7. Examine a pair of UDP packets in which your host sends the first UDP packet and
the second UDP packet is a reply to this first UDP packet. (Hint: for a second
packet to be sent in response to a first packet, the sender of the first packet should
be the destination of the second packet). Describe the relationship between the
port numbers in the two packets.

=> The source port of the Sending packet is the same as the destination port of the
Receiver packet.
=> The destination port of the Sending packet is the same as the source port of the
Receiver packet.

=> Source Port = 46597 , Destination port = 53

=> Source Port = 53 , Destination port = 46597