aindreas/uni
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[CT420]: WK07 Lecture 2 materials

Browse Source
This commit is contained in:
Aindréas Ó hAodha
2025-02-26 15:44:32 +00:00
parent 4df9a21c7d
commit 7c06a4da62
8 changed files with 801 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

141
year4/semester2/CT420/notes/CT420.tex
View File

@ -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}