Yu Cheng (Jade)
ICS 351
Lab Report 5 part 2
November 16, 2008
[Exercise 5A]
We connected the ethernet interfaces of PC1, PC2, and the routers. We used
command `echo "0" > /proc/sys/net/ipv4/ip_forward` to disable the IP
forwarding on both PC1 and PC2. We then used the following commands to
configure the interfaces of PC1 and PC2:
on PC1: `ifconfig eth0 10.0.1.11/24`
on PC1: `ifconfig eth1 10.0.5.11/24`
on PC2: `ifconfig eth0 10.0.2.22/24`
on PC2: `ifconfig eth1 10.0.5.22/24`
After configuring the IP addresses of the PCs, we added the default routes for
them as shown on the text book figure. We used command `route -n` to check
the existing routing entries. There were no default gateway on both PCs. We
used the following commands to add the default routes:
on PC1: `route add default gw 10.0.1.3`
on PC2: `route add default gw 10.0.2.4`
We also configured the routers using the following commands:
Router1
yourname# config t
yourname(config)# no ip routing
yourname(config)# ip routing
yourname(config)# ip route 0.0.0.0 0.0.0.0 10.0.3.2
yourname(config)# ip route 10.0.4.0 255.255.255.0 10.0.1.3
yourname(config)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.1.1 255.255.255.0
yourname(config-if)# interface fa0/1
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.3.1 255.255.255.0
yourname(config-if)# end
Router2
yourname# config t
yourname(config)# no ip routing
yourname(config)# ip routing
yourname(config)# ip route 0.0.0.0 0.0.0.0 10.0.3.1
yourname(config)# ip route 10.0.4.0 255.255.255.0 10.0.2.4
yourname(config)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.2.2 255.255.255.0
yourname(config-if)# interface fa0/1
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.3.2 255.255.255.0
yourname(config-if)# end
Router3
yourname# config t
yourname(config)# no ip routing
yourname(config)# ip routing
yourname(config)# ip route 0.0.0.0 0.0.0.0 10.0.4.4
yourname(config)# ip route 10.0.3.0 255.255.255.0 10.0.1.1
yourname(config)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.1.3 255.255.255.0
yourname(config-if)# interface Serial0/0/1
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.4.3 255.255.255.0
yourname(config-if)# end
Router4
yourname# config t
yourname(config)# no ip routing
yourname(config)# ip routing
yourname(config)# ip route 0.0.0.0 0.0.0.0 10.0.4.3
yourname(config)# ip route 10.0.3.0 255.255.255.0 10.0.2.2
yourname(config)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.2.4 255.255.255.0
yourname(config-if)# interface Serial0/0/1
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.4.4 255.255.255.0
yourname(config-if)# end
We intended to check which end of the cable (Router3 or Router4) was DCE end.
We didn't figure out where to look at first, so we used the following commands
on both Router3 and Router4.
yourname# config t
yourname(config)# interface Serial 0/0/1
yourname(config-if)# clock rate 9600
Neither of Router3 and Router4 showed any error message. We then used command
`show controllers Serial0/0/1` to check the setting. We saw that Router3 is
the DCE end the the configuration was successful. We then issued a ping and a
traceroute commands from PC1 to both of the interfaces on PC2, and from PC1 to
PC2 as well. The commands were successful.
[Exercise 5B]
We started the wireshark on PC1 interface 1 to caputure traffic between
PC1 and PC2 for this exercise. We then started a telnet session from PC1 to
PC2 using command `telnet 10.0.5.22`.
Question 3-a
For the first part of the exercise, We typed three charactors "e", "d", and
"o" at a regular speed. We observed three packets for each charactor. The
first one was a telnet data packet from the sender to the receiver. It had a
flag type [PSH, ACK]. The second one was also a telent data packet from the
receiver to the sender. It also had a flag type [PSH, ACK]. The third packet
from the senter to the receiver was a TCP session. It has a flag type [ACK].
We didn't see four packets. We didn't see an ACK for the first packet with a
payload. To reduce the number of segments, TCP combined two segments in a
delayed acknowledgement. In this case, each end waited for some time to see if
there was any data going in the same direction as acknowledgement. If it foud
one, the acknowledgement was piggybacked with the data.
Question 3-b
By observing the three sets of packets in the wireshark, We got three sets of
time intervels that the client waited before sending ACKs.
--------------------------------------------------------------------------------
Packet 3 for "e": Arrival Time: Nov 13, 2008 17:11:00.869828000
Packet 2 for "e": Arrival Time: Nov 13, 2008 17:11:00.869720000
- _________________________________
108 micorseconds
--------------------------------------------------------------------------------
Packet 3 for "d": Arrival Time: Nov 13, 2008 17:11:01.075398000
Packet 2 for "d": Arrival Time: Nov 13, 2008 17:11:01.075331000
- _________________________________
167 micorseconds
--------------------------------------------------------------------------------
Packet 3 for "o": Arrival Time: Nov 13, 2008 17:11:01.232024000
Packet 2 for "o": Arrival Time: Nov 13, 2008 17:11:01.231946000
- _________________________________
78 micorseconds
--------------------------------------------------------------------------------
TCP waited too see if there was any data going in the same direction. If there
was, the ACK can be piggybacked with the data. This was what we observed in
the second packets of each communication.
Question 3-c
We didn't get any [ACK] packets from the server, instead we got the
piggybacked echo packets with a flag type [PSH, ACK]. The time intervels are
listed as below.
--------------------------------------------------------------------------------
Packet 2 for "e": Arrival Time: Nov 13, 2008 17:11:00.869720000
Packet 1 for "e": Arrival Time: Nov 13, 2008 17:11:00.869248000
- _________________________________
472 micorseconds
--------------------------------------------------------------------------------
Packet 2 for "d": Arrival Time: Nov 13, 2008 17:11:01.075331000
Packet 1 for "d": Arrival Time: Nov 13, 2008 17:11:01.075038000
- _________________________________
293 micorseconds
--------------------------------------------------------------------------------
Packet 2 for "o": Arrival Time: Nov 13, 2008 17:11:01.231946000
Packet 1 for "o": Arrival Time: Nov 13, 2008 17:11:01.231522000
- _________________________________
424 micorseconds
--------------------------------------------------------------------------------
Question 3-d
Both the first and the second TCP segments carried typed characters as
paylaod. They had the same flag type [PSH, ACK]. They carried application
data, so they had a flag "push". They both at the same time piggybacked the
previous ACK, so also servered as the acknowledgements.
Question 3-e
--------------------------------------------------------------------------------
Packet 1 "e": Src Port: 35025, Dst Port: telnet (23), Seq: 175, Ack: 238, Len: 1
Packet 2 "e": Src Port: telnet (23), Dst Port: 35025, Seq: 238, Ack: 176, Len: 1
Packet 3 "e": Src Port: 35025, Dst Port: telnet (23), Seq: 176, Ack: 239, Len: 0
--------------------------------------------------------------------------------
Packet 1 "d": Src Port: 35025, Dst Port: telnet (23), Seq: 176, Ack: 239, Len: 1
Packet 2 "d": Src Port: telnet (23), Dst Port: 35025, Seq: 239, Ack: 177, Len: 1
Packet 3 "d": Src Port: 35025, Dst Port: telnet (23), Seq: 177, Ack: 240, Len: 0
--------------------------------------------------------------------------------
Packet 1 "o": Src Port: 35025, Dst Port: telnet (23), Seq: 177, Ack: 240, Len: 1
Packet 2 "o": Src Port: telnet (23), Dst Port: 35025, Seq: 240, Ack: 178, Len: 1
Packet 3 "o": Src Port: 35025, Dst Port: telnet (23), Seq: 178, Ack: 241, Len: 0
--------------------------------------------------------------------------------
We observed that the sequence number from PC1, the client increased by one from
every first packet to the third packet. It looks like ACK packets didn't
consume any sequence number, the same sequence number was used again for the
next packet. The relative sequence number and the hexdacimal digits for these
repeating sequence numbers were all the same. So, it won't couse confusion
because TCP re-use the previous sequence number so that there is no gap in
sequence numbers.
Question 3-f
The window size was advertised as "Window size: 5856 (scaled)" for all of the
packets from the client to the server.
Question 4-a
For the second part of the exercise, we typed in the telnet client program
very fast by holding the key. We wre missing [ACK] TCP segments from the
client to the server. We observed one telent data packet followed by one echo
and repeating in this patern. This is because the transmission was so fast
the ACKs were piggybacked onto the next application data segments.
For example, in the previous experiment we had the following time interval
between the [ACK] and the next application data segment:
--------------------------------------------------------------------------------
Packet 1 for "d": Arrival Time: Nov 13, 2008 17:11:01.075038000
Packet 3 for "e": Arrival Time: Nov 13, 2008 17:11:00.869828000
- _________________________________
205210 microseconds
--------------------------------------------------------------------------------
In this experiment, we had the following time interval between the telenet
echo pacekt and the next application data packet. It was about 10 times faster.
--------------------------------------------------------------------------------
Packet n + 1: Arrival Time: Nov 13, 2008 17:23:12.748355000
Packet n: Arrival Time: Nov 13, 2008 17:23:12.715711000
- _________________________________
32644 microseconds
--------------------------------------------------------------------------------
[Exercise 5C]
We repeated the previous exercise and observed the traffic going through a
slow link by setting the wireshark monitoring on the cooresponding interface.
Question 3-a
We observed three packets for each charactor that was typed in the telnet
client. They were the same as what we saw in the previous exercise.
--------------------------------------------------------------------------------
Packet 1 "e": Src Port: 35025, Dst Port: telnet (23), Seq: 175, Ack: 238, Len: 1
Packet 2 "e": Src Port: telnet (23), Dst Port: 53884, Seq: 238, Ack: 176, Len: 1
Packet 3 "e": Src Port: 53884, Dst Port: telnet (23), Seq: 176, Ack: 239, Len: 0
--------------------------------------------------------------------------------
Packet 1 "d": Src Port: 53884, Dst Port: telnet (23), Seq: 176, Ack: 239, Len: 1
Packet 2 "d": Src Port: telnet (23), Dst Port: 53884, Seq: 239, Ack: 177, Len: 1
Packet 3 "d": Src Port: 53884, Dst Port: telnet (23), Seq: 177, Ack: 240, Len: 0
--------------------------------------------------------------------------------
Packet 1 "o": Src Port: 53884, Dst Port: telnet (23), Seq: 177, Ack: 240, Len: 1
Packet 2 "o": Src Port: telnet (23), Dst Port: 53884, Seq: 240, Ack: 178, Len: 1
Packet 3 "o": Src Port: 53884, Dst Port: telnet (23), Seq: 178, Ack: 241, Len: 0
--------------------------------------------------------------------------------
As we typed more quickly, we observed that one segment carried more than one
keystroke of data.
--------------------------------------------------------------------------------
Packet 1: Src Port: 53884, Dst Port: telnet (23), Seq: 186, Ack: 249, Len: 2
Packet 2: Src Port: telnet (23), Dst Port: 53884, Seq: 249, Ack: 188, Len: 2
Packet 3: Src Port: 53884, Dst Port: telnet (23), Seq: 188, Ack: 251, Len: 0
--------------------------------------------------------------------------------
Question 3-b
Yes, we do oberverd delayed acknowledgments, as we typed quickly. Just like
the previous exercise, if there was data to sent to the same direction. It
waited and piggybacked onto the data segment.
Question 3-c
We observed multiple characters that were transmitted in the payload of one
segment. I've attached the data in question 3-a. This is due to the low rate
of the connection. It introduced significant delays between the client and
the server. A heuristic in TCP, called Nagle's algorithm forces the sender to
wait for an ACK after transmitting a small segment. So multiple segments were
boundled and transmitted together.
[Exercise 6A]
We started wireshark on PC1 interface 1, which monitored on the fast link
throught ethernet cables. We started a ttcp connection between PC1 and PC2
throught the fast link. We used commands:
on PC2: `ttcp -rs -l1000 -n500 -p4444`
on PC1: `ttcp -ts -l1000 -n500 -p4444 -D 10.0.5.22`
Question 4-a
--------------------------------------------------------------------------------
Packet 2 e.g 1: Arrival Time: Nov 13, 2008 17:42:51.791697000
Packet 1 e.g 1: Arrival Time: Nov 13, 2008 17:42:51.791572000
- _________________________________
125 micorseconds
--------------------------------------------------------------------------------
Packet 2 e.g 2: Arrival Time: Nov 13, 2008 17:42:51.792477000
Packet 1 e.g 2: Arrival Time: Nov 13, 2008 17:42:51.792376000
- _________________________________
101 micorseconds
--------------------------------------------------------------------------------
Packet 2 e.g 3: Arrival Time: Nov 13, 2008 17:42:51.811939000
Packet 1 e.g 3: Arrival Time: Nov 13, 2008 17:42:51.811845000
- _________________________________
94 micorseconds
--------------------------------------------------------------------------------
It looks like about 100 microseconds time interval of the ACKs from the
receiver. There were less ACKs from the receiver than the TCP segments sent.
I think this can be explained by Nagle's algorithm too. The ACKs were all to
the same direction, TCP waited and boundled some ACKs and sent them together.
Question 4-b
I randomly selected two sets of three consecutive ACKs from the wireshark data.
--------------------------------------------------------------------------------
ACK 1: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 128001, Len: 0
ACK 2: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 130001, Len: 0
ACK 3: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 132897, Len: 0
--------------------------------------------------------------------------------
Ack: 130001 - Ack: 128001 = 2000 bytes
Ack: 132897 - Ack: 130001 = 2896 bytes
--------------------------------------------------------------------------------
ACK 1: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 192001, Len: 0
ACK 2: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 194001, Len: 0
ACK 3: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 196001, Len: 0
--------------------------------------------------------------------------------
Ack: 194001 - Ack: 192001 = 2000 bytes
Ack: 196001 - Ack: 194001 = 2000 bytes
--------------------------------------------------------------------------------
One typical ACK acknowledges about 2~3k bytes of data. One TCP segment has
1000 or 1448 bytes data. So, one ACK acknowledges about two TCP segments.
Question 4-c
The window size advertised by the receiver started from "Win = 5856" in the
[ACK] packet of the three way handshake, and increased gradually to
"Win=269856" in the last [FIN, ACK] packet from the receiver to terminate the
connection.
Question 4-d
I randomly selected two examples to calculate the time intervals of a TCP
segment and it's ACK from the receiver.
--------------------------------------------------------------------------------
PC1: Src Port: 36538, Dst Port: krb524 (4444), Seq: 405001, Ack: 1, Len: 1000
Arrival Time: Nov 13, 2008 17:42:51.837470000
PC2: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 405001, Len: 0
Arrival Time: Nov 13, 2008 17:42:51.838051000
--------------------------------------------------------------------------------
17:42:51.838051000 - 17:42:51.837470000 = 581 microseconds
--------------------------------------------------------------------------------
PC1: Src Port: 36538, Dst Port: krb524 (4444), Seq: 397001, Ack: 1, Len: 1000
Arrival Time: Nov 13, 2008 17:42:51.836272000
PC2: Src Port: krb524 (4444), Dst Port: 36538, Seq: 1, Ack: 387001, Len: 0
Arrival Time: Nov 13, 2008 17:42:51.836486000
--------------------------------------------------------------------------------
17:42:51.836486000 - 17:42:51.836272000 = 214 microseconds
I took serveral hundreds of microseconds from the transmission of the segment
until the ACK arrived at the sender.
Question 4-e
No, it didn't. The maximum amount of datat in one TCP segment was 1448 bytes,
rather than the maximum amount of data allowed by the advertised window. This
maybe due to the congestion window size control. TCP tried to send as large
as it could. Apparently 1448 bytes per segment was the largest that TCP could
send.
Question 4-f
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
327 0.046173 10.0.5.22 10.0.5.11 TCP
Info: krb524 > 50900 [FIN, ACK] Seq=1 Ack=500002 Win=269856 Len=0
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
328 0.046283 10.0.5.11 10.0.5.22 TCP
Info: 50900 > krb524 [ACK] Seq=500002 Ack=2 Win=5856 Len=0
--------------------------------------------------------------------------------
After PC2 finished sending all the ACKs, it sent a [FIN, ACK] packet to PC1
requesting a termination of the connection. PC1 sent back a [ACK] packet and
the connection terminated.
[Exercise 6B]
We reconfigured the clock rate at Router3, the DCE end of the serial WAN link.
yourname# config t
yourname(config)# interface Serial0/0/1
yourname (config-if)# clock rate 125000
We repeated the previous exercise and observed the traffic going through a
slow link by setting the wireshark monitoring on the cooresponding interface,
and establishing ttcp connection on the cooresponding interface.
on PC2: `ttcp -rs -l1000 -n500 -p4444`
on PC1: `ttcp =ts -l1000 -n500 -p4444 -D 10.0.2.22`
Question 4-a
We observed a patern in which every one or two TCP segments was followed by one
ACK. In the last exercise, however, a bounch of application data TCP segments
were sent, and then a bounch of ACKs from the receiver were sent.
Question 4-b
Yes. In the last exercise we observed that one typical ACK covered about two
TCP segment. In this exercise, it seems like one ACK acknowledged the data
size of one TCP segment. I randomly picked several consecutive ACKs.
--------------------------------------------------------------------------------
ACK 1: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 18793, Len: 0
ACK 2: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 20241, Len: 0
ACK 3: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 21689, Len: 0
--------------------------------------------------------------------------------
Ack: 20241 - Ack: 18793 = 1448 bytes
Ack: 21689 - Ack: 20241 = 1448 bytes
--------------------------------------------------------------------------------
ACK 1: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 140993, Len: 0
ACK 2: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 142441, Len: 0
ACK 3: Src Port: krb524 (4444), Dst Port: 33834, Seq: 1, Ack: 143889, Len: 0
--------------------------------------------------------------------------------
Ack: 142441 - Ack: 140993 = 1448 bytes
Ack: 143889 - Ack: 142441 = 1448 bytes
--------------------------------------------------------------------------------
Question 4-c
No. The window size advertised by the receiver here looked the same as that
in the previous exercise. It started at "Win = 5856" in the [ACK] packet of
the three way handshake, and graduatly increased to "Win = 255936" in the
[FIN, ACK] packet that was sent to terminate the TCP connection.
Question 4-d
No. The maximum TCP segment is 1448 bytes as we observed from the saved
wireshark data. This might due to the congestion window control.
[Exercise 6C]
I used the wireshark dat saved in the lab. I generated four graphs and saved
them as time-sequence-stevens.png, time-sequence-tcptrace.png, rtt.png,
throughput.png.
[Exercise 7A]
The DCE clock rate was set to 125 kbps in the previous exercise. We started
the wireshark traffic on the interface 0 of PC1 to monitor the slow link
through serial WAN cable. We started a ttcp connection.
on PC2: `ttcp -rs -l1000 -n500 -p4444`
on PC1: `ttcp -ts -l1000 -n500 -p4444 -D 10.0.2.22`
Question 4
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
5 33.933589 10.0.1.11 10.0.2.22 TCP
Info: 50966 > krb524 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=7925644 TSER=0 WS=5
:
Transmission Control Protocol,
Src Port: 50966 (50966), Dst Port: krb524 (4444), Seq: 0, Len: 0
:
Options: (20 bytes)
Maximum segment size: 1460 bytes
SACK permitted
:
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
6 33.943974 10.0.2.22 10.0.1.11 TCP
Info: krb524 > 50966 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460
:
Transmission Control Protocol,
Src Port: krb524 (4444), Dst Port: 50966 (50966), Seq: 0, Ack: 1, Len: 0
:
Options: (20 bytes)
Maximum segment size: 1460 bytes
SACK permitted
:
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
7 33.944107 10.0.1.11 10.0.2.22 TCP
Info: 50966 > krb524 [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=7925656 TSER=7925251
:
Transmission Control Protocol,
Src Port: 50966 (50966), Dst Port: krb524 (4444), Seq: 1, Ack: 1, Len: 0
:
Options: (12 bytes)
NOP
NOP
--------------------------------------------------------------------------------
The sender and receiver did negotiate to permit SACKs or not. I think it said
in the las ACK in three way handshake that they didn't permit SACKs.
Question 5-a
--------------------------------------------------------------------------------
1st: [TCP Retransmission ] 41032 > krb524, Seq: 79929, Ack: 1, Len: 1448
Arrival Time: Nov 13, 2008 18:59:55.314858000
2nd: [TCP Retransmission ] 41032 > krb524, Seq: 79929, Ack: 1, Len: 1448
Arrival Time: Nov 13, 2008 19:00:03.730858000
3rd: [TCP Retransmission ] 41032 > krb524, Seq: 79929, Ack: 1, Len: 1448
Arrival Time: Nov 13, 2008 19:00:20.562855000
4th: [TCP Retransmission ] 41032 > krb524, Seq: 79929, Ack: 1, Len: 1448
Arrival Time: Nov 13, 2008 19:00:54.226865000
5th: [TCP Retransmission ] 41032 > krb524, Seq: 79929, Ack: 1, Len: 1448
Arrival Time: Nov 13, 2008 19:10:01.556548000
--------------------------------------------------------------------------------
19:00:03.730858000 - 18:59:55.314858000 = 8.416 sec
19:00:20.562855000 - 19:00:03.730858000 = 16.832 sec
19:00:54.226865000 - 19:00:20.562855000 = 33.664 sec
19:10:01.556548000 - 19:00:54.226865000 = 9 min 7.330 sec
--------------------------------------------------------------------------------
The last time interval to considerably longer than the previous one. That's
because TCP was waiting for ARP to resolve. The time that ARP requests used
didn't count in the retransmission time counting. So, the patern followed the
binary exponential backup.
Question 5-b
The maximum time we observed was a little more than 1 min. After that long
time of waitting, TCP gave up and terminated the connection.
Question 5-c
We observed 5 retransmissions in total. After the 5 retransmission while no
ACKs receiving, TCP gave up, and the sender sent out a [FIN, PSH, ACK] packet
to terminate the conneciton.
Question 6
We observed that the retransmission was different. There was one successful
retransmission. After the negociation, No SACKs were allowed.
[Exercise 7B]
We re-configured the DCE clock time to 64 kbps for this exercise.
yourname# config t
yourname(config)# interface Serial0/0/1
yourname(config-if)# clock rate 64000
We started the wireshark on the interface 0 to monitor the slow link. We used
the following commands to start the TCP conncetion between PC1 and PC2.
on PC2: `ttcp -rs -l1000 -n500 -p4444`
on PC1: `ttcp -ts -l1000 - n500 -p444 -D 10.0.2.22`
We then issued a ping command on PC1 `ping -f 10.0.2.22` to flood ICMP Echo
Recall, which would overfolw the buffers of Router3 at the serial WAN link.
Question 6-a
I save the time-sequence (stevens) graph started as
7b-retransmit-stevens.png. The graph started from a packet from PC1 to PC2.
The packets losses happened three times. It looks like the time intervals
follow the patern of the binary exponential backup.
Question 6-b
The advertised window size can be determined in the time-seqence (stevens)
graph. It increased gradually at first. Then there was the first pack drop.
The window size shrunk into half of its size. Then it tried to increase.
After the second packet drop, it shrunk to half of its size, and so on.
Question 6-c
Most of the retranmission packets were regular retransmission. There were
only two fast retransmission packets through out the wireshark file that we
saved. They oppeared at the beginning of each retransmssion section.
