Laboration 1 in DT151G - Data and Computer Communications,

with Applications in Linux

Table of Contents
Introduction .................................................................................................................................................. 3
Environment & Tools .................................................................................................................................... 3
Purpose ......................................................................................................................................................... 3
Part 1: Methodology ..................................................................................................................................... 3
nslookup miun .......................................................................................................................................... 3
DNS gaia .................................................................................................................................................... 5
nslookup cs.umass.edu ........................................................................................................................... 11
UDP ......................................................................................................................................................... 12
Part 2: Methodology ................................................................................................................................... 18
TCP Basics................................................................................................................................................ 19
TCP and Congestion Control ................................................................................................................... 25
Part 1: Results ............................................................................................................................................. 26
nslookup miun ........................................................................................................................................ 26
DNS gaia .................................................................................................................................................. 26
nslookup cs.umass.edu ........................................................................................................................... 27
UDP ......................................................................................................................................................... 28
Part 2: Results ............................................................................................................................................. 29
TCP and HTTP .......................................................................................................................................... 29
TCP and Congestion Control ................................................................................................................... 30
Part 1: Discussion ........................................................................................................................................ 33
nslookup miun ........................................................................................................................................ 33
DNS gaia .................................................................................................................................................. 34
nslookup cs.umass.edu ........................................................................................................................... 34
UDP ......................................................................................................................................................... 37
Part 2: Discussion ........................................................................................................................................ 37
TCP and HTTP .......................................................................................................................................... 37
TCP and Congestion Control ................................................................................................................... 38
References .................................................................................................................................................. 40
Introduction

Environment & Tools

Operating system: Ubuntu

Wireshark version: 3.6.0

Purpose
The purpose of this assignment was to use Wireshark to capture and examine network data in a Linux
environment, as well as to search and resolve domain names and IP addresses for web- and DNS servers
using the nslookup command in the Linux terminal.

Part 1: Methodology

nslookup miun
Question 1-3 were answered by using the nslookup command on www.miun.se to determine the IP
address of the Miun webserver.

Figure 1: Shows the IP address of the local DNS server (at the top) and the IPv4 and IPv6 addresses of the Miun
webserver (at the bottom of the picture).
Question 4a was answered by using the “type=NS” option together with nslookup. And (for two of the
students) the cloudflare DNS resolver 1.1.1.1.

Figure 2: Shows the name of the authoritative DNS name server.

Question 4b was answered by using the nslookup command on the name of the authoritative DNS name
server for the Miun domain.

Figure 3: Showing the authoritative DNS name server of miun domain.

Question 5 was purely theoretical in nature.

DNS gaia
Question 1-3 were answered by clearing the local DNS cache, as well as the cache in the browser, and
then using Wireshark to capture and inspect the DNS messages (queries and response) sent by opening
the web page http://gaia.cs.umass.edu/kurose_ross/ in Firefox.

Figure 4: Showing the DNS packet sent to gaia.cs.umass.edu.

Question 4 was answered by looking at the destination address of the DNS query message shown below.

Figure 5: Showing the destination IP address to gaia.cs.umass.edu.

Question 5 was answered by looking at the number of questions and answers in the DNS query
message.

Figure 6: showing the DNS query message’s amount of questions and answers.
Question 6 was answered by looking at the number of questions and answers in the response to the
DNS query message.

Figure 7: showing the DNS response message’s amount of questions and answers.
Question 7 was answered by examining the packet numbers of HTTP requests, as well as DNS queries
and responses seen in the pictures below.

Figure 8: shows the starting packet number for GET HTTP request of base page at gaia.cs.umass.edu.
Figure 9: Show the initial packet number of the GET HTTP request of the image at gaia.cs.umass.edu.
nslookup cs.umass.edu
Questions 8-10 were answered by examining the DNS query message. This is shown in the following
image.

Figure 10: Shows the destination, IP address and the type of DNS query.

Question 11 was answered by examining the DNS response message. This is shown in the following
image.

Figure 11: Shows the response message of DNS.

UDP
Question 1 was answered by selecting the packet and looking at the DNS segment, as shown in the
following image. Question 2 was answered by selecting each of the fields and looking in Wireshark’s
data section.

Figure 12: The packet of DNS segment.

Question 3 was answered by selecting the UDP header and DNS header in Wireshark to examine their
lengths in the packet content field. The UDP segment was 8 bytes and was immediately followed by the
38 bytes of the DNS message. This is 46 bytes in total, the same value as in the UDP Length field. The
selection is shown in the following two images.

Figure 13: length field of UDP packet 1.

Figure 14: length field of UDP packet 2.

The answer to question 4 was calculated as following.

Assuming that the UDP Length value is the only constraint, a maximum number of bytes for a
UDP payload can be calculated by subtracting the largest possible Length value from the UDP
header length.

largest possible UDP payload = largest possible UDP Length value - UDP header length

The UDP Length value is stored in 2 bytes which is equal to 16 bit. 16 bit can store 2 16 = 65 536
different numbers, giving a max value of 65 535 assuming 0 is one value.

largest possible UDP Length value = 65 535

The UDP length is always 4 fields of 2 byte = 8 byte. This can simply be subtracted from the max
value because the unit of the UDP Length value is byte.
 UDP header length = 8

largest possible UDP payload = 65 535 - 8 = 65 527 byte

In reality there are other additional constraints that lower this number, like the maximum size
of the link-layer frame that can be transmitted by the local host (maximum transmission unit,
MTU).

In question 5, the source port field in the UDP segment was selected to see the number of bytes
used for its storage, as seen in the following image. The max value was calculated by knowing
that 2 byte = 16 bit, and 2 bit can store 216 = 65 536 different numbers, giving the max value 65
535 assuming 0 is one value.

Figure 15 Size of maximum source port field.

Question 6 was answered by looking in the IP header to find the protocol field, as shown in the
following figure.

Figure 16: Showing UDP protocol number.

Question 7 was answered by looking in the UDP header of both packets to find the source ports.
The following two figures shows the packets.

Figure 17: Showing source port number of UDP request message.

Figure 18: Showing source port number of UDP response message.

Part 2: Methodology
SYN, introduction to part 2

Question 1-2 were answered by looking in Wireshark at the UDP header, shown in the following figure.

Figure 19: Showing IP address and TCP port number of client computer and gaia.cs.umass.edu.
TCP Basics
Question 3 was answered by looking in the UDP header of the same packet in Wireshark, as shown in
the following image.

Figure 20: Showing the (raw) sequence number.

Question 4 was answered by looking in the UDP header of the reply packet in Wireshark, as shown in
the following image.

Figure 21: The sequence number of the SYNACK segment.

Question 5 was answered by looking at the TCP header of the segment containing the HTTP POST
command, shown in the following image.

Figure 22: The sequence number of the TCP segment containing the header of the HTTP POST request.

Question 6 was calculated as following.

According to the Arrival Time field in the packet’s Frame section, the first HTTP segment was
received at the following time:

Arrival Time: Feb 3, 2021 03:43:26.716922000 W. Europe Standard Time

The ACK message for this segment was found by searching for the relative acknowledgment
number, which matches the ”next sequence number” in the segment that was responded to.
The ACK message was received at:

Arrival Time: Feb 3, 2021 03:43:26.745546000 W. Europe Standard Time

The RTT for the first HTTP segment was determined to be the time difference of the packet
transmission and arrival of the ACK message: 0.028624s. The RTT of the second HTTP segment
was calculated using the relative capture times of it and its ACK message (packets number 5
and 8): 0.052676 - 0.024048 = 0.028628s. (These values can also be found in the TCP segment
section [SEQ/ACK analysis].)

The estimated RTT after the second HTTP segment transmission/acknowledgment is calculated
using the following formula, taken from the course literature:

EstimatedRTT = (1 - α) · EstimatedRTTp + α · SampleRTT

The value of α is given in the assignment. SampleRTT is the measured RTT for the second
segment, while EstimatedRTTp is the measured RTT for the first segment:

α = 0.125

EstimatedRTTp = 0.028624

SampleRTT = 0.028628

The calculation was thus performed in the following manner:

EstimatedRTT = (0.875 · 0.028624) + (0.125 · 0.028628) = 0.0286245 = 0.028625s

For question 7, the length of the first four data-carrying TCP segments were read from the
outgoing HTTP packet, shown in figure 23 below.

Figure 23: Showing the payload of each of the first four data-carrying TCP segments.
Question 8 was performed as following.

The available buffer space reported by a server response segment was calculated with the given
formula in the lab document:

BufferSpace = WindowSize · WindowScalingFactor

The packet numbers of the server responses to the first four TCP segments were 7, 8, 13, 16.

Initially, there was some confusion about which field to select out of the TCP fields “Window”
and “[Calculated window size]”, until it was noticed that the “[Calculated window size]” was the
product of the other two values. An example of these fields in packet 7 is shown at the bottom
of Figure 24.

Figure 24: Some UDP fields in packet 7, the fields related to window size at the bottom.

The calculations were done regardless of the observed product to ensure correct procedures
and understanding.

The calculated buffer spaces in the server responses to the first four data-carrying TCP
segments were as following, which was consistent with the values in the “[Calculated window
size]” fields:

249 · 128 = 31 872 bytes

272 · 128 = 34 816 bytes

295 · 128 = 37 760 bytes

317 · 128 = 40 576 bytes

The minimum amount of available buffer space among the first four TCP segments was thus the
first value: 31 872 bytes.

Question 9 was performed as following.

A search for retransmitted segments in the trace was done by using the filters

tcp.analysis.retransmissions

and

tcp.analysis.retransmissions || tcp.analysis.ack_lost_segment

To ensure that the filters work, they were tested on a new live trace, and they did capture a few
TCP retransmissions.

Some searching was also done by manually scrolling through the list and looking for packets
with tags including words like “duplicate” and “retransmission”.

The method for question 10 was done as following.

The number of outgoing packets that were acknowledged in each of the first 10 ACK messages
was found by reading the TCP header field ”[SEQ/ACK analysis]” of each ACK, while manually
keeping track of which segments had already been acknowledged. The ”[SEQ/ACK analysis]”
field contained a link to a segment that it responded to, as shown in figure 25 of packet 7.

Figure 25: The “[SEQ/ACK analysis]” field in packet number 7, showing a segment it is acknowledging.

The 10 first ACK segments had packet numbers 7-8, 13, 16-19, 28-29, 34, and 37.
Question 11 was performed as following.

The average throughput was calculated by taking the size of the reassembled TCP segments and
dividing it by the total time of the transmission.

According to the outgoing HTTP packet, the file is 153 425 byte and is transmitted in 106
packets of number 4 to 153. The relative time of transmissions/receptions of the packets
number 4 and 153 were 0.024047 s and 0.147682 s. This data is used to calculate the average
throughput as following:

Throughputav = Data / (Timelast - Timefirst)

= 153 425 / (0.147682 - 0.024047) = 1 240 951 byte/s = 1.24 Mb/s

TCP and Congestion Control

The methodology for questions 12-13 is presented together with the result because the
thought process is relevant for the discussion type of questions.
Part 1: Results
The results to some questions were different for each student for natural reasons, for example port
numbers of the computer used for the lab, and IP addresses of home routers. Only one of the variants in
such cases is presented in the result. The values in the figures presented in the methodology section
may also differ from the results for this reason.

nslookup miun
Question 1

The IPv4 addresses for Miun's webserver are 104.18.0.138 and 104.18.1.138.

The IPv6 addresses for Miun's webserver are 2606:4700::6814:18a and 2606:4700::6814:8a.

Result Question 2

The IP address of the DNS server that provided the answer when using Linux was 127.0.0.53.

Result Question 3

The answer to the nslookup command came from a non-authoritative server.

Result Question 1.4a

The name of the authoritative DNS name server was ns1.cloudflare.net.

Result Question 1.4b

To find the IP address of the authoritative name server, an nslookup could be performed on the name of
the server, the same way as for a regular domain name like www.miun.se.

Result Question 1.5

A reverse DNS lookup is the reverse of an ordinary DNS lookup: looking up the host name by an IP
address.

2 DNS gaia
Many of the answers in this section were different between students for natural reasons explained in
the discussion section. To be able to present specific answers, an example image from a single student
was chosen for the report.

Result Question 2.1

The packet number of the first DNS query message was 1. The message was sent using UDP.

Result Question 2.2

The packet number of the DNS response message was 3. The response message was sent using UDP.

Result Question 2.3

The destination port of the DNS query was 53. Same as the source port of the DNS response.

Result Question 2.4

The DNS query message was sent to the IP address 192.168.64.1.

Result Question 2.5

The DNS query message contained 1 question and 0 answers.

Result Question 2.6

The DNS response message contained 1 question and 1 answer.

Result Question 2.7

The packet number of the initial HTTP GET request for the base HTML file was 40. The DNS
query/response message used to send this HTTP request were the initial DNS messages to resolve the
host name gaia.cs.umass.edu. No other DNS messages for this host name were sent. The packet
numbers were 5 and 8 for the IPv4 address (type A record). The packet number of the HTTP GET request
for the header image was 348, and the response was number 574.

nslookup cs.umass.edu
Result Question 2.8

The destination port of the DNS query was 53. Same as the source port of the DNS response.

Result Question 2.9

The DNS query message is sent to IP address 192.168.64.1, which is the home router. This is not the IP
address of the default local DNS server.

Result Question 2.10

The DNS query was of type A. The query did not contain any answers.

Result Question 2.11

The DNS response contained 1 question and 1 answer. The question field data was identical to the
question in the query message. The answer contained the IPv4 address for the specified hostname.

Result Question 2.12

The destination IP 192.168.64.1 was the home router, same as in the previous question number 9.

Result Question 2.13

The DNS query message contained 1 question and 0 answers.

Result Question 2.14

The DNS response message had some differences between students (see discussion).
The response message contained 3 answers with information about each of the 3 authoritative name
servers, such as their name, type (NS), and cache info (time to live). This section was the same for all
students. However, the number of additional resource records varied between 1 and 3 in the different
versions between students.

The version with a single additional <root> resource record contained information about UDP payload
size and DNSSEC security, among other things. The version with three additional resource
records contained type A records for each of the authoritative name servers. Their IPv4 address was
included here, which was completely missing in the other version.

3 UDP
Result Question 3.1

The first UDP segment had the packet number 1. The application-layer protocol message carried in the
segment was a DNS query message for a type NS record. The UDP header had four fields: source port,
destination port, length, and checksum.

Result Question 3.2

The Wireshark packet content field shows that each of the UDP header fields is 2 bytes, which are
displayed as four hexadecimal digits.

Result Question 3.3

The UDP Length header specifies the total length of the UDP segment, including the application-layer
payload. This was verified by selecting the UDP segment and DNS message in Wireshark to examine
their lengths in the packet content field. The UDP segment was 8 bytes and was immediately followed
by the 38 bytes of the DNS message. This is 46 bytes in total, the same value as in the UDP Length field.

Result Question 3.4

Theoretically, the maximum number of bytes that can be included in a UDP payload is 65527 bytes.

Result Question 3.5

The largest possible source port number is thus 65 535.

Result Question 3.6

The IP Protocol number for UDP is 17.

Result Question 3.7

The Wireshark packet numbers of the UDP packet pair were 1 and 2. The port numbers were the same
but flipped in the second packet. The first packet had the source port 40647 and destination port 53.
The second packet had the opposite ports. This shows that the client host port is 40647 and the server
port is 53.
Part 2: Results

4 TCP and HTTP

Result Question 4.1

The IP address and TCP port number used by the client computer was 192.168.86.68 and 5639
respectively.

Result Question 4.2

The IP address of gaia.cs.umass.edu is 128.119.245.12. It's sending and recieving on port number 80.

Result Question 4.3

The first TCP SYN segment has the (raw) sequence number 4236649187. It is identified as a SYN segment
by the SYN bit in the flag field.

Selective acknowledgments will be used according to one of the fields in the Options section ”TCP
Option - SACK permitted”. This is shown in the image.

Selective acknowledgment is when the receiver acknowledges and buffers out-of-order segments
despite being out of order [4].

Result Question 4.4

The sequence number of the SYNACK segment is 1068969752. The segment is identified as a
SYNACK segment by the SYN and ACK flags being set in the TCP header. The value of the
acknowledgment field is 4236649188. This is the sequence number of the next TCP segment
the server expects to receive.

Result Question 4.5

The sequence number of the TCP segment containing the header of the HTTP POST request was
4236649188. The data field containing the TCP payload was 1448 bytes, which is only a small part of the
file. As seen in the HTTP POST message, the data was transferred in 106 separate segments.

Result Question 4.6

The first segment in the data-transfer part of the TCP connection was sent at 0.024047s. The ACK for the
first data-containing segment was recieved at 0.052671s. The RTT for the first data-containing segment
was 0.028624s. The RTT value of the second data-carrying TCP segment and it's ACK was 0.028628s. The
EstimatedRTT value after the ACK from the second data-carrying was recieved was 0.0286245s

Question 4.7
The length of each of the first four data-carrying TCP segments was 1448 bytes.

Question 4.8

The minimum amount of available buffer space advertised to the client was 31 872 bytes. No throttling
due to lack of buffer space occurred.

Question 4.9

No retransmitted segments were found in the trace file.

Question 4.10

The receiver acknowledged 1448 bytes in each of the first 10 ACK messages.

Question 4.11

The average throughput for the TCP connection while transmitting the file was 1.24 Mb/s.

TCP and Congestion Control

Question 4.12

To analyze the plot, it is useful to count the number of packets sent in each “pulse”. Packets outside the
large stacks were counted to the following stack:

• t = 0.025: 3 (+1) packets

• t = 0.053: 6 packets
• t = 0.082: 12 packets
• t = 0.1: 4 + 20 packets

The number of sent packets seems to double each pulse, and the plot looks to increase exponentially
overall. This seems like the TCP slow-start phase, which is typically used at the start of a TCP connection.
The TCP slow-start phase doubles the sending rate after each RTT when no congestion is encountered.
[1 p 266-267]

In summary, the graph looks like TCP in it’s slow start phase.

Question 4.13

The graph seems to be following a regular periodicity.

To speak about the periodicity of the “pulses” of packets it is useful to calculate the periods. The periods
between each major pulse of packets are calculated as the difference between the highest points of
each subsequent tallest stack:

• P0 = 0.02405 - 0 = 0.02405 s
• P1 = 0.05285 - 0.02405 = 0.02880 s
 • P2 = 0.08093 - 0.05285 = 0.02808 s
• P3 = 0.1055 - 0.08093 = 0.02457 s
• P4 = 0.1326 - 0.1055 = 0.0271 s

A hypothesis to explain the periodicity of the plot is that the usage of the slow-start phase for
transmission congestion control results in the pulses of packets. Differences in transmission times create
irregularities that propagate to the following pulses. The figure 26 below is used to illustrate the
explanation.

When a number of packets are sent simultaneously in the very initial pulse (3-4 packets), the ACKs also
arrive around the same time, triggering the client to continue transmitting data in pulses due to using
the slow-start phase. This is supported by the doubling of number of packets in each pulse, as shown at
the top of the plot in figure 26.

At the 4th pulse (24 packets), four packets are transmitted out of sync for some reason, highlighted as
area A in figure 26, perhaps because of different arrival times of the previous client-transmitted packets
or the received ACKs. This could have been caused by very brief network congestion or packets being
sent over different network paths with different throughputs. This irregularity propagates to the
following pulses, highlighted as areas B and C. Some of the packets in these areas may of course also be
the result of new differences in transmission times. If the transmission would have continued, it is likely
that more inconsistencies would have appeared, the pulse becoming increasingly fragmented and
chaotic.
Figure 26: The sequence-number-versus-time plot (Stevens format) of the TCP segments in the given trace, with
number of packets per pulse specified and areas of irregularities highlighted.

To preserve objectivity and consistency, the areas of each pulse in figure 26 were defined so
that packets outside the big stacks always belong to the following big stack. This decision was
made because the produced pattern illustrates the hypothesis.

Question 4.14

The questions 12 and 13 for the given trace file have been answered above.
Part 1: Discussion

1 nslookup miun
Discussion Question 1

There was some discussion about whether we should include IPv6 addresses in the answer. In the end
we decided in favour of this because it’s an important technology and seemed relevant. It was also
interesting to note that using nslookup on miun.se without “www” resulted in a completely different
result.

Figure 27: Showing different result of nslookup of miun.se

It was also observed that the IP addresses were received in different orders between students. There
was an agreement that this was caused by the website being hosted on several servers for load
distribution, and the IP addresses were rotating to distribute the traffic which is a typical technique.

Discussion Question 2

There was some confusion about the responding DNS server IP address 127.0.0.53 and what it referred
to because it was the same for everybody. In the end we came to agree that it was not the local DNS
server but a part of the function of the Linux operating system: “127.0. 0.53 is the address of the local
caching stub resolver. It forwards DNS requests to whatever upstream DNS servers you specify. Also
good to note here, is that by default systemd-resolved caches DNS responses.”[2]

Discussion Question 4a

The authoritative DNS server name could not be found with nslookup when using a virtual operating
system without specifying the Cloudflare DNS resolver as in the command “nslookup
www.miun.se 1.1.1.1” [3]. Without this final argument, the field following “Authoritative answers can be
found from” was always empty. The problem didn’t occur when performing the nslookup on a non-
virtual OS.
DNS gaia
Discussion Question 2.1 - 2.2

The packet numbers of the DNS messages varied between students, in the range 1-5 for the query
message and 3-8 for the response message. There was a discussion about the cause for the difference,
and the conclusion was that it was likely the result of some other web traffic being captured before the
request for the gaia.cs.umass.edu website had been sent, because the DNS request and reply should
precede any TCP traffic for the requested webpage.

Discussion Question 2.4

The destination IP address varied between students but had similar numbers: 192.168.0.1, 192.168.10.1,
192.168.64.1. This was determined to be the home router of each student.

Discussion Question 2.7

We discussed the reasons why the DNS query and response messages did not appear to have to be
resent in order to resolve gaia.cs.umass.edu before sending the HTTP request for the image. It could be
seen in Wireshark that once the DNS service had resolved the host IP, two TCP connections were
established from the lab computer to the host’s IPv4 address with SYN and “[SYN, ACK]” messages. Both
the HTTP file and the referenced objects were then transmitted over the same connection. It seems like
the host IP is only resolved one time for all the objects referenced by the webpage, and the IP is cached
on the local machine while the TCP connection between the browser and web server is running.

nslookup cs.umass.edu
Discussion Question 2.8

We observed that the DNS server port (53) was the same for everybody. We agreed that this is because
it is a standard port number for DNS servers defined by IANA. [5]

Discussion Question 2.14

There was some confusion about why there were 2 different versions of the DNS response message
between students, with completely different numbers and contents of the additional records. At first it
was assumed that a mistake has been made for one of the versions, but this was disproven after
inspecting the information.

When checking the terminal nslookup results for the two versions it became clear that version 2
had received the authoritative servers while version 1 had not. The nslookup results and their associated
packet info is shown below. All students had used the same nslookup command on a virtual operating
system, so we assumed that the cause for this could be some settings in the operating system or DNS
settings from the ISP, for example the ISPs using different DNS resolvers.
Figure 28: Version 1 of the DNS response message from the nslookup of type NS.

Figure 29: The nslookup result of the version 1 type of the DNS response message.
Figure 30: Version 2 of the DNS response message from the nslookup of type NS.

Figure 31: The nslookup result of the version 2 type of the DNS response message.
UDP
Discussion Question 4

The largest possible calculated UDP payload was 65 527 byte. In reality there are other additional
constraints that lower this number, like the maximum size of the link-layer frame that can be
transmitted by the local host (maximum transmission unit, MTU).

Discussion Question 5

There was nothing to discuss for this question.

Discussion Question 7

It was observed that the source port number was different for each student. It was agreed that this is
caused by the socket on each client host generating a random socket number that is not already used
for another connection.

Part 2: Discussion

TCP and HTTP

Discussion Question 3

There was nothing to discuss for this question.

Discussion Question 4

The SYNACK segment has the sequence number 1068969752. This is a completely different number than
the SYN sequence number because it was generated by the server(?). The segment is identified as an
SYNACK message by the SYN and ACK bits in the flag field, which gives the flag value 0x012 (= 0001
0010).

The packet’s acknowledgement number is 4236649188. As with other response packets, this number is
derived from the sequence number of the packet it responds to, which in this case was 4236649187
(one unit lower). Simple SYNACK messages (that are not piggybacking on a packet with a data payload)
increment the number by 1.(?) The data about the SYNACK segment can be seen in the image below.

Discussion Question 5 - 6

There was nothing to discuss for these questions.

Discussion Question 7

All data-carrying TCP segments were found to have the same segment length of 1448 byte
apart from the very last one which was 1385 bytes. There was an agreement that the limitation
of 1448 bytes was likely caused by limitations in the link layer such as the Ethernet protocol, or
some other protocol layer.

Discussion Question 8

It was clearly observed that window size increased in each server response. The explanation
that was agreed upon was that it was the result of bandwidth probing, a part of the TCP self-
clocking behavior. When a TCP data transmission (either from the client or server side)
experiences no packet loss, this is interpreted as the path not being congested. The receiver
increases its window size to use more of the available network bandwidth. [1, p. 264-265]

Another observation was that all of the 3 fields related to window size were represented by the
value “00 f9” in Wireshark’s data field. These fields are shown again in figure 32 below. The “00
f9” hexadecimal value is equal to the decimal value 249, indicating that only the window
field/value pair was transported in the packet, and not [Calculated window size] or [Window
size scaling factor]. This would mean that the values in brackets are calculated locally by the
Wireshark software.

Figure 32: The fields related to window size in packet 7.

TCP and Congestion Control

Discussion Question 11

The discussion of this question is included in the result section because of the nature of the question.

Discussion Question 12

The discussion of this question is included in the result section because of the nature of the question.

Discussion Question 13
We were a bit unclear about how to interpret the question, but our understanding was that the pattern
of pulses was probably caused by the TCP slow-start phase. There was an agreement that the detailed
explanation proposed by one student made sense, although we could not be sure if it was 100% correct.
References
[1] James F. Kurose, Keith W. Ross. Computer Networking: A Top-Down Approach. 8th Edition. Pearson
2021.

[2] Ask Ubuntu, “DNS set to systemd's 127.0.0.53 - how to change permanently?”, March 6th 2019
[Online]. Available: https://askubuntu.com/questions/1012641/dns-set-to-systemds-127-0-0-53-how-
to-change-permanently

[3] Cloudflare, “What is 1.1.1.1?” [Online]. Available: https://www.cloudflare.com/en-

gb/learning/dns/what-is-1.1.1.1

[4] Packet Life, “TCP Selective Acknowledgements (SACK)” [Online]. Available:

https://packetlife.net/blog/2010/jun/17/tcp-selective-acknowledgments-sack/

[5] IANA, “Service Name and Transport Protocol Port Number Registry”, November 24th 2021 [Online].
Available: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-
numbers.xhtml?&page=2