Th`ese de Doctorat de l'université Paris VI Pierre et Marie Curie Mlle ...
Th`ese de Doctorat de l'université Paris VI Pierre et Marie Curie Mlle ...
Th`ese de Doctorat de l'université Paris VI Pierre et Marie Curie Mlle ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Utility Function Types<br />
In a multi-application n<strong>et</strong>work environment, different types of utility functions (concave,<br />
step, s-shaped, linear, <strong>et</strong>c.) are envisioned and have been qualitatively <strong>de</strong>scribed in [10, 11].<br />
Applications can be classified based on their nature. Applications that generate data<br />
in<strong>de</strong>pen<strong>de</strong>ntly of the current n<strong>et</strong>work state are called real-time applications. These ap-<br />
plications can be further classified into real-time applications with hard requirements and<br />
less stringent requirements, respectively. The latter ones are called adaptive real-time<br />
applications.<br />
On the other hand, applications that can adapt their data generation rate according to<br />
the n<strong>et</strong>work conditions are called elastic applications.<br />
Traditional data applications like file transfer, electronic mail, and remote terminal are<br />
examples of elastic applications. These applications are rather tolerant to n<strong>et</strong>work <strong>de</strong>lay<br />
and present a <strong>de</strong>creasing utility improvement like that illustrated in Figure 2.1(a).<br />
On the other hand, some applications are characterized by hard real-time requirements<br />
(e.g. guaranteed bandwidth, very low <strong>de</strong>lay and jitter). Examples of such applications<br />
are link emulation, IP telephony, and other applications that expect circuit-switched-like<br />
service.<br />
For applications with hard real-time requirements, the typical utility function is repre-<br />
sented in Figure 2.1(b): while the minimum guaranteed bandwidth is m<strong>et</strong>, the application<br />
performance is constant, but as soon as the allocated bandwidth drops below such mini-<br />
mum, the performance falls sharply to zero.<br />
Traditionally, vi<strong>de</strong>o and audio applications have been <strong>de</strong>signed with hard real-time re-<br />
quirements. However, recent experiments on the Intern<strong>et</strong> have shown that most of these<br />
applications can be implemented to be rather tolerant of occasional <strong>de</strong>lay-bound violations<br />
and dropped pack<strong>et</strong>s. However, such applications still need a guaranteed bandwidth since<br />
they generate data in<strong>de</strong>pen<strong>de</strong>ntly of the n<strong>et</strong>work conditions (like, for example, congestion<br />
events). Thus, the performance <strong>de</strong>gra<strong>de</strong>s rapidly as soon as the allocated bandwidth be-<br />
23