Modeling Quality-Quantity based Communication

1. Modeling Quality-Quantity based Communication Orr Srour under the supervision of Ishai Menache

2. Agenda • The problem • Design motivations • Our model • Simulations • Summary & Conclusions

3. The Problem - QQ Quality Quantity Regularly, price depends both on the quality and the quantityof the desired service. $6 $1 Quantity Quality 0.5$

4. The Problem - QQ While so, networks still suffer from the old fashioned ”one price per all” attitude. Users usually pay a constant price for their bandwidth, regardless to its usage. Same Price (?)

5. The Problem - QQ • Many QoS (Quality of Service) protocols have been recently developed in order to solve the problem above. • We have chosen to use the “Differentiated Services” approach.

6. Differentiated Services • This method simply attaches a quality tag to every packet that is being sent. Three bits in the TOS byte of the IPv4 header are used in order to determine the desired service type for the current packet Differ Normal Urgent

7. The Dynamic Nature Let’s look at two different events: the NBA final playoff game, and the US presidency election results announcement.

8. The Dynamic Nature These events were predictable. What about unpredictable events such as news flashes ? This kind of events cause a dramatic change in the service requests characteristics.

9. The Dynamic Nature Our service supplier should be able to operate under our dynamic world – thus be flexible and rapidly adjustable.

10. Ordinary Basic Server Model • One queue • Incoming packets rate = I [Packets/Time] • Packets handling rate = H [Packets/Time] When I>H overflow occurs. All the packets beyond the server’s capacity will be dropped (ignored) – the “tail-drop” phenomenon.

11. Our Server Model • Our server will be divided into a filter and a buffer. • The filter will be constructed out of several queues, each with its own length and packet-loss rate. • We will use 10 queues in our filter. A packet in the 1st (left most) queue has probability of 0.1 not to be dropped, while a packet in the 10th queue will be handled for sure.

12. Our Server Model • Every packet that reaches the server contains some information about where it should be placed (using Differentiated Services). The server is in charge of spreading the packets between the different queues in the filter. • SPD (Service-based Packet Dropping) is the filtering scheme, used to drop packets according to the queue they are in.

13. Our Server Model Server Filter Ordinary Buffer

14. Our Server Model • Every packet’s allocation decision can be represented as a random variable representing the desired queue. • The type of this random variable will be a Gaussian. • Its standard deviation is announced by the server. • The user is free to choose the center of the Gaussian, and the total amount of packets he sends.

15. A Methodical Break • Where did this idea come from? The roots of this project are the physical variables from the world of statistical mechanics. The work tries to construct the server under certain temperature (1/β) and users with chemical potential (μ). The users try to achieve equilibrium with their environment (the server), just like any physical system we know.

16. Some SPD examples Θ = 0.5 β = 50 μ= 6 Θ = 0.5 β = 11.11 μ= 6 Θ = 0.9 β = 6.6 μ= 3 Θ– The energy of the most probable packet. μ– The quantity descending coefficient (controls the total number of packets submitted to the server). β– The standard deviation of the Gaussian function. Controlled by the user Controlled by the server

17. Our Server Model Packet Arrival Filter: Buffer:

18. Our Server Model SPD: Filter: Buffer:

19. Our Server Model SPD: Filter: β Buffer:

20. Our Server Model SPD: Filter: Buffer:

21. Our Server Model Θ SPD: Filter: Buffer:

22. Our Server Model SPD: Filter: Buffer:

23. Our Server Model SPD: 90% Filter: Buffer:

24. Our Server Model SPD: Filter: Buffer:

25. The User Model Let us model a simple user using 3 properties: • Desired amount of information - the total amount of packets that should pass the server (- not being dropped) [packets]. • User’s link capacity (bandwidth) - the maximal amount of information that the user can transmit per time – usually physically constrained [packets/time]. • Maximal price - the maximal price the user is willing to pay in order to receive his desired energy [energy units].

26. Notations • u - a single data packet. • R – a single user. • E(u) – u’s acceptance probability. • NR(E(u)) – The total number of packets R submits with the same energy E(u). • Price(E(u), NR(E(u))) – the price of the packet u. It is determined by its energy and number of similar packets R sends.

27. Flow of Events Provisioning phase: Construction of the queues Declaration of the price function Runtime phase: Announcement of β Announcement of Θ & μ

28. The User’s Utility Function • Let us define the utility of a user as a variable which is scales independent : • The optimal choice for the user will then become: Etot Uuser = TotalCost [EU/EU] = [1] Etot

29. The Server’s Utility Function • b - the price of 1 unit of capacity space [EU]. • Profits = (payment from users) – (capacity) * b [EU] At the provision phase: During the runtime phase:

30. Relations Demonstrations E vs. β & μ E vs. β & Θ

31. The Cost Function • For methodic reasons, let us choose the following cost function: For low quantity, high price for high energies. For high quantity, high price for high energies & middle energies.

32. Average Packet Price β=0.01 β=0.51 β=7.01 Θ μ β=2.01 β=9.51 β=19.51

33. The Server’s Optimization Simulation • Let us take a look on how the server chooses it’s optimal announcement. • Let us consider the following energy consumption: Average of 500 units of energy

34. Total Number of Packets vs. β

35. Packets Allocations vs. β

36. Number of Users Playing the Game

37. Profits vs. β

38. What If a Sudden Increase in the Energy occurs? Average Energy 800 Number Of Users 1000 Average Energy 300 Number of Users 1300

39. What If a Sudden Increase in the Energy occurs? • Under the right choice of β, the server can handle sudden changes in its demands. • The right choice here means that the total number of packets the server needs to handle does not vary too much, and thus no physical constraint will affect the server’s operations.

40. One Day Game After showing how the server chooses β, let us introduce a simple simulation that will try to estimate the network traffic for "one day”. Different hours of the day will gain different services desires. Let us choose the queues of the server to be 10,000 packet places long each.

41. Game Details • The provider is free to choose it’s price function once, and then change β during the game. • The provider has no energy limits (no maximal capacitance). • Every user has a constant desired energy - the energy he wishes to attain. • Every user has a constant maximal price he is willing to pay for his desired energy. • When the minimal price for the desired energy is more than the user's maximal price, the user stops playing (his energy equals to 0). • The user has a constant maximal capacity of packets he can handle (this is the maximal value of N per user). • The user tries to find the minimal price for his desired energy, and once it is found, he tries to find the highest energy for this price, so that the minimal energy he will receive is his desired energy.

42. Number of Playing Users Vs. Time

43. Maximal Price of 1 Packet vs. Time

44. The Average Total Energy Consumption

45. β During the Day

46. Number of Participating Users

47. Server’s Utility vs. Time

48. Packets Allocation vs. Time

49. Profits vs. Time

50. Summary and Conclusions • In real life, the most general model should allow one user to send multiple requests for services at the same time. • We observed high correlation between the different variables of the problem. Slight change in the average energy for example, as shown before, can dramatically change the number of users participating the game.