-
Notifications
You must be signed in to change notification settings - Fork 3
/
lab_assignments.tex
220 lines (149 loc) · 11 KB
/
lab_assignments.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
\chapter{Lab Assignments}
In these labs you can use any programming language that you want.
In each assignment you must deliver the source code and a brief explanatory pdf document explaining how you solved the assignment.
It should also include some examples, including the commands that you used to test it and the results.
Some assignments may ask for additional information, such as plots.
Pack all the files in a zip file (not rar) and submit it using moodle.
Remember to include the names and NIA in all the source files and in the document.
Prepare the assignment in advance, so that you can complete it during the class.
The submission deadline will be one week after the class.
\section{Traffic Generator and Sink}
In this lab assignment you will program a Poisson traffic generator and a traffic sink.
The Poisson traffic generator takes the following parameters:
destination host, destination port, packet rate and traffic class.
It generates UDP packets with a string that contains three integer values separated by a blank space. The integers represents a packet id (starting with 0), time stamp in milliseconds (local significance only) and traffic class. Add also a final trailing space.
The traffic sink takes a port number as a parameter and computes packet delay and packet loss (computation of jitter is optional).
Test it with a traffic generation rate of 10 packets per second.
Note that since the generator and the sink are directly connected, the delay, the jitter and the packet loss will will be zero.
In the next assignment we will place a queue in between.
Then these values will no longer be zero.
\begin{figure}[!h]
\centering
\includegraphics[width=\linewidth]{figures/scenario.eps}
\caption{Scenario to test in lab assignment.}
\label{fig:scenario}
\end{figure}
\subsection{Extra challenges:}
Save the inter-arrival time between packets and plot a frequency hystogram.
Verify that you obtain a decaying exponential shape.
Test your programs with other groups programs to verify interoperability.
\section{A queue}
The second module that you have to construct in this course contains a queue (that includes a dropper and a buffer) and a scheduler.
Note that each module has to be a separate program. The different modules communicate (send packets to each other) using sockets.
This program listens at an UDP port and transmits the packets to a given UDP port and address. Consequently, it has to be simultaneously an UDP server and an UDP client. You may consider the possibility of using different threads for the dropper and the scheduler.
All port numbers and the destination should be configurable as parameters. An additional parameter will configure the queue size (number of packets). If the queue size is set to zero, it means infinite queue length. If a finite queue is used, a taildrop policy will be applied.
The scheduler should be configurable to be able to choose an exponentially distributed service time or a deterministic service time. In either case, the service rate should be taken as an input parameter.
Combine the Buffer with the traffic generator and traffic sink modules to make measures of packet loss and delay.
\begin{figure}[!h]
\centering
\includegraphics[width=\linewidth]{figures/scenario2.eps}
\caption{Scenario to test in lab assignment 2.}
\label{fig:scenario2}
\end{figure}
Prepare a plot comparing the packet delay and packet loss obtained from the simulation and theoretical results.
\section{Priority Queues}
The third module that you have to construct in this course contains two priority queues (that include a dropper and a buffer) and a scheduler.
We will name $H$ the high priority queue and $L$ the low priority queue.
Each module has to be a separate program. The different modules communicate (send packets to each other) using sockets.
This program listens to two UDP ports and transmits the packets to a given UDP port and address. Consequently, it has to be simultaneously an UDP server and an UDP client. You may consider the possibility of using different threads for the droppers and the scheduler.
The scheduler strictly prioritizes queue $H$.
That is, it starts to serve queue $L$ only if there are no packets at queue $H$.
Nevertheless, this is non-preemptive priority, which means that the server will not interrupt a service to queue $L$ when a packet arrives to queue $H$.
The server will complete the service to the packet of queue $L$ and only then it will serve the packet that has arrived to queue $H$.
All port numbers and the destination should be configurable as parameters. An additional parameter will configure the queue size (number of packets). If the queue size is set to zero, it means infinite queue length. If a finite queue is used, a taildrop policy will be applied.
The scheduler will draw service times from an exponential distribution.
\begin{figure}[!h]
\centering
\includegraphics[width=\linewidth]{figures/scenario3.eps}
\caption{Scenario to test in lab assignment 3.}
\label{fig:scenario3}
\end{figure}
After you have completed the basic scenario take some measures and explain the results.
Then you can implement also a classifier as in Fig.~\ref{fig:scenario3_mod} and take additional measures.
\begin{figure}[!h]
\centering
\includegraphics[width=\linewidth]{figures/scenario3_mod.eps}
\caption{Advanced scenario to test in lab assignment 3.}
\label{fig:scenario3_mod}
\end{figure}
Combine the priority queues with two traffic sources that generate different classes of traffic and obtain statistics of the delay for each of the traffic classes.
Prepare plots combining analytical results and simulation results.
\section{Optional QoS Tool}
In this lab assignment you will implement one ore more QoS tools of your choice.
You can choose any of the tools that we have seen in class, e.g., metering, token-bucket policer, (weighted) RED, weighted taildrod, re-write.
A brief description of each of the tools follows:
\begin{itemize}
\item{classifier:}
It has an input socket and several output sockets (one for each possible class of service).
The classifier checks the class of server marking of the packet and redirects the packet accordingly.
\item{metering:}
It has an input socket and three output sockets.
It uses two token buckets (as described in rfc2698) and it takes as an input four parameters: CIR (packets per second), PIR (packets per second), CIR burst (packets) and PIR burst (packets).
The green, yellow and red packets are sent to each of the three different output sockets.
\item{token-bucket policer:}
It takes two parameters: rate (packets per second) and burst size (packets).
Non-compliant packets are discarded.
\item{ RED}
It takes a rate and a size as input parameters.
The probability of dropping an arriving packet is equal to the occupancy of queue at the moment of arrival.
\item{Weighted taildrop }
It takes a rate and a size as input parameters.
The queue only accepts high priority packets when the queue is half-full.
The probability of dropping an arriving packet is equal to the occupancy of queue at the moment of arrival.
\item{re-write}
It changes the class field of the packet.
\end{itemize}
Another option is to implement queueing disciplines from the ones that we have seen in class (e.g., weighted round robin, weighted fair queueing and deficit weighted round robin)
The idea is that different groups implement different tools.
Keep in mind that in the next (last) lab assignment you should combine your tool and some of your classmate's tools to create a QoS scenario in which different service classes will receive a different treatment.
You may first think about your scenario and then choose the tool you want to implement accordingly.
%The complexity of metering, token-bucket policer and leaky bucket shaper with RED is considerably higher than the other options.
%It is highly recommended that each group implements at least one of these three tools.
\section{Design and evaluate your own scenario}
This is a free assignment.
With all the knowledge gathered throughout the course and all the developed code, you have to invent an scenario and implement some sort of QoS.
You have to include some invented motivation.
As an example, it may be your home network in which your flat mate is downloading a linux distribution while you are playing an interactive real-time online game.
The download is generating one thousand packets per second and is filling the buffers while the game generates only 10 packets per second and is suffering excessive delays.
You can use different combinations of tools that we have seen and developed during the course.
You can try different parameter configurations (queue length, burst size, rates, different kinds of RED, etc.) and report the results obtained with each of them.
Offer an expert recommendation about which is the best solution and why.
You can also combine and use the queueing theory techniques that we have seen in class, if you wish.
You will have to prepare a presentation (5-10 minutes) to explain your classmates about your project (motivation, possible solutions, test plan, etc.).
Additionally, when you have performed all the tests and computations, you will have to deliver a short report (max. 5 pages) detailing your work.
You can also use code generated by other groups.
Include the slides, the report and all the used code in one zip file that will be submitted via moodle.
Make sure to clarify which code has been generated by you and which code has been developed by other groups and re-used in your project.
\section{QoS in Linux}
Run a speed test that measures upload/download speed in your linxu box.
Then install a Token Bucket Filter.
You can use, for example, the following command:
\texttt{tc qdisc add dev eth0 root tbf rate 1000kbit latency 50ms burst 1540.}
Explain the results.
Remove the qdisc.
\texttt{tc qdisc del dev eth0 root tbf rate 1000kbit latency 50ms burst 1540.}
\subsection{Fair Queeueing}
Connect two computers using ethernet.
Install \texttt{iperf} in both computers.
Change the speed of your ethernet interface (as root) to 10Mbps to accentuate the delay suffered by the packets.
\texttt{ethtool -s eth0 speed 10 duplex full autoneg on}
Send a ping from one computer to the other to measure the round-trip time.
Launch an iperf flow that saturates the link.
You can use for the server:
\texttt{iperf -u -s}
And for the client
\texttt{iperf -c 10.80.25.96 -u -b 10M -t 20}
Observe what happens to the ping RTT.
Now, as root, install fair queueing.
\texttt{tc qdisc add dev eth0 root sfq perturb 10}
Repeat the experiment of measuring the RTT with a ping and then launching an iperf test.
What happens?
Is there any difference compared to the previous experiment?
Remove fair queueing.
\texttt{tc qdisc add dev eth0 root sfq perturb 10}
The latest releases of Linux include changes that improve the behaviour of TCP.
Try the experiment using iperf with TCP.
What happens? Why?
\subsection{Changing the DSCP value}
Try to change the DSCP value of packets with a destination port equal to 80 and then observe the changes using wireshark.
\texttt{tc qdisc add dev eth0 root sfq perturb 10}