\documentclass[a4paper,9pt]{article}

\author{Camil Staps\\\small{s4498062}}
\title{Networking\\\large{Assignment 2}}
\date{March 1, 2016}

\usepackage{polyglossia}
\setmainlanguage{english}
\usepackage{geometry}
\usepackage[hidelinks]{hyperref}
\usepackage{caption}
\usepackage{enumitem}
\setenumerate{label=\alph*)}

\usepackage{minted}
\setminted{fontsize=\scriptsize}

\begin{document}

\maketitle

\section{Packet loss and retransmissions}
\begin{enumerate}
  \item This is the probability that the packet arrives three times: $0.99^3=0.970299$.
    
    And analogously: $0.970299^2=0.941480149401$.
  \item The probability that a message arrives after exactly $i$ tries is $(1-0.99^6)^(i-1)$ (the probability of failure for the first $i-1$ transmissions) times $0.99^6$ (the probability of success the $i$th time. Therefore, the average number of tries is $\sum_{i=1}^\infty (1-0.99^6)^{i-1}\cdot0.99^6\cdot i=1.06216$.
  \item It takes half a second for the packet to be transmitted over one link. Over three hops this takes then $1.5s$. Since the acknowledgement has a negligible amount of data, it is transmitted in negligible time. Therefore, the client should wait at least $1.5s$ before retransmitting the packet.
  \item \begin{description}
      \item[Reliable data transfer] Yes, because packets are retransmitted when not acknowledged.
      \item[Throughput] Will be high, because packets are retransmitted when not acknowledged (and the probability of a packet arriving the first try is already quite high).
      \item[Timing] The protocol does not ensure that message segments arrive in order, or within a certain time period.
      \item[Security] The protocol does not provide confidentiality (can be sniffed), authenticity (obvious), non-repudiation (idem), integrity (no MAC or so), availability (may just DoS either end, e.g.), or authorization (again obvious).
    \end{description}
\end{enumerate}

\section{Persistent connections in HTTP}
When referring to sections in this assignment I refer to RFC 2616.
\begin{enumerate}
  \item According to 8.1.2, persistent connections are closed when a message with the \texttt{Connection: close} header is sent. According to 14.10, this can be sent both in a request and in a response, and hence by both the client and the server. From that moment, the client must not send any more requests on that connection. According to 14.10, the connection should not be considered persistent after the current request/response is complete.
  \item HTTP/1.1 does not provide any encryption services. We might expect this in section 15, Security Considerations, but nothing is said there about encryption. Typically, we would encrypt HTTP traffic by encapsulating it in an encrypted packet and sending that packet over TCP -- that is, it is not a part of the HTTP protocol.
  \item According to section 8.1.4, emphasis mine:
    \begin{quote}
      Clients that use persistent connections SHOULD limit the number of
      simultaneous connections that they maintain to a given server. A
      \emph{single-user client} SHOULD \emph{NOT} maintain \emph{more than 2} connections with
      any server or proxy. A \emph{proxy} SHOULD use up to \emph{2*N} connections to
      another server or proxy, where N is the number of simultaneously
      active users. These guidelines are intended to improve HTTP response
      times and avoid congestion.
    \end{quote}
    The restrictions are only suggestions (SHOULD, not MUST). Single-user clients should maintain at most 2 connections with any server or proxy. From this follows that proxy clients should use up to $2n$ connections with a server or proxy, where $n$ is the number of clients.
  \item Yes. From 8.1.4:
    \begin{quote}A client, server, or proxy MAY close the transport connection at any time.\end{quote}
\end{enumerate}

\section{Analysing HTTP traces}
\begin{enumerate}
  \item \url{http://gaia.cs.umass.edu/cs453/index.html} (first line and Host header).
  \item 1.1 (first line).
  \item Persistent (Connection header).
  \item English (Accept-Language header).
  \item Netscape 7.2 on Windows XP. This is useful because not every browser supports every HTML/CSS/JS feature (see e.g. \url{http://caniuse.com}). The server may then respond with workarounds for that specific browser, if needed.
  \item No, the connection has been closed because of the Connection header and according to 8.1.2 of RFC 2616, the client must not make any more requests on the same connection after this.
  \item 100968 bytes.
  \item Yes, otherwise the status code should have been 206 Partial Content and the Content-Range header should have been present.
  \item The server should respond with a 304 Not Modified status code according to section 10.3.5.
  \item According to section 10.3.5, the cache must disregard the 304 status code, and repeat the request without the If-\{Unm,M\}odified-Since and If[-None]-Match conditionals, to force a response with content.
\end{enumerate}

\section{The dig command for DNS}
\begin{enumerate}
  \item \inputminted{text}{assignment2-cs.ru.nl.dig}
  \item \inputminted{text}{assignment2-files.camilstaps.nl.dig}
  \item \texttt{dig} first fetches the root servers, then the name servers for the TLD (using the root servers), then the name servers for \texttt{ru.nl} (using the TLD name servers), and then the information of \texttt{cs.ru.nl} (using the \texttt{ru.nl} name servers).
\end{enumerate}

\section{DNS cache and database}
\begin{enumerate}
  \item \texttt{nl}, \texttt{cs.nl}, \texttt{random.cs.nl}.
  \item It is most likely that \texttt{nl} is cached. All domains under \texttt{nl} will need to use this, so it is used more than any of the other names listed above. For similar reasons, it is the least likely that \texttt{random.cs.nl} will be cached.
  \item By making a DNS request and checking what server responds. When a site has not recently been accessed, it will be its name server replying. When a site has been recently accessed, it will be some cache in between (in my case, my router, \texttt{192.168.1.1}, is caching DNS queries).
  \item The higher the TTL, the more likely it is that the record is cached, because these records will stay in the cache longer.
  \item The FQDN is \texttt{printer}, the IP \texttt{134.122.131.10}.
  \item \texttt{beta}.
  \item Using CNAME records follows the DRY principle. When moving to a different server, you will only need to edit the IP address once, in the A record.
\end{enumerate}

\end{document}

