0:00

If I tell you that you have to wait for a certain amount of time t but then in

Â return, I'll give you a certain reward, p. Then what is the chance that you will

Â wait, that a month of time t, okay? Let's say this is a probability, a

Â likelihood of that you'll be waiting that long for this amount of reward.

Â Now, what this would be, would depends on, the ratio of your price sensitivity versus

Â delay tolerance, reflected in this dependance of these two arguments.

Â So this is what we call a waiting function.

Â Okay? With a little abuse of notation, we use w

Â to denote the function as well, w as a function of t and p.

Â Now this really should be a different function, for different users and

Â different applications. So, if you got, you know,

Â 50 users each got to less on average, 100 applications then you should have, in full

Â generality, four or 5,000 different such waiting functions.

Â But in general, for practical purposes, we'll group them into the similar classes.

Â For example, we'll say that Alice and Bob, belong to the same class or, email versus,

Â Facebook update belongs to the same class. And then we'll have fewer functions to

Â estimate. Now in order to talk more about this, we

Â need to paramaterize this function, w okay.

Â Now, we know that w should be decreasing function in t because longer you're asked

Â to wait, the less change you're willing to wait.

Â 1:36

Should also be at the same time, increasing function in P because the more

Â pricing functions you're given, the higher the chance that you will wait.

Â Now of course, there are many currently infinite number of functions that are,

Â decreasing in t and increasing in p. But one typical and very simple

Â parameterization is through the following form.

Â We say that w as a function of t and p, is simply p / t.

Â Now, this is not the final answer for one thing, the t can be zero, so let's say t +

Â one. Now, second this is not really

Â differentiating between your dependence on p versus t.

Â So one possibility is to get the denominator power beta.

Â So this is a function that it's parameterize by beta.

Â Beta is some positive real number that can praumatize a different concept weighting

Â functions. Now, in general, if you have a large beta.

Â That means that you are not willing to wait a whole lot.

Â If it's a small beta, then it means you are willing to wait a lot.

Â For example, based on our own survey in the US, we found that beta is about 2.027

Â for YouTube streaming. And, beta is the 0.63554 for video

Â download, for example from iTunes, okay. So, this, is much smaller number and

Â therefore reflects a much, more likely chance that it's going to wait.

Â 3:24

So different users, different apps, different demographics and countries, you

Â can have different betas. Of course you don't have to stick to this

Â para, particular parameterization, but this is a fairly simple and quite useful

Â one. And later in the homework one of the

Â problems asks you to run through an estimation of weighting functions.

Â Now, suppose you have indeed run through an a y estimation weighting functions.

Â Now, the second step, after that profiling step, is the price optimization engine.

Â Here, the price can be viewed as incentive or reduction in price or reward of credit

Â to your monthly bill. Okay?

Â So instead of, say, now it's $ten a gigabyte,

Â I'm going to give you a reduction down to $eight a gigabyte if it's really needy of

Â incentive for you to shift traffic into this, say, middle of the night.

Â And maybe $one a gigabyte. Okay?

Â Now, we're not going to presuppose a particular price.

Â This should be discovered through an optimization problem.

Â So, what kind of optimization? As you may recall, we need an objective

Â function, we need different constraints, and we need variables.

Â And the rest will be constants if they're not variables.

Â So, what is our objective function here? For the carriers, there are two kinds of

Â costs incurred now. One is the cost of exceeding capacity.

Â 5:00

That can translate into user turns or the capital expenditure you need to provide to

Â increase capacity and overprovision by the peek traffic.

Â Okay? The other is the cost of reward, meaning that since you are not charging

Â $ten but instead eight or $one, then you are giving away $two or $nine in these two

Â cases respectively, for example. So you got two kinds of cars that you want

Â to balance their sum, and let's say you weighted a sum of them.

Â Eight is the weighting parameter, some real positive number, times the exceeding

Â capacity cost to plus the reward cost. We'll see an example in detail soon.

Â And then the constraint basically is to say that I need to maintain proper

Â accounting of the traffic for each given period.

Â Lets say I've got two periods here okay, period one, period two.

Â The traffic that comes, goes away from period one into period two because of this

Â incentive versus traffic that goes from period two back to period one because of

Â incentives. You have to keep track of those traffic

Â getting in and out of the given period. And the variables are indeed these price

Â rewards. They are going to shape this part, and

Â clearly they define this part of the objective, and they are constrained by

Â your proper accounting rule. This is the optimization problem that

Â we'll be dealing with. Now before we show any examples, want to

Â highlight that there are also many system implementation issues involved here.

Â It's not just a mathematical exercise. As in many of the upcoming lectures in

Â this course. There are quite a few modules that require

Â different kinds of coding capability. For example, we need a graphic using

Â interface, simplest one would be the best, now we have to interface with the IOS and

Â Android, And or Windows if you use Windows Dongles

Â for 3G and LTE. We also need traffic measurement, and also

Â mobility pattern analysis in order to run the profiling engine.

Â We need a computational engines to run the price setting on a very dynamic basis, and

Â we need a database, of course, which could be partially split into your phone or

Â iPads and partially given to the ISP's. Okay.

Â Which part goes here and which part goes here, would, in part, depends on the

Â privacy and security concerns. And you also need, of course, scheduling

Â control software. Some of this may, goes to the end-user

Â devices. Okay?

Â Your phone and tablet. Some of that goes into gateways.

Â For example, in your home, your cable provider may have a residential gateway

Â together with a wifi. Okay? And some of that, control software

Â need to go into the backend usually, the control plane of the carriers, for example

Â we will see later in lecture nineteen something called the PCRF in cellular 3G,

Â 4G networks. Okay?

Â You need software intelligence across all of these points in the network end to end.

Â As you can see, this is a gigantic piece of implementation,

Â Involves many different addiments and kinds of codes.

Â I just want to highlight that. This also says that basically,

Â You've got a network. Okay.

Â This is your network. You've got also end user devices.

Â 9:17

Now, we have run a trial of TDP, in a project called, Data Me here actually at

Â Princeton with about 50 participants. And the same team is now going to launch

Â commercial class with a five commercial carriers, including three of the largest

Â in the US and India. But for this local, Princeton, small scale

Â trial that has been concluded already, what we have observed is that we can see a

Â 30% reduction in the peak average ratio. That is, you chop the peak.

Â Okay, read from the average by 30%. Yet, at the same time, you also see

Â another almost magical thing: 107% increase in the average amount of usage

Â over, say, a day, or week. The key word is that this is average.

Â In other words, not only you chopped the peak, dump it to the valley, but also

Â raise the sea level. Use the metaphor of chopping, say, ice

Â bergs onto the ocean. The sea level also rise.

Â The total usage, or average, over day's usage rises affects more than doubles.

Â Why is that? Well, that's mostly because when people

Â look at the design. Okay.

Â I skipped the graphic using today's interface design, cuz it's really outside

Â the scope of this quarter networking. But one of the implementation gives you a

Â color-coded tab on your home screen. And, people look at the green button,

Â instead of red one, knowing that this is a very inexpensive, a cheap period to use

Â internet. And then, they start to consume more.

Â So, it leads to both a reduction in cost, and an increase in total usage.

Â That translates into, better profit for the carriers.

Â At the same time, it also translates into lower prices, back to the motivating

Â questions for this whole lecture. Lower prices per gigabyte for consumers

Â like you and me. Plus, it gives, actually, as a side

Â benefits, the power to chose between paying more for faster service and paying

Â less to save money, if you are capable of with willing to wait.

Â So that is the win-win created by such a TDP trial.

Â And I just want to illustrate one more time this solid line is.

Â The traffic over a 24-hour period, without TDP.

Â And the dotted line is an example of what you get with TDP.

Â So you can see, it makes this up and down less dynamic.

Â The ideal case you want it to be straight line.

Â And say, under the area, under the curves of the same area, let me convert that into

Â straight lines, so that the area under the straight line is the same as before.

Â 12:36

Now that will be the ideal, but up close, in order to achieve that ideal the rewards

Â be very high cuz you have to take away a lot of time sensitive traffic.

Â And the objective function may say that you know, a times the cost of eExceeding

Â capacity may not be so heavy that it means that you can send out any reward that's

Â also a cost term. So the balance between these two cost

Â terms will determine how flatten you want to make this traffic profile look like.

Â In other words, if I increase this constant a, the weight in front cause

Â exceeding capacity relative to the cost of sending our rewards.

Â If I increase that a, then this will be flatter and flatter.

Â So how can I describe how flat it is? One possible quantitative metrics that if

Â I look at the straight line, and then look at the difference between this line and

Â one traffic curve. Say, the one before TDP, okay?

Â In absolute value, so this will be counted to size this, and this will be counted.

Â Okay. You add up those error differentials, we

Â call that residue spread, okay. The spread between, peak and valley.

Â Then, the residue spread should be a decreasing function of the capacity weight

Â eight. In fact, on plotting on log scale here you

Â see that indeed, as a becomes heavier and heavier weight, ISP has one more incentive

Â to reduce the spread and you see actually, in this particular example, at least, a

Â very sharp drop off, the cliff behavior. Now, what exactly should a be?

Â That, I don't know. There's no universally correct answer.

Â It depends on the actual cost structure again which is very proprietary sensitive

Â commercial secrets of different carriers. But the general methodology is as we just

Â