# 4th Assignment Group: Monday 2-4 - Group 1 Ana Tomi: 413117 Fabian Wagner: 349330 Lukas Hoffmann: 415442 Yasin Kilic: 371955 ## Question 1: Relationship between bandwidth and window size ### a) Assuming a bandwidth ofR= 32 Kibit/s, what is the propagation delay between sender andreceiver? Note: You can round to full milliseconds. a packet without payload has a length of L = 40byte = 320bit bandwith R = 32Kibit/s = 32768bit/s transmission delay = L/R = 320bits / 32768bit/s = 9.8ms According to our RTT of 60ms and 30ms for half of the way minus the transmission delay we have 30ms - 9.8ms = 20.2ms as the propagation delay. ### b) Assuming the propagation delay remains the one computed in a) and given a bandwidth of R= 32 Kibit/s, what is the window size maximizing the link utilization while still avoiding loss? For the Maximum Segement Size the RTT is 302ms. The transmission delay for 536B is 536B / 4096B/s = 0.131s This times two plus two times the propagation delay of 20.2ms is 302ms The ideal Window Size is calculated by w* = RTT x Bandwith = 0.302s * 32Kibit/s = 10Kibit The window size maximizing the link utilization while still avoiding loss is 10Kibit. ### c) Assuming the propagation delay remains the one computed in a), how does the optimal windowsize (for maximum utilization) change if bandwidth increases? Compute the optimal window size for i)R= 100 Kibit/s, ii)R= 1 Mibit/s, iii)R=10 Mibit/s. i) w* = RTT x Bandwith = 0.302s * 100Kibit/s = 31Kibit The optimal window size is 31Kibit. ii) w* = RTT x Bandwith = 0.302s * 1Mibit/s = 0.302Mibit = 310Kibit The optimal window size is 310Kibit. iii) w* = RTT x Bandwith = 0.302s * 10Mibit/s = 3.02Mibit = 3093Kibit The optimal window size is 3093Kibit. If the bandwith increases the optimal windo size increases linear to the bandwith. ## Question 2: Parallelizing TCP Connections ### (a) What is the advantage of using parallel connections for the server, rather than sending the whole file in a single TCP connection? - reliable delivery of every single packet - if a packet get lost, it can be resent without much data flow - the server dont use the whole bandwith for n packets ### (b) What is the disadvantage of using parallel connections for the server, rather than sending the whole file in a single TCP connection? - much traffic (SYN, ACK, FIN) for every connection between server and client - the server must keep alive the n connections to the host until the packts are received ### (c ) Assume that there are other TCP connections in the network which are not between our server and client. How does using parallel connections between our server and client impact the other TCP connections? By using multiple parellel TCP connections the traffic becomes even more bursty then usual. The available bandwith on the common part of the connections is then shared between more connections and the connection can be slower for the other connection. In the worst case scenario it lead to packets beeing droped or so slow that the timeout runs out. ## Question 3: TCP Traffic Analysis ### (a) In Wireshark, start a traffic capture on your local network interface #### How many packets do you get in total? During the whole capture run I got a total of 157 Packets that were captured. 62 of hat the IP Adress of "researchvm.inet.tu-berlin.de" ( either in the Source or Destination field). `Displayfilter: ipv6.addr == 2001:638:809:ff13:130:149:221:201` #### How many of them contain TCP? From the total 157 packets 129 contained TCP Packets. `Displayfilter: tcp` Of the 62 packets going to the IP of researchvm.inet.tu-berlin.de all 62 were TCP packets `Displayfilter: TCP && ipv6.addr == 2001:638:809:ff13:130:149:221:201` #### How many of them contain HTTP/1.1? Six of them contain HTTP/1.1 `Displayfilter: tcp && http.request.version == "HTTP/1.1"` ### (b) Now set a display filter to show only packets that correspond to a single TCP connection of your web page request and response. There are two different ways to do this with wireshark. Wireshark has a build in function to follow a single tcp connection. It is documented here: https://www.wireshark.org/docs/wsug_html_chunked/ChAdvFollowStreamSection.html When i use that on one of the packets the display filter that Wireshark generates is the following: `Displayfilter: tcp.stream eq 3` That filters out the third tcp stream found in the trace. The number has no deeper meaning besides that. Another way of filtering out destinct packets that belong to a single connection it by the four parameters source IP and Port and destination IP and Port. `Displayfilter: (tcp.port == 80) && (tcp.port == 51610) && (ipv6.addr == 2001:638:809:ff13:130:149:221:201) && (ipv6.addr == 2a02:8109:9ac0:3bfc:a568:15d9:966a:73f4)` ### (c ) Analyze the obtained data by marking packets belonging to: the TCP connection setup, the transmission of the HTTP request, the transmission of the HTTP response, the tear-down of the connection. ![](https://i.imgur.com/9hw43K1.png) * TCP connection setup -> Green * Transmission of the HTTP request -> Orange * Transmission of the HTTP response -> Blue (including the tcp packet where the http response is included in) * Tear-down of the connection ### (d) Start a new traffic capture and load the pagehttp://inet.tu-berlin.de. #### Set a display filter for DNS, and find the queries for inet.tu-berlin.de. What records does the browser ask for, and what replies does it get? | Request | Response | | -------- | -------- | | inet.tu-berlin.de: type A | Address: 130.149.220.241| | inet.tu-berlin.de: type AAAA | AAAA Address: 2001:638:809:ff11:130:149:220:241| | ocsp.pca.dfn.de: type A | Address: 193.174.13.86| | ocsp.pca.dfn.de: type AAAA | AAAA Address: 2001:638:714:2809:3::7| | www.inet.tu-berlin.de: type A | Address: 130.149.7.202| | www.inet.tu-berlin.de: type AAAA | type SOA, mname dns.inet.tu-berlin.de #### Click on one of the DNS replies, remove the DNS display filter again, and look at the packets coming afterwards to and from one of the IP addresses associated with inet.tu-berlin.de. What TCP connections do you see? After the DNS query response for the AAAA record for inet.tu-berlin.de follows a TCP connection setup and a HTTP GET / request. The answer to that request is a also an HTTP packet with the status code 302 in there refering to the https side. The client then opens another tcp connection. this time to port 443 instead of 80 and shortly after initiates a dns query about ocsp.pcs.dfn.de #### What can you see in them, and what can you not see? Why? The requests that follow after the first request to port 443 are the TLS handshake. The DNS query for ocsp.pcs.dfn.de is part of that OCSP stands for "Online Certificate Status Protocol" and the request is made to check the validity of the certificat that inet.tu-berlin.de provides. The traffic that follow after that is the ocsp request to check the certificate. After that the connection is switched to a encrypted connection using TLS 1.2. The traffic following that is just encrypted giberish. The actual payload can't be inspected without the encryption key.