01.07.2013 Views

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 ...

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!