diff --git a/year4/semester2/CT420/materials/7. Soft RTS.pdf b/year4/semester2/CT420/materials/7. Soft RTS.pdf new file mode 100644 index 00000000..d64b254b Binary files /dev/null and b/year4/semester2/CT420/materials/7. Soft RTS.pdf differ diff --git a/year4/semester2/CT420/notes/CT420.pdf b/year4/semester2/CT420/notes/CT420.pdf index 4391c79e..0c7464c2 100644 Binary files a/year4/semester2/CT420/notes/CT420.pdf and b/year4/semester2/CT420/notes/CT420.pdf differ diff --git a/year4/semester2/CT420/notes/CT420.tex b/year4/semester2/CT420/notes/CT420.tex index b1bf8410..b1398e86 100644 --- a/year4/semester2/CT420/notes/CT420.tex +++ b/year4/semester2/CT420/notes/CT420.tex @@ -581,7 +581,148 @@ Finally, the \textbf{clock combining algorithm} averages the time offsets of sur The \textbf{combining algorithm} provides a final offset, so the client clock can be adjusted. The UNIX Clock Model provides the kernel variable \verb|tickadj| which amortises the required change gradually by making adjustments every tick e.g., every 10 milliseconds. +\section{Soft RTS} +A \textbf{soft RTS} is a RTS in which performance is degraded but not destroyed by failure to meet response time constraints, e.g., multimedia systems. +\subsection{Quality of Service (QoS)} +\textbf{Perceived QoS} reflects the subjective evaluation of service quality from the end user's perspective and overall satisfaction. +It encompasses factors like application responsiveness, ease of use, consistency, reliability, and the overall user interface delay. +It is challenging to measure accurately as it involves subjective experiences \& user feedback, often gathered through surveys, user studies, or feedback mechanisms. +\\\\ +\textbf{Intrinsic QoS} refers to the technical \& measurable characteristics of a network or service that directly affects its performance \& reliability. +Intrinsic QoS parameters include bandwidth, latency, packet loss rate, jitter, \& throughput. +Intrinsic QoS measures are typically quantifiable and can be objectively measured using various tools \& monitoring techniques. + +\subsubsection{QoS Metrics} +\textbf{Latency} is the time it takes to send a packet from point $A$ (say, the client) to point $B$ (say, the server). +It is physically limited by how fast signals can travel in wires or the open air. +Latency depends on the physical, real-world distance between $A$ and $B$. +Typical latencies are conceptually small, between roughly 10 and 200 milliseconds. +High latency can result in delays between user actions and system responses, leading to sluggish or unresponsive behaviour in real-time applications. +\\\\ +\textbf{Jitter} is the inconsistency or fluctuations in the arrival time of data packets at the receiver. +It can be caused by various factors, such as network congestion, packet loss, routing changes, etc. +It can have significant implications for real-time communication applications, particularly voice \& video sharing. +Inconsistent packet arrival times can lead to disruptions, distortion, and out-of-sync audio or video playback. +\\\\ +\textbf{Bandwidth} measures the amount of data that is able to pass through a network at a given time. +It is measured in bits per second. +Real-time applications with high-bandwidth requirements, such as high-definition video streaming \& VOIP may experience performance issues if the available bandwidth is insufficient to accommodate the data transmission demands. + +\subsection{Real-Time Multimedia Technologies} +\subsubsection{Transport Layer for Real-Time Media} +\textbf{TCP} provides reliability, ordered delivery, \& congestion control. +Retransmissions can lead to high delay and cause delay jitter. +TCP is not suitable for real-time systems and does not support mulitcast. +\\\\ +\textbf{UDP} has no built-in reliability or congestion control, and no defined technique for synchronising. +It has low latency and minimal overhead (no handshake, no retransmissions). +A feedback channel must be defined for quality control. + +\subsubsection{Service Requirements for Real-Time Flows (Voice / Video)} +\begin{itemize} + \item \textbf{Sequencing:} the process of maintaining the correct order of data packets during transmission and ensuring that they are re-assembled correctly at the receiver's end. + \item \textbf{Synchronisation:} ensures that different types of data streams (such as audio \& video) are aligned in time during playback. + \item \textbf{Payload identification:} different media types (MPEG1, MPEG2, H.261) may require different handling in terms of decoding or processing. + \item \textbf{Frame indication:} specifying which packets belong to the same frame or video sequence and helps with decoding \& rendering video frames accurately. +\end{itemize} + +\subsubsection{RTP} +\textbf{Real-time Transport Protocol (RTP)} provides end-to-end transport functions suitable for real-time audio/video applications over multicast \& unicast network services. +It works in user space over UDP. +The working model is as follows: +\begin{itemize} + \item The multimedia application generates multiple streams (audio, video, etc.) that are fed into the RTP library. + \item The library multiplexes the streams \& encodes them in RTP packets which are fed to a UDP socket. +\end{itemize} + +\textbf{Secure RTP (SRTP)} is used by applications including WhatsApp, Zoom, Skype, etc. for transporting voice \& video streams. + +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{./images/RTP.png} + \caption{ RTP protocol} +\end{figure} + +RTP services include: +\begin{itemize} + \item Payload type identification: determination of media encoding. + \item Synchronisation source identification: assigned to each distinct media source (such as a microphone or a camera). + Enables synchronisation of multiple streams coming from the same source (e.g., lip-syncing audio \& video). + \item Sequence numbering: a counter is used which is incremented on each RTP packet send and is used to detect lost packets. + \item Time-stamping: time monitoring, synchronisation, jitter calculation. + \item RTP issues: no QoS guarantees, no guarantee of packet delivery. +\end{itemize} + +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{./images/RTPpheader.png} + \caption{ RTP header} +\end{figure} + +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{./images/RTPdatadelirvery.png} + \caption{ RTP data delivery} +\end{figure} + +\textbf{RTP Control Protocol (RTCP)} is a companion protocol to RTP that is used periodically to transmit control packets to participants in a streaming multimedia session. +It gathers statistics on the media connection, including bytes sent, packets sent, lost packets, jitter, feedback, \& round-trip delay. +It provides feedback on the quality of the service being provided by RTP but does not actually transport any data. +The application may use this information to increase the quality of service, perhaps by limiting flow or using a different codec. + +\subsubsection{Mouth-to-Ear M2E Delay} +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{./images/m2e.png} + \caption{ M2E delay } +\end{figure} + +M2E delay consists of: +\begin{itemize} + \item Sender: + \begin{itemize} + \item Packetisation delay. + \item Encoding delays. + \item OS/Application/Driver software. + \item MAC delays. + \end{itemize} + + \item Network: + \begin{itemize} + \item Propagation delay. + \item Queuing delays. + \item Processing/serialisation delays in routers. + \end{itemize} + + \item Receiver: + \begin{itemize} + \item NIC delays. + \item OS/Application/Driver software. + \item Jitter buffer delays. + \item Decoding delays. + \end{itemize} +\end{itemize} + +VOIP QoS strategies include: +\begin{itemize} + \item Sender-based: + \begin{itemize} + \item RTCP feedback with adaptive codeces: if loss/delay excessive, switch to lower-bandwidth code or implement Forward Error Correction (FEC) strategy. + \end{itemize} + + \item Network-based: + \begin{itemize} + \item Prioritising delay-sensitive traffic flows. + \end{itemize} + + \item Receiver-based: + \begin{itemize} + \item Buffering strategies: the human ear is not sensitive to short-term variations; + the buffer ``absorbs'' variation in network queueing delays and the voice can be reconstructed using RTP timestamps, but this adds to overall M2E delay. + \item Packet Loss Concealment (PLC) and FEC. + \end{itemize} +\end{itemize} diff --git a/year4/semester2/CT420/notes/[ b/year4/semester2/CT420/notes/[ new file mode 100644 index 00000000..cda0ac54 --- /dev/null +++ b/year4/semester2/CT420/notes/[ @@ -0,0 +1,660 @@ +% ! TeX program = lualatex +\documentclass[a4paper,11pt]{article} +% packages +\usepackage{censor} +\StopCensoring +\usepackage{fontspec} +\setmainfont{EB Garamond} +% for tironian et fallback +% % \directlua{luaotfload.add_fallback +% % ("emojifallback", +% % {"Noto Serif:mode=harf"} +% % )} +% % \setmainfont{EB Garamond}[RawFeature={fallback=emojifallback}] + +\setmonofont[Scale=MatchLowercase]{Deja Vu Sans Mono} +\usepackage[a4paper,left=2cm,right=2cm,top=\dimexpr15mm+1.5\baselineskip,bottom=2cm]{geometry} +\setlength{\parindent}{0pt} + +\usepackage{fancyhdr} % Headers and footers +\fancyhead[R]{\normalfont \leftmark} +\fancyhead[L]{} +\pagestyle{fancy} + +\usepackage{microtype} % Slightly tweak font spacing for aesthetics +\usepackage[english]{babel} % Language hyphenation and typographical rules +\usepackage{xcolor} +\definecolor{linkblue}{RGB}{0, 64, 128} +\usepackage[final, colorlinks = false, urlcolor = linkblue]{hyperref} +% \newcommand{\secref}[1]{\textbf{§~\nameref{#1}}} +\newcommand{\secref}[1]{\textbf{§\ref{#1}~\nameref{#1}}} + +\usepackage{mathtools} +\usepackage{changepage} % adjust margins on the fly + +\usepackage{minted} +\usemintedstyle{algol_nu} + +\usepackage{pgfplots} +\pgfplotsset{width=\textwidth,compat=1.9} + +\usepackage{caption} +\newenvironment{code}{\captionsetup{type=listing}}{} +\captionsetup[listing]{skip=0pt} +\setlength{\abovecaptionskip}{5pt} +\setlength{\belowcaptionskip}{5pt} + +\usepackage[yyyymmdd]{datetime} +\renewcommand{\dateseparator}{--} + +\usepackage{enumitem} + +\usepackage{titlesec} + +\author{Andrew Hayes} + +\begin{document} +\begin{titlepage} + \begin{center} + \hrule + \vspace*{0.6cm} + \Huge \textsc{ct420} + \vspace*{0.6cm} + \hrule + \LARGE + \vspace{0.5cm} + Real-Time Systems + \vspace{0.5cm} + \hrule + + \vfill + + \hrule + \begin{minipage}{0.495\textwidth} + \vspace{0.4em} + \raggedright + \normalsize + \begin{tabular}{@{}l l} + Name: & Andrew Hayes \\ + Student ID: & 21321503 \\ + E-mail: & \href{mailto://a.hayes18@universityofgalway.ie}{a.hayes18@universityofgalway.ie} \\ + \end{tabular} + \end{minipage} + \begin{minipage}{0.495\textwidth} + \raggedleft + \vspace*{0.8cm} + \Large + \today + \vspace*{0.6cm} + \end{minipage} + \medskip\hrule + \end{center} +\end{titlepage} + +\pagenumbering{roman} +\newpage +\tableofcontents +\newpage +\setcounter{page}{1} +\pagenumbering{arabic} + +\section{Introduction} +\subsection{Lecturer Contact Information} +\begin{itemize} + \item Name: Dr. Michael Schukat. + \item E-mail: \href{mailto://michael.schukat@universityofgalway.ie}{michael.schukat@universityofgalway.ie}. + \item Office: CSB-3002. +\end{itemize} + +\begin{itemize} + \item Name: Dr. Jawad Manzoor. + \item E-mail: \href{jawad.manzoor@universityofgalway.ie}{jawad.manzoor@universityofgalway.ie}. + \item Office: CSB-3012. +\end{itemize} + +\subsection{Assessment} +\begin{itemize} + \item 2 hours of face-to-face \& virtual labs per week from Week 03. + \item 30\% Continuous Assessment: + \begin{itemize} + \item 2 assignments, 10\% each. + \item 2 in-class quizzes between Week 07 \& Week 12, worth 5\%. + \end{itemize} +\end{itemize} + +\subsection{Introduction to Real-Time Systems} +A system is said to be \textbf{real-time} if the total correctness of an operation depends not only upon its logical correctness but also upon the time in which it is performed. +Contrast functional requirements (logical correctness) versus non-functional requirements (time constraints). +There are two main categorisation factors: +\begin{itemize} + \item \textbf{Criticality:} + \begin{itemize} + \item \textbf{Hard RTS:} deadlines (responsiveness) is critical. + Failure to meet these have severe to catastrophic consequences (e.g., injury, damage, death). + \item \textbf{Soft RTS:} deadlines are less critical, in many cases significant tolerance can be permitted. + \end{itemize} + + \item \textbf{Speed} + \begin{itemize} + \item \textbf{Fast RTS:} responses in microseconds to hundreds of microseconds. + \item \textbf{Slow RTS:} responses in the range of seconds to days. + \end{itemize} +\end{itemize} + +A \textbf{safety-critical system (SCS)} or life-critical system is a system whose failure or malfunction may result in death or serious injury to people, loss of equipment / property or severe damage, \& environmental harm. + +\section{The Essence of Time: From Measurement to Navigation \& Beyond} +\textbf{Time} is the continued sequence of existence \& events that occurs in an apparently irreversible succession from past, through the present, into the future. +Methods of temporal measurement, or chronometry, take two distinct forms: +\begin{itemize} + \item The \textbf{calendar}, a mathematical tool for organising intervals of term; + \item The \textbf{clock}, a physical mechanism that counts the passage of time. +\end{itemize} + +Global (maritime) exploration requires exact maritime navigation, i.e., longitude \& latitude calculation. +\textbf{Latitude} (north-south) orientation is straightforward; \textbf{longitude} (east-west orientation) requires a robust (maritime) clock. +\\\\ +\textbf{Ground-based navigation systems} like LORAN (LOng RAnge Navigation) were developed in the 1940s and were in use until recently, and required fixed terrestrial longwave radio transmitters, and receivers on-board of ships \& planes. +They are also referred to as hyperbolic navigation or multilateration. +The principles of ground-based navigation systems is as follows: +\begin{enumerate} + \item A \textbf{master} with a known location broadcasts a radio pulse. + \item Multiple \textbf{slave} stations with a known distance from the master send their own pulse, upon receiving the master pulse. + \item A \textbf{receiver} receives master \& slave pulses and measures the delay between them. + \item This allows the receiver to deduce the distance to each of the stations, providing a fix. +\end{enumerate} + +NEED TO FINISH + +\section{Time Synchronisation in Distributed Systems} +A \textbf{distributed system (DS)} is a type of networked system wherein multiple computers (nodes) work together to perform a task. +Such systems may or may not be connected to the Internet. +Time \& synchronisation are important issues here: think of error logs in distributed systems -- how can error events recorded in different computers be correlated with each other if there is no common time base? +The problem is that GNSS-based time synchronisation may or may not be available, as GPS signals are absorbed or weakened by building structures. +There is no other time reference such systems can rely on because in such a distributed system there are just a series of imperfect computer clocks. +\\\\ +In distributed systems, all the different nodes are supposed to have the same notion of time, but quartz oscillators oscillate at slightly different frequencies. +Hence, clocks tick at different rates (called \textit{clock skew}), resulting in an increasing gap in perceived time. +The difference between two clocks at a given pot is called \textit{clock offset}. +The \textbf{clock synchronisation problem} aims to minimise the clock skew and subsequently the offset between two or more clocks. +A clock can show a positive or negative offset with regard to a reference clock (e.g., UTC), and will need to be resynchronised periodically. +One cannot just set the clock to the ``correct'' time: jumps, particularly backwards, can confuse software and operating systems. +Instead, we aim for gradual compensation by correcting the skew: if a clock runs too fast, make it run slower until correct and if a clock runs too slow, make it run faster until correct. +\\\\ +Synchronisation can take place in different forms: +\begin{itemize} + \item Based on \textbf{physical} clocks: absolute to each other by synchronising to an accurate time source (e.g., UTC), absolute to each other by synchronising to locally agreed time (i.e., no link to a global time reference), where the term \textit{absolute} means that the differences in timestamps are proper time intervals. + + \item Based on \textbf{logical} clocks (i.e., clocks are more like counters): timestamps may be ordered but with no notion of measurable time intervals. +\end{itemize} + +In either case, the DS endpoints synchronise using a shared network. +For physical clock synchronisation, network latencies must be considered as packets traverse from a sending node to a receiving node. +In a \textbf{perfect network}, messages \textit{always} arrive, with a propagation delay of \textit{exactly} $d$; +the sender sends time $T$ in a message, the receiver sets its clock to $T + d$, and synchronisation is exact. +\\\\ +In a \textbf{deterministic network}, messages arrive with a propagation delay $0 < d \leq D$; +the sender sends time $T$ in a message, the receiver sets its clock to $T + \frac{D}{2}$, and therefore the synchronisation error is at most $\frac{D}{2}$. +\textbf{Deterministic communication} is the ability of a network to guarantee that a message will be transmitted in a specified, predictable period of time. + +\subsection{Synchronisation in the Real World} +Most off-the-shelf networks are \textit{asynchronous}, that is, data is transmitted intermittently on a best-effort basis. +They are designed for flexibility, not determinism, and as a result, propagation delays are arbitrary and sometimes even unsymmetric (i.e., upstream \& downstream latencies are different). +Therefore, synchronisation algorithms are needed to accommodate these limitations. + +\subsubsection{Cristian's Algorithm} +\textbf{Cristian's algorithm} attempts to compensate for symmetric network delays: +\begin{enumerate} + \item The client remembers the local time $T_0$ just before sending a request. + \item The server receives the request, determines $T_S$, and sends it as a reply. + \item When the client receives the reply, it notes the local arrival time $T_1$. + \item The correct time is then approximately $(T_S + \frac{(T_1 - T_0)}{2} )$. +\end{enumerate} + +The algorithm assumes symmetric network latency. +If the server is synced to UTC< all clients will follow UTC. +Limitations of Cristian's algorithm include: +\begin{itemize} + \item Assumes a symmetric network latency; + \item Assumes that timestamps can be taken as the packet hits the wire / arrives at the client; + \item Assumes that $T_S$ is right in the middle of the server process; for example, consider the server process being pre-empted just before it sends the response back to the client, which will corrupt the synchronisation of the client. +\end{itemize} + +\subsubsection{Berkeley Algorithm} +In the \textbf{Berkeley algorithm}, there is no accurate time server: instead, a set of client clocks is synchronised to their average time. +The assumption is that offsets / skews of all clocks follow some symmetric distribution (e.g., a normal distribution) with some clocks going faster and others slower, and therefore a mean value close to 0. +\begin{enumerate} + \item One node is designated to be the \textbf{master node} $M$. + \item The master node periodically queries all other clients for their local time. + \item Each client returns a timestamp or their clock offset to the master. + \item Cristian's algorithm is used to determine and compensate for RTTs, which can be different for each client. + \item Using these, the master computes the average time (thereby ignoring outliers), calculates the difference to all timestamps it has received, and sends an adjustment to each client. + Again, each computer gradually adjusts its local clock. +\end{enumerate} + +Client clocks are adjusted to run faster or slower, to be synced to an overall agreed system time. +The client networks is an intranet, i.e., an isolated system. +Therefore, the Berkeley algorithm is an \textbf{internal clock synchronisation algorithm}. +The Berkeley algorithm was implemented in the TEMPO time synchronisation protocol, which was part of the Berkelely UNIX 4.3BSD system. + +\subsection{Logical Clocks} +\textbf{Logical clocks} are another concept linked to internal clock synchronisation. +Logical clocks only care about their internal consistency, but not about absolute (UTC) time; +subsequently, they do not need clock synchronisation and take into account the order in which events occur rather than the time at which they occurred. +In practice, if clients or processes only care that event $a$ happens before event $b$, but don't care about the exact time difference, they can make use of a logical clock. +\\\\ +We can define the \textbf{happens-before relation} $a \rightarrow b$: +\begin{itemize} + \item If events $a$ and $b$ are within the same process, then $a \rightarrow b$ if $a$ occurs with an earlier local timestamp: \textbf{process order}. + \item If $a$ is the event of a message being sent by one process, and $b$ is the event of the message being received by another process, then $a \rightarrow b$: \textbf{causal order}. + \item We also have \textbf{transitivity:} if $a \rightarrow b$ and $b \rightarrow c$, then $a \rightarrow c$. +\end{itemize} +Note that this only provides a \textit{partial order}: +if two events $a$ and $b$ happen in different processes that do not exchange messages (not even indirectly), then neither $a \rightarrow b$ nor $b \rightarrow a$ is true. +In this situation, we say that $a$ and $b$ are \textbf{concurrent} and write $a \sim b$, i.e., nothing can be said about when the events happened or which event happened first. +\\\\ +Happens-before can be implemented using the \textbf{Lamport scheme:} +\begin{enumerate} + \item Each process $P_i$ has a logical clock $L_i$, where $L_i$ can be simply an integer variable initialised to 0. + \item $L_i$ is incremented on every local event $e$; we write $L_i(e)$ or $L(e)$ as the timestamp of $e$. + \item When $P_i$ sends a message, it increments $L_i$ and copies its content into the packet. + \item When $P_i$ receives a message from $P_k$, it extracts $L_k$ and sets $L := \text{max}(L_i, L_k)$ and then increments $L_i$. +\end{enumerate} + +This guarantees that if $a \rightarrow b$, then $L_i(a) < L_k(b)$, but nothing else. +\\\\ +The primary limitation of Lamport clocks is that they do not capture \textbf{causality}. +Lamport's logical clocks lead to a situation where all events in a distributed system are ordered, so that if an event $a$ (linked to $P_i$) ``happened before'' event $b$ (linked to $P_k$), i.e., $a \rightarrow b$, then $a$will allso be positioned in that ordering before $b$ such that $L_i(a) < L_k(b)$ or simply $L(a) < L(b)$; +however, nothing can be said about the relationship between two events $a$ \& $b$ by merely comparing their time values $L_i(a)$ and $L_k(b$.): we can't tell if $a \rightarrow b$ or $b \rightarrow a$ or $a \sim b$ unless they occur in the same process. + +\subsubsection{Vector Clocks} +In practice, causality is captured by means of \textbf{vector clocks}: +\begin{enumerate} + \item There is an ordered list of logical clocks, with one per process. + Each process $P_i$ maintains a vector $\vec{V_i}$, initially containing all zeroes. + Each index $k$ of a vector clock $\vec{V_i}[k]$ represents the number of events that process $P_i$ knows have occurred in process $P_k$. + $\vec{V_i}[i]$ is the count of events that have occurred locally at process $P_i$, while $\vec{V_i}[k]$ (for $k\neq i$) is the count of events in process $P_k$ that $P_i$ is aware of. + + \item On a local event $e$, $P_i$ increments its own clock component $\vec{V_i}[i]$. + If the event is ``message send'', a new $\vec{V_i}$ is copied into the packet, so that on message sends the current vector state is included in the message. + + \item If $P_i$ receives a message from $P_m$, then each index $\vec{V_i}[k]$ where $k \neq i$ is set to $\text{max}(\vec{V_m}[k], \vec{V_i}[k])$, and $\vec{V_i}[i]$ is incremented. +\end{enumerate} + +Intuitively, $\vec{V_i}[k]$is the number of events in process $P_k$ that have been observed by $P_i$. + +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{./images/vector_clocks_example.png} + \caption{Vector clocks example} +\end{figure} + +In the above example, when process $P_2$ receives message $m_1$, it merges the entries from $P_1$'s clock by choosing the maximum value of each position. +Similarly, when $P_3$ receives $m_2$, it merges in $P_2$'s clock, thus incorporating the changes from $P_1$ that $P_2$ already saw. +Vector clocks explicitly track the transitive causal order: $f$'s timestamp captures the history of $a$, $b$, $c$, \& $d$. +\\\\ +To use vector clocks for ordering, we can compare them piecewise: +\begin{itemize} + \item We say $\vec{V_i} = \vec{V_j}$ if and only if $\vec{V_i}[k] = \vec{V_j}[k] \forall k$. + \item We say $\vec{V_i} \leq \vec{V_j}$ if and only if $\vec{V_i}[k] \leq \vec{V_j}[k] \forall k$. + \item We say $\vec{V_i} < \vec{V_j}$ if and only if $\vec{V_i} \leq \vec{V_j}$ and $\vec{V_i} \neq \vec{V_j}$. + \item We say $\vec{V_i} \sim \vec{V_j}$ otherwise, e.g., $\vec{V_i} = [2,0,0]$ and $\vec{V_j} = [0,0,1]$. +\end{itemize} + +For any two event timestamps $T(a)$ \& $T(b)$: +\begin{itemize} + \item if $a \rightarrow b$, then $T(a) < T(b)$; \textbf{and} + \item if $T(a) < T(b)$, then $a \rightarrow b$. +\end{itemize} + +Hence, we can use timestamps to determine if there is a causal ordering between any two events. + +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{./images/vector_vs_lamport.png} + \caption{Lamport clocks versus vector clocks} +\end{figure} + +\section{The NTP Protocol} +The options for computer clocks are essentially as follows: +\begin{itemize} + \item \textbf{Option A:} stick to crystals. + \begin{itemize} + \item Costly precision manufacturing. + \item Works indoors. + \item Temperature Compensated Crystal Oscillator (TCXO). + \item Oven Controlled Crystal Oscillator (OCXO). + \end{itemize} + + \item \textbf{Option B:} buy an atomic clock (\$50,000 -- \$100,000) or a GNSS receiver (based on an atomic clock, but doesn't work indoors), or a time signal radio receiver if you are based in central Europe. + + \item \textbf{Option C:} use software-based approaches to discipline cheap crystal clocks. + Less quality, but useful for certain applications, and works indoors. +\end{itemize} + +\textbf{Distributed master clocks} provide a time reference to hosts that are inter-connected via a network. +The underlying time-synchronisation protocols combine aspects of Cristian's algorithm (i.e., RTD calculation) and Berkeley's algorithm (i.e., combining multiple reference time sources). +Good time synchronisation requires: +\begin{itemize} + \item Good time references: easily done with GPS, atomic clocks, etc. + \item Predictable / symmetric / deterministic network latencies: doable in LAN setups, but not guaranteed in Internet data communication. +\end{itemize} + +There are two main distributed master clock protocols: +\begin{itemize} + \item \textbf{Network Time Protocol (NTP):} defined in RFC 5905, originally used in the Unix-based NTP daemon, one of the first Internet protocols that ever evolved. + \item \textbf{Precision Time Protocol (PTP):} designed for managed networks, e.g., LAN. +\end{itemize} + +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{./images/ntpvsptp.png} + \caption{NTP \& PTP characteristics} +\end{figure} + +In \textbf{uni-directional synchronisation} a reference clock sends a timestamp to a host via a network. +The host then uses the timestamp to set its local clock. +Useful when message latencies are minor relative to the synchronisation levels required. +\\\\ +In \textbf{round-trip synchronisation (RTS)} a host sends a request message, receives a reference clock response message with known (local) submission \& arrival times, allowing for the calculation of the round-trip delay (1) and the host clock error (2), i.e., the phase offset. +Variations of RTS form the basis for NTP \& PTP. + +\begin{align} + \delta = (T_{i+3} - T_i) - (T_{i+2} - T_{i+1}) +\end{align} +\begin{align} + \theta = (T_{i+1}-T_i) + \frac{(T_{i+2}-T_{i+3})}{2} +\end{align} + +\begin{figure}[H] + \centering + \includegraphics[width=0.4\textwidth]{./images/rts.png} + \caption{ RTS example } +\end{figure} + +\subsection{NTP} +The NTP architecture, protocol, \& algorithms have evolved over the last 40 years to the latest NTP Version 4. +NTP is the standard Internet protocol for time synchronisation \& co-ordinated UTC time distribution. +It is a fault-tolerant protocol, as it automatically selects the best of several available time sources to synchronise with. +It is highly scalable, as the nodes form a hierarchical structure with reference clock(s) at the top: +\begin{itemize} + \item Stratum 0: Time Reference Source (e.g., GPS, TAI atomic clocks, DCF 77). + \item Stratum 1: Primary Time Server. +\end{itemize} + +NTP applies some general aforementioned principles such as avoiding setting clocks backwards and avoiding large step changes; +the required change (positive or negative) is amortised over a series of short intervals (e.g., over multiple ticks). +\\\\ +NTP is the longest-running and continuously operating Internet protocol (since around 1979). +Government agencies in many other countries and on all continents (including Antarctica) operate public NTP primary servers. +National \& regional service providers operate public NTP secondary servers synchronised to the primary servers. +Many government agencies, private \& public institutions including universities, broadcasters, financial institutions, \& corporations operate their own NTP networks. +\begin{figure}[H] + \centering + \includegraphics[width=0.5\textwidth]{./images/ntphierarchy.png} + \caption{ NTP hierarchy } +\end{figure} + +In \textbf{client/server mode}, UDP is used for data transfer (no TCP), i.e., NTP over UDP on UDP port 123. +There is also the optional use of broadcasting or multicasting (not covered here). +Several packet exchanges between the NTP client and the Stratum server take place to determine the client offset: +\begin{enumerate} + \item The client sends a packet with \textbf{originate timestamp} $A$. + \item The server receives the packet and returns a response containing the originate timestamp $A$ as well as the \textbf{receive timestamp} $B$ and the \textbf{transmit timestamp} $C$. + \item The client receives this packet and processes $A$, $B$, $C$, as well as the packet arrival time $D$ of the received packet; it then determines the offset and the round-trip delay (RTD). +\end{enumerate} + +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{./images/ntpoperation.png} + \caption{ NTP operation } +\end{figure} + +The above example is of a symmetric network with a 15ms delay each way; the client's clock lags 5ms behind the server's clock: +\begin{align*} + \text{RTD} = (D-A)-(C-B) = 32-2 =& 30\text{ms} \\ + \text{Offset} = \frac{((B-A)+(C-D))}{2} = \frac{(20 + (-10))}{2} =& 5\text{ms} +\end{align*} + +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{./images/networkdelayasymmetry.png} + \caption{ Network delay asymmetry } +\end{figure} + +In the above example, the client's clock still lags 5ms behind the servers clock, but there is an asymmetric network latency: 10ms versus 20ms: +\begin{align*} + \text{RTD} = (D-A)-(C-B) = 32-2 =& 30\text{ms} \\ + \text{Offset} = \frac{((B-A)+(C-D))}{2} = \frac{(15 + (-15))}{2} =& 0\text{ms} +\end{align*} + +Typical NTP performance for various set-ups is as follows: +\begin{itemize} + \item Small LAN: \sim10 microseconds best possible case on a 2-node LAN, \sim220 microseconds on a real-world small LAN. + \item Typical large-building LAN: \sim2ms. + \item Internet with a few hops: 10–20ms. + \item Long distance and/or slow or busy link: 100ms–1s. +\end{itemize} + +Accuracy is further degraded on networks with asymmetric traffic delays. +\\\\ +The \textbf{NTP time format} has a reference scale of UTC. +Time parameters are 64 bits long: +\begin{itemize} + \item Seconds since January 1, 1900 (32 bits, unsigned). + \item Fraction of second (32 bits, unsigned). +\end{itemize} +The NTP time format has a dynamic range of 136+ years, with rollover in 2036. +Its resolution is 2\textsuperscript{-32} seconds \sim232 picoseconds. + +\subsubsection{NTP Protocol Header} +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{./images/ntpheader.png} + \caption{ NTP protocol header } +\end{figure} +\begin{itemize} + \item \verb|LI| (\textbf{Leap Indicator}) 2-bit: + \begin{itemize} + \item \verb|0|: no warning; + \item \verb|1|: last minute of the day has 61 seconds; + \item \verb|2|: last minute of the day has 59 seconds. + \end{itemize} + + + \item \verb|VN| (\textbf{Version Number}) 2-bit: currently 4. + + \item \verb|Mode|: 3-bit integer, including: + \begin{itemize} + \item \verb|3|: client; + \item \verb|4|: server. + \end{itemize} + + \item \verb|Stratum|: 8-bit integer for Stratum server hierarchy level, including: + \begin{itemize} + \item \verb|1|: primary server (i.e., stratum 1); + \item \verb|2|–\verb|15|: secondary server. + \end{itemize} + + \item \verb|Poll|: 8-bit signed integer representing the maximum interval between successive message, in $\log_2$ seconds. + This field indicates the interval at which the client will poll the NTP server for time updates. + The client dynamically adjusts this interval based on its clock's stability \& the network conditions to balance accuracy \& network load. + + \item \verb|Precision|: 8-bit signed integer representing the resolution of the system clock (the tick increment) in $\log_2$ seconds; + e.g., a value of -18 corresponds to a resolution of about one microsecond (2\textsuperscript{-18}) seconds. + + \item \verb|Root Delay|: round-trip packet delay from a client to a stratum 1 server. + It gives a crude estimate of the worst-case time transfer error between a client and a stratum 1 server due to network asymmetry, i.e., if all of the round-trip delay was in one direction and none in the other direction. +\end{itemize} + +For a single client clock, the \textbf{dispersion} is a measure of how much the client's clock might drift during a synchronisation cycle: +\begin{align*} + \text{Dispersion} = \textit{DR} \times (D-A) + \textit{TS} +\end{align*} +where $(D-A)$ is the duration of a synchronisation cycle, with $A$ being the first timestamp and $D$ being the last timestamp, \textit{DR} being the local clock skew (i.e., the deviation of actual clock tick frequency to nominal clock tick frequency), and \textit{TS} being the timestamping errors due to the finite resolution of the clock and delays in reading the clock when fetching a timestamp. +\\\\ +The \textbf{root dispersion} of a client clock is the combined dispersions of all stratum servers along the path to a Stratum 1 server. +\\\\ +The \textbf{root distance} is the sum of root dispersion and half the root delay. +It provides a comprehensive measure of the maximum error in time synchronisation as the total worst case timing error accumulated between the Stratum 1 server and the client. + +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{./images/rootdispersion.png} + \caption{ Example root dispersion \& root delay } +\end{figure} + +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{./images/annotatedntpheader.png} + \caption{ Annotated NTP protocol header } +\end{figure} + +A \textbf{reference ID (refid)} is a 32-bit code (4 ASCII bytes) identifying the particular server or reference clock, e.g.,: +\begin{itemize} + \item \verb|GPS|: Global Positioning System; + \item \verb|GAL|: Galileo Positioning System; + \item \verb|PPS|: Generic Pulse-Per-Second; + \item \verb|DCF|: LF Radio DCF77 Mainflingen, DE 77.5 kHz; + \item \verb|WWV|: HF Radio WWV Fort Collins, Colorado; + \item \verb|GOOG|: unofficial Google refid used by Google NTP servers as \verb|time4.google.com|. +\end{itemize} + +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{./images/ntparchitecuraloverview.png} + \caption{ NTP architectural overview } +\end{figure} + +An NTP client synchronises with multiple stratum servers. +It uses a range of algorithms to deal with variable \& asymmetric non-deterministic network delays and to determine its most likely offset, thereby running a series of processes: +\begin{itemize} + \item The peer process runs when a packet is received; + \item The poll process sends packets at intervals determined by the clock discipline process \& remote server; + \item The system process runs when a new update is received; + \item The clock discipline process implements clock time adjustments; + \item The clock adjust process implements periodic clock frequency (VFO) adjustments. +\end{itemize} + +For each stratum there is a \textbf{poll process} that sends NTP packets at intervals ranging from 8 seconds to 36 hours. +The corresponding \textbf{peer processes} receive NTP packets and, after performing some packet sanity tests, $T1$ – $T4$ are determined / extracted. +The NTP daemon calculates offset \& delay as seen before. +The time series of offset \& delay values calculated by multiple peer processes are processed by a sequence of algorithms, thus eliminating servers with long RTD or servers that show ``strange'' offsets which, for example, are often the result of network asymmetries. + +\subsubsection{Mitigation Algorithms} +The \textbf{clock filter algorithm} uses a sliding window of eight samples for each stratum server and picks out the sample with the least expected error, i.e., it chooses the sample with the minimum RTD. +It is effective at removing spikes resulting from intermittent network congestions. + +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{./images/clockfilteralg.png} + \caption{ Clock filter algorithm before and after } +\end{figure} + +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{./images/clockfilteralgmotivation.png} + \caption{ + The wedge scattergram plots sample points of offset versus delay (RTD) collected over a 24-hour period by a client clock communicating with a single stratum server. + For this experiment, the client clock is externally synced to the stratum server, so the offset should be zero; + however, as the (network) round trip delay increases, the offset variability increases, resulting in increasingly larger offset errors. + Therefore, the best samples are those at the lowest delay. + This is taken into account by the clock filter algorithm. + } +\end{figure} + +The \textbf{intersection algorithm} selects a subset of peers (i.e., stratum servers) and identifies truechimers \& truetickers based on the intersection of confidence (offset) intervals (i.e., min/max offsets of a clock over $x$ readings determines its invterval). + +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{./images/intersectional.png} + \caption{ Plot range of offsets calculated by each peer with 1, 2, \& 3 overlapping} +\end{figure} + +\textbf{Marzullo's algorithm} is an agreement protocol for estimating accurate time from a number of noisy time sources by intersecting offset intervals; if some intervals don't intersect, it considers the intersection of the majority of intervals. +It eliminates false tickers. +\\\\ +The \textbf{clock cluster algorithm} processes the truechimers returned by the clock intersection algorithm. +It produces a list of survivors by eliminating truechimers that have a comparably large root delay \& root dispersion. +Finally, the \textbf{clock combining algorithm} averages the time offsets of survivors using their root dispersions as a weight, i.e., survivors with a small root dispersion have a higher weight. +\\\\ +The \textbf{combining algorithm} provides a final offset, so the client clock can be adjusted. +The UNIX Clock Model provides the kernel variable \verb|tickadj| which amortises the required change gradually by making adjustments every tick e.g., every 10 milliseconds. + +\section{Soft RTS} +A \textbf{soft RTS} is a RTS in which performance is degraded but not destroyed by failure to meet response time constraints, e.g., multimedia systems. + +\subsection{Quality of Service (QoS)} +\textbf{Perceived QoS} reflects the subjective evaluation of service quality from the end user's perspective and overall satisfaction. +It encompasses factors like application responsiveness, ease of use, consistency, reliability, and the overall user interface delay. +It is challenging to measure accurately as it involves subjective experiences \& user feedback, often gathered through surveys, user studies, or feedback mechanisms. +\\\\ +\textbf{Intrinsic QoS} refers to the technical \& measurable characteristics of a network or service that directly affects its performance \& reliability. +Intrinsic QoS parameters include bandwidth, latency, packet loss rate, jitter, \& throughput. +Intrinsic QoS measures are typically quantifiable and can be objectively measured using various tools \& monitoring techniques. + +\subsubsection{QoS Metrics} +\textbf{Latency} is the time it takes to send a packet from point $A$ (say, the client) to point $B$ (say, the server). +It is physically limited by how fast signals can travel in wires or the open air. +Latency depends on the physical, real-world distance between $A$ and $B$. +Typical latencies are conceptually small, between roughly 10 and 200 milliseconds. +High latency can result in delays between user actions and system responses, leading to sluggish or unresponsive behaviour in real-time applications. +\\\\ +\textbf{Jitter} is the inconsistency or fluctuations in the arrival time of data packets at the receiver. +It can be caused by various factors, such as network congestion, packet loss, routing changes, etc. +It can have significant implications for real-time communication applications, particularly voice \& video sharing. +Inconsistent packet arrival times can lead to disruptions, distortion, and out-of-sync audio or video playback. +\\\\ +\textbf{Bandwidth} measures the amount of data that is able to pass through a network at a given time. +It is measured in bits per second. +Real-time applications with high-bandwidth requirements, such as high-definition video streaming \& VOIP may experience performance issues if the available bandwidth is insufficient to accommodate the data transmission demands. + +\subsection{Real-Time Multimedia Technologies} +\subsubsection{Transport Layer for Real-Time Media} +\textbf{TCP} provides reliability, ordered delivery, \& congestion control. +Retransmissions can lead to high delay and cause delay jitter. +TCP is not suitable for real-time systems and does not support mulitcast. +\\\\ +\textbf{UDP} has no built-in reliability or congestion control, and no defined technique for synchronising. +It has low latency and minimal overhead (no handshake, no retransmissions). +A feedback channel must be defined for quality control. + +\subsubsection{Service Requirements for Real-Time Flows (Voice / Video)} +\begin{itemize} + \item \textbf{Sequencing:} the process of maintaining the correct order of data packets during transmission and ensuring that they are re-assembled correctly at the receiver's end. + \item \textbf{Synchronisation:} ensures that different types of data streams (such as audio \& video) are aligned in time during playback. + \item \textbf{Payload identification:} different media types (MPEG1, MPEG2, H.261) may require different handling in terms of decoding or processing. + \item \textbf{Frame indication:} specifying which packets belong to the same frame or video sequence and helps with decoding \& rendering video frames accurately. +\end{itemize} + +\subsubsection{RTP} +\textbf{Real-time Transport Protocol (RTP)} provides end-to-end transport functions suitable for real-time audio/video applications over multicast \& unicast network services. +It works in user space over UDP. +The working model is as follows: +\begin{itemize} + \item The multimedia application generates multiple streams (audio, video, etc.) that are fed into the RTP library. + \item The library multiplexes the streams \& encodes them in RTP packets which are fed to a UDP socket. +\end{itemize} + +\textbf{Secure RTP (SRTP)} is used by applications including WhatsApp, Zoom, Skype, etc. for transporting voice \& video streams. + +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{./images/RTP.png} + \caption{ RTP protocol} +\end{figure} + +RTP services include: +\begin{itemize} + \item Payload type identification: determination of media encoding. + \item Synchronisation source identification: assigned to each distinct media source (such as a microphone or a camera). + Enables synchronisation of multiple streams coming from the same source (e.g., lip-syncing audio \& video). +\end{itemize} + + + + + + + +\end{document} diff --git a/year4/semester2/CT420/notes/images/RTP.png b/year4/semester2/CT420/notes/images/RTP.png new file mode 100644 index 00000000..983c424f Binary files /dev/null and b/year4/semester2/CT420/notes/images/RTP.png differ diff --git a/year4/semester2/CT420/notes/images/RTPdatadelirvery.png b/year4/semester2/CT420/notes/images/RTPdatadelirvery.png new file mode 100644 index 00000000..fb2b3dac Binary files /dev/null and b/year4/semester2/CT420/notes/images/RTPdatadelirvery.png differ diff --git a/year4/semester2/CT420/notes/images/RTPpheader.png b/year4/semester2/CT420/notes/images/RTPpheader.png new file mode 100644 index 00000000..aa841730 Binary files /dev/null and b/year4/semester2/CT420/notes/images/RTPpheader.png differ diff --git a/year4/semester2/CT420/notes/images/m2e.png b/year4/semester2/CT420/notes/images/m2e.png new file mode 100644 index 00000000..26b50289 Binary files /dev/null and b/year4/semester2/CT420/notes/images/m2e.png differ