1
>> Qiang Xu: So I'm here to introduce Qiang Xu to you. Qiang is going to be
giving his interview talk on mobile application performance optimization. He's
a fifth year student, graduating by the end of April, and he's worked on
cellular network characterization and global application optimization, and he
interned with us two years ago, and he's also worked with other people at MSR
to develop 3G test, which when the FCC opened challenge awards in the area of
network measurement applications, and without further adieu, here's Qiang.
>> Qiang Xu: Thank you. Thanks for joining the talk. I'm very happy to be
here today to present my research effort about mobile application performance
optimization through network infrastructure aware adaptation. Unlike some
existing adaptation techniques, ours are more aware of cellular network or
unique characteristics of cellular network infrastructure.
[indiscernible] smartphones have overtaken feature phones on the market of
cellular network device. And on those smartphones, the traffic generated by
those web applications start to dominant HTTP traffic rather than web browsers.
The increasingly powerful and popular smartphone devices do not necessarily
guarantee acceptable mobile application performance. So very often we will use
those applications [indiscernible] with application will be easily interrupted
by broken network connectivity or slow network connection.
You [indiscernible] network performance without utilizing the cellular network
or the computation utilization very carefully. Those applications will have
any consumption, much higher than we expected.
When we see acceptable performance, the performance actually end-to-end
performance, so we know that end-to-end performance is affected by a multitude
of factors. The network device application, the application will all factors
of the performance. For example in network, the routing, the topology, the
naming addressing resolution, all of them will affect application performance.
Beside networks application is affected by the hardware, the software, the
application implementation. There are so many different types of applications,
different type of applications have very different resource utilization
requirements so we [indiscernible] those applications will have different
performance.
In a [indiscernible] applications, they use different optimization, resource
2
adaptation technique so we can see sometimes their performance differs
significantly.
So what we want to do. In our research, we want to improve mobile application
performance. Again, we want to use those optimization adaptation techniques
different from existing or previous optimization techniques. We want to do
something different. We are more aware of those fundamentally unique
characteristics in cellular networks, such as routing restriction issue,
performance variation issue, and radio inefficiency. So the work flow for our
research path, we identify some unique characteristics in cellular networks.
We try to determine, okay, the impact of those individual factors on the
application performance, and when we develop our design, those optimization
techniques, we take those into consideration.
Let's have a look at what has been done so far. In 2011, we have a project
named the Yellow Page. In this project, we identified routing restriction
issue in cellular networks. Then we investigate what the impact of this
routing restriction issue on latency sensitive applications, such as
[indiscernible].
After that, we have a project, NetPiculet, and it follow-up project, and this
project, we identified or reverse engineered some middle box policies in
cellular network, and [indiscernible] impact of such middle box policy on
networking applications. We also have system named AccuLoc, which address a
particular issue faced by cellular network operator when we want to localize
the work performance to lower aggregation levels that just RNC or base station
level.
Very recently, we start work on project named plural routing. We anticipate
that in the future, internet mobility will dominate the future internet, and so
we propose some internet domain routing [indiscernible] internet architecture
features to keep inter [indiscernible] incremental [indiscernible] upon BGP.
Those projects are [indiscernible] network infrastructure.
[indiscernible] we have a project named the 3GTest, and 3GTest, we try to
isolate the impact of different factors on web application. Beside 3GTest, we
have a project named the Proteus. In proteus, we identify the predictability
of cellular network performance in the [indiscernible] of second. Then we try
to see how much benefit we can achieve if we want to leverage such
3
[indiscernible] for realtime interactive applications.
Realtime interactive application is just one type of application. For other
type of application, those are non-realtime. We have infinity. Infinity is a
scheduling framework that schedules uploading and [indiscernible] requests for
applications and take energy efficiency into consideration. You will want to
move beyond optimizing a single application to many applications. We need to
understand, okay, the usage patterns of those application.
So we have a diversity project. Diversity is a measurement, try to understand
the usage patterns of all the applications that we can observe in cellular
networks.
For cellular network operators, if they want to understand app usage, if they
want to identify applications, the first thing they need to do is for all the
network flow, they need to know which application originates each network flow.
So FLOWR is such system that helps some network operators to identify those
realtime network flows to the applications, individual applications that
originate such traffic flow in realtime ways, minimize supervise learning
effort.
>>: How many of your projects primarily compared to the ones that
[indiscernible].
>> Qiang Xu:
>>:
This one, infinity, proteus, diversity, AccuLoc and FLOWR.
[indiscernible].
>> Qiang Xu: For those projects, I'm the lead student. For others
[indiscernible]. For 3GTest, as you know, I'm the major contributor as well.
In this talk, I'm only going to focus on two of them, proteus and YellowPage.
In Proteus, we work on two problems. First, we quantify or we identify the
predictability in the cellular network performance, particularly in a time
granularity of seconds. And then we investigate, okay, how much benefit we can
see if we leverage such predictability for realtime interactive applications.
We know mobile user experience can be significantly rich by those realtime
interactive applications such as [indiscernible], video conferencing, online
gaming, and even potentially popular product based on Head Up Display, such as
[indiscernible].
4
Five years or ten years ago, when we started to use smartphones, Windows Phone,
iPhone, or Blackberry, at that moment, the computation capability or network
technology even couldn't support [indiscernible]. Now, I think or in the
future, such applications will play a more important role. But we know those
applications are very performance sensitive. So let's have a look at how
sensitive those applications are to network performance.
A very common feature has been overlooked by us for those realtime interactive
applications. Those applications can actually tolerate bad network condition
to some degree. For example, they can add forward correction to prevent
information loss. We can adjust dejitter buffer size. We can even vary the
source coding rate to lower down the requirement on the network bandwidths.
But those adaptations assumes that, okay, the network performance, the network
change is somewhat can be estimated or somewhat predictable so that they can
adapt to the performance change. They can do adaptations. If the performance
change is in a arbitrary, then performance degradation will happen. But we
know in cellular networks, performance variation is really high. At this
moment, round trip time can be up to 100 milliseconds. But in the immediate
next moment can be 200 millisecond or even higher.
So let's have a look at some numbers, ways cellular network performance
[indiscernible]. We have a measurement application in the MobiPerf also known
as 3GTest and 4GTest, which was developed in cooperation with Microsoft as
well.
Based on the measurement collected from 300K users in the U.S., we see in 3G
networks, the round trip time is around 200 milliseconds, whereas the
[indiscernible] 150 millisecond. So the variation really high. Even for LT
networks, the performance better, the round trip time is 20 milliseconds, but
[indiscernible] is up to 50 milliseconds.
>>:
You say that 20 millisecond is a median?
>> Qiang Xu:
This is a median, this is a standard deviation.
>>: So these numbers go directly from your 4GTest paper in [indiscernible],
right? Showing there that the median was about 70 milliseconds, and then the
standard deviation was quite a bit lower than 50.
5
>> Qiang Xu: Right, that paper for the 4GTest paper, that paper we measure
using a Verizon phone in our local location, because at that moment, we only
have LTE just for Verizon. And for 4GTest, the application [indiscernible]
from the United States, these things computed based on the measurement from the
U.S. users. One is the local number, one is the overall number.
>>: Okay. My recollection of the graph was that it was covering more than
local tests, but I'll double check that.
>> Qiang Xu:
>>:
Sure.
The first number is a median?
>> Qiang Xu: The first number is a median, and basically the second number is
the standard deviation.
>>: We've actually done a bunch of experiments right here for different
projects [indiscernible], but we did our own thing, and these numbers don't
come out. The numbers we're seeing in Washington state for the [indiscernible]
measurement do not say 20 seconds. They're more in the direction of 17
seconds.
>> Qiang Xu: I think, yeah, I think it should -- those numbers will be for
based on locations. But ->>: But if you present it as this, this is sort of, you know, if you want to
present it and you might want to put some caveats in there.
>> Qiang Xu:
Okay, yeah.
>>: Because a lot of our calculations are based -- a lot of the systems are
based on [indiscernible].
>>: Also keep in mind that the speed test data shows that in the U.S. for LTE,
the median is around ten to twelve mega bits per second on the down link.
>> Qiang Xu: Okay. So that's confirmed to us when we do measurement, it
depends on the location, the data set forth site.
6
So okay. Regardless of the actual numbers, we [indiscernible] still is a
nature for cell networks. And [indiscernible] reliable adaptations for those
performance sensitive applications, for those realtime interactive applications
will always be necessary [indiscernible] real well smartphone device.
So what's problem do we address? We first want to figure out [indiscernible]
predictability of cellular network performance or in other words what
performance metrics are produceable or [indiscernible] predictability they
have. Particularly in the time granularity of seconds, because we want to let
realtime interactive applications adapt to that predictability.
Then beyond that, we position, we want to position the predictability in
applications. We want to see how to efficiently do the prediction in realtime
and how to support those applications with the performance prediction and
eventually how much benefit we can achieve so let those applications have
performance predictions.
There are several challenges we need to address. First, there are so many
hidden factors in the networks or on devices. The network [indiscernible]
level, the load balancing, the resource allocation scheme, totally unknown to
us. Without knowing such information, it's difficult for us to develop some
sophisticated performance model to do the prediction.
So what we do is we do regression trees. We treat all those hidden factors
together as a black box. We use the regression trees to learn the performance
patterns. One of the advantage of using regression trees is [indiscernible]
effort to projecting the performance model or in tuning the parameters.
The second challenge is the cost of learning predictability for realtime
interactive applications. For realtime application, [indiscernible] realtime
constraint, we can do whatever necessary. We can do active probing. We can do
offline training. But for realtime applications, since we know that's the
nature, the [indiscernible] is a nature of the cell network performance, so
[indiscernible] application, we think the prediction has to be continuously in
realtime and lightweight.
So [indiscernible] passively monitor the traffic.
>>:
So are you doing this [indiscernible]?
7
>> Qiang Xu:
>>:
Peripheral.
Peripheral [indiscernible].
>> Qiang Xu:
[indiscernible] actually I'll talk about later.
>>: I know, but the performance you learn, is that specific to a SQL device or
specific to a setup device?
>> Qiang Xu: The performance is actually a performance model. It's not a
limited device. But the scope of the performance model only covers a shorthand
period. So it's not necessary to cover a device at a time. I think I will
introduce later maybe has a better understanding.
So we [indiscernible] the traffic generated by the applications.
[indiscernible] since we are doing a prediction at the time granularity of the
seconds, most context information [indiscernible] in the network should be
fairly stable. So we think the traffic -- the traffic pattern of these
applications at the time granularity should be very stable. That's why we use
passive monitoring, rather than active probing.
But certain challenges that arise to predictability assume that eventually, we
can predict the performance matching fairly accurately. We still need to feel
those applications with the performance prediction. So we have -- we implement
a [indiscernible] to field those applications with performance [indiscernible].
The library name is Proteus.
Let us have a look at what has been observed in previous [indiscernible] to on
the performance predictability. We know resource allocation happens at each
aggregation levels in cellular network, based on the RNC level or the GGSN
level. So [indiscernible] predictable patterns, either resource pattern or
performance pattern.
In the time granularity of hours, there are [indiscernible] patterns in
[indiscernible] which have been observed in many paper, such as sigmetrics
paper in 2011. In a shorter time granularity of minutes, the [indiscernible]
paper and Mobisys from Microsoft as well. We observed that somewhat latency
can be predictable or has some predictability at a time scale of 15 minutes.
In a further shorter time granularity of hundreds of milliseconds, there's an
8
Mobicom paper observe that [indiscernible] tend to stay in the same modulation
rate for hundreds of millisecond. To us, the most suitable [indiscernible]
granularity is second because we are targeting for realtime and captive
applications.
For example, a typical chunk size for adaptive bit rate streaming can be two
seconds. In order to verify the predictability at the second time granularity,
we run some control experiments. In the controlled experiments, we collect the
more than 400 hours -- more than 400 hours of packet trace. It covers three
cellular networks operators, AT&T, Sprint and T mobile. And also,
[indiscernible] it covers Android and iPhone.
We didn't succeed on Windows Phone, because window phone isn't [indiscernible]
or other packet sniffer. We run most of our experiments in Ann Arbor. Some of
them were collected in Chicago. One thing to mention, that we run most of our
experiments other UDP, instead of TCP, because TCP already has contraction
control and the retransmission.
When we do performance predictability, we want to have the maximized visibility
to network performance. That's we rely on UDP.
>>: So the question was, so 400-plus is nice, but can you give us a sense for
the locations. Like did you do them in one spot in both those locations, or
did you do it in both of those cities, or did you do it in multiple
[indiscernible] in those two cities?
>> Qiang Xu: Yes, for each location -- for Chicago, we do just at one spot.
For Ann Arbor, we do at several network locations. For example, office,
apartment, library. We did collect several ->>: So you did like five, seven locations.
locations?
>> Qiang Xu:
Not like, 20, 50, a hundred
No.
>>:
Okay.
>>:
Did the location move during the one-hour trace or was it stationary?
>> Qiang Xu:
[indiscernible] some packet trace when they are moved, but when
9
the -- when we do experiments, it's been lasting for a while. We need to power
supply during [indiscernible] it's difficult. We do experiments in stationary
condition.
This is a quick evidence showing the performance predictability at time
granularity of seconds. So we -- here, we're showing the distribution of
[indiscernible] correlation coefficient. The correlation, we compute the
correlation at this moment through the [indiscernible] at this time moment, the
correlation between the [indiscernible] like say [indiscernible] seconds ago.
And T is a time lag. So given a time lag, we know that [indiscernible]
coefficient [indiscernible] since we have so many flows, we have distribution
for each given time lag.
And we show the distribution based on percentile values. Apparently, somewhere
around one second, we can see the [indiscernible] correlation coefficient is
nonzero. But we move the time lag to 20 seconds, the other correlation
coefficient is [indiscernible] hard to tell.
So one nice thing we learned from this figure, that the performance, the
[indiscernible] performance is highly correlated with the performance, the most
recent performance. But for the history, say 20 seconds ago, the correlation
is already weak to tell. That's why I say it's not specific to a location
because I just have 20 seconds, the location may now -- the location probably
is [indiscernible] or specific to twice.
So we just do performance modeling at this time granularity.
>>:
So at what [indiscernible] across different time?
>> Qiang Xu: We do different time of day, but later, I will show it's not
actually affected by time of day much. So we think our [indiscernible] choices
collect experiments other different time of day. We didn't specify peak hour
or not peak hour.
>>: [indiscernible] you believe based on this location doesn't matter. And
the reason I disagree with you on that is because I think in conditions where a
signal strength gets particularly poor, or there can be inference from other
devices that are on the same spectrum or [indiscernible] also sort of
contradicts your previous assertion on the numbers on LTE. You were talking
about, well, those previous numbers were from lab experiments and we should be
10
looking at numbers from [indiscernible] experiments. Can you tell us
philosophically why this situation, we should believe those numbers, whereas
when looking at the overall LTE performance numbers, we should focus on a
broader set of data?
>> Qiang Xu: When we, for example, for LTE numbers, we should rely on more
like the lab experiments or the [indiscernible].
>>: Yeah, just tell me philosophically, which is a better choice in one
situation, such as collecting LTE performance numbers and looking at those, and
looking at very fine grain information like this.
>> Qiang Xu: I think [indiscernible] try to optimize for applicant
performance. It depends on [indiscernible] for optimization, it just very
broadly [indiscernible] don't care about, okay, the performance measure is
from -- we probably more care about the performance measure broadly over the
country. We have here focus on that application to granularity is about
seconds. Probably we care more about the experiments [indiscernible] in that
because we see the variation of time granularity, the time [indiscernible] for
variation we see at this moment and next moment so it covers seconds or
minutes.
So probably from that perspective, that, the [indiscernible] is also valuable.
>>: And there is also maybe some logistic difference in these two experiments.
In the past, focusing on maybe ->>:
[indiscernible].
>>: I have one other question. So what is the -- so [indiscernible] packets
coming in [indiscernible] so much of the effect do you see inside these
numbers? Because you've got 0.5 seconds, and this might actually be the way of
scheduling the packets [indiscernible] as opposed to the correlations for
example seeing and that actually depends on how the packets are being sent to
the base station or to the client, right?
So is there a way to parse that out?
>> Qiang Xu: How much contribution of the scheduling in the cell network
affects the overall performance. So I think for 3G, that's definite very big
11
impact. And for LTE, the impact for those scattering is low. But those
[indiscernible] that means when we see the [indiscernible] in cell network, in
LTE networks compared with [indiscernible], it's not the [indiscernible] it
affects the variation.
.
So here, we can actually experiment using counter experiments.
>>:
I'm sorry.
[inaudible].
>> Qiang Xu: They're different types of [indiscernible]. We can experiment
from another 400 packet choice, but you want to make a [indiscernible]
conclusion. We need to figure out the real cause so that we can apply this
conclusion, we can see this conclusion is a common feature in cell networks.
At the time granularity of seconds, we know that the user, the [indiscernible]
level will be -- should be stable, very likely to be stable and we think the
performance is highly affected by the radio resource allocated to a device by
the base station. And the base station allocates the radio station based on
[indiscernible] gathering [indiscernible]. The base station has
[indiscernible] to encourage a device to occupy continued [indiscernible] to
finish the transmission. We did some survey on some [indiscernible] papers and
some base station manuals. We see aggressiveness factor for the base station
to do proportional [indiscernible] gathering is as much as 0.001.
That means a base station encouraged the device to occupy the [indiscernible]
for a certain amount of time and you will do a quick of [indiscernible]
analysis the time for the device to occupy [indiscernible] will be roughly the
time slot for the allocation divided by the aggressiveness factor, which is
0.001. And based on division, it will be 1.67 divided by 0.001 is around one
second.
So that makes us confident on seeing there is predictability performance of
cell network performance.
Once we are convinced about the predictability, we start to design the
regression trees to learn the performance patterns. Intuitively, the
regression tree will be a history window. The performance patterns in the
history predict okay what's the performance in the next time window.
12
And in the history window, we split the time into time window. For each time
window, we know the throughput, the delay, the loss rate. And based on the -based on the performance in the history window, then we predict the last -- the
delay or the throughput. And we also know that the current performance is
mostly correlation with most recent performance rather than performance ten
seconds ago or 20 seconds ago. So we use exponential back off. That means
that [indiscernible] of the regression tree will be the performance in the
previous one-time window, two-time Windows, four-time windows, eight-time
windows or so forth.
To choose sides for the time window or the history window, for time window, we
choose half seconds because we are talking for realtime [indiscernible]
applications. For history window, we choose for 20 seconds, because from the
previous figure, we see the correlation between the current performance and the
one 20 seconds ago is too weak to tell. But that mean those parameters ever
subjective too.
Now we know the design of the regressive tree, we run the [indiscernible] over
all the packets. We want to see what's the performance, what's the prediction
accuracy. Way to prediction and [indiscernible] that means once we can see a
complete history window, which is 20 seconds, we can do prediction immediately.
We value prediction accuracy by comparing the prediction performance matrix
with the actual performance matrix based on the packet trees.
To have a baseline of the prediction accuracy, we compare ways to adaptation
solutions. One is AD-1 and AD-2. AD-1 always estimates the performance of the
next ten window based on the current one. And AD-2 is less aggressive, is
measuring the performance of the next time window based on the average of the
history window.
So let's see the prediction accuracy. Here, they're showing the prediction
accuracy for loss of currents, not loss rate. For loss of cur rents, the
[indiscernible] happens in a time window if [indiscernible] but actually there
is no. We can see the false positive rate for Proteus is consistently low, is
no more than two percent. But for other true solutions, for AD-1, it's up to
20 percent. For AD-2, it's even up to 80 percent. Actually, this is expected
because for AD-2, it's assuming the current performance based on the
performance -- the average performance and history. But we know the
performance correlation between the history performance such as ten seconds or
20 seconds ago is already too weak.
13
Similarly for false negative. Proteus is here. It's a little bit overlapped
with AD-1, AD-2, and false negative is still consistently low, it's one to two
percent. It's also the best.
Besides [indiscernible] prediction, see loss occurrence, we can also predict
the exact numbers for [indiscernible] loss rates and delay. The exact numbers
can help application to adjust like see full error correction.
>>: I have a question about the previous slide.
right-hand side of the graph.
>> Qiang Xu:
So the blue line on the
This one?
>>: Right. So false positive rate for that is like almost 100 percent.
that mean that there's some kind of negative [indiscernible]?
Does
>> Qiang Xu: I think [indiscernible] for this figure, we see that the
performance at this moment, the correlation between the performance at this
moment and this moment is too weak to tell. So that's [indiscernible] estimate
performance based on the actual history. That will be really inefficient. So
the correlation is almost zero. So that means even we do estimation, just the
naive estimation, we still need to look at a very short time window.
Otherwise, it won't be helpful.
>>: I think the point is that if the correlation is zero, you expect it to be
50 percent.
>>:
Exactly.
>> Qiang Xu:
>>:
Let me see.
50 percent.
When you predict, you will have 50 percent of false positive rate, right?
>>: I think what's missing, so you haven't defined here what you mean by false
positive. Do you mean, is it an accurate prediction if it's within X
milliseconds of what the true legacy is? What's your definition of false
positive?
>> Qiang Xu:
I think --
14
>>:
Does that mean that it has to be exactly correct?
>> Qiang Xu: I think it's want to be 50 percent. It will be 50 percent if
quantitatively predict the loss rate. But you do the prediction for the loss
occurrence in the time window. See, if there is one pack loss or two pack
loss, we always consider it's a pack loss. So in that's case, that's where
we're 50 percent, which is pretty -- a loss occurrence is now 50 percent.
>>: What's apriori, I mean, what's the probability that the loss just occurs
without giving it any information?
>>:
[inaudible].
>> Qiang Xu: Here I also want to mention that loss rate is actually not the
loss rate based on packets. It's the loss rate based on window. So that means
for this given time window, there's pack loss. We can see there's loss. So
this pack loss is actually higher than the loss rate based on number of
packets. Also, this is also one reason why this false positive rate is not
like you said, 50 percent.
So this figure I want to show the binary prediction, I can quantitatively
predict like that number, for like set numbers, I use [indiscernible] as
example so for each throughput, I only show 15 flows in the figure by random
sampling. Otherwise the figure will be very unclear. So for each flow, it
show the average throughput on the X axis, and since a flow has so many time
Windows, we show the average error [indiscernible] of the prediction arrow.
Which you can see the performance varies a lot, from 100 KBPS to 800 KBPS. But
the prediction error is still very stable, it's around 10 KBPS with standard
deviation of 10 KBPS.
>>:
Sorry, can you tell me, that for LTE, right?
>> Qiang Xu: This is for 3G.
don't have LTE yet.
>>:
When we did the experiments in our location, we
I see.
>> Qiang Xu:
But we did some quick experiments.
We found for LTE, there's
15
still predictability. I just explained because there is a base station
scheduling, but the time window set and [indiscernible] will be different.
>>:
Can you explain what the error part is on each measurement?
>> Qiang Xu: Oh, the error parts, so for one flow, there are so many time
Windows. For each time window, we have a prediction. So aggregating all the
time Windows, we have a distribution of the prediction error, the average, the
median or the standard deviation. So for each flow, I show one bar. This is
the -- this is the average and standard deviation and the X axis, I'm showing
the average throughput of the flow. I want to show over so diverse network
condition, the performance prediction is stable.
>>:
[inaudible].
>> Qiang Xu: Um-hmm. The prediction errors, not prediction values, will
predict away the actual one. Because we have the package trees, so we know the
actual performance.
>>: But the error bars are on the prediction, not the actual measured
comparison.
>> Qiang Xu: This is -- the error is using the predictive [indiscernible] the
actual throughput and we see the difference, not just [indiscernible]. So we
show the difference here and then we show the average of the difference and the
standard deviation of the difference.
>>:
[indiscernible].
>> Qiang Xu: Actually, not for each throughput value. For all the flows, we
have different throughput value. It will be distributed over the X axis. But
I only show 15 of them to make the figure clear.
>>:
it?
What is the flow? Are they different flows, are they the same?
How are you generating the packets?
>> Qiang Xu:
>>:
More than 400 packet flows [indiscernible] experiments.
They're all different?
How is
16
>> Qiang Xu:
>>:
Do you know how to categorize the flows themselves.
>> Qiang Xu:
>>:
They are different because of different time of day.
How to what?
I'm sorry.
Categorize the flows, how fast [indiscernible].
>> Qiang Xu: Oh, yes, [indiscernible] you mean. It's actually difficult.
Like for gap, previous gap, once gap run over [indiscernible] probing to ask me
the network bandwidth, then UDP. We do very similar thing. At each -- before
each experiment, we run a short time TCP to roughly estimate what's the network
condition. Then we send UDP at this sending rate.
>>: Were you able to figure out a certain characteristic of flows that use
whatever error bars versus others, or is it just all over the place here?
>> Qiang Xu:
>>:
Can you say question again?
I don't understand.
So if your flows are different characteristics, right?
>> Qiang Xu:
>>: Then when you measure all this stuff, it may be different because, again,
if the queues are filled up or they're not filled up, depending on how fast
[indiscernible] responding so you need to sort of say this is the kind of flows
which achieve these are the kinds of errors versus some other kind of flow
achieves certain other kinds of errors. [indiscernible] all the flows are very
much pretty similar to one another, in which case we can actually look at these
bars and say okay [indiscernible].
>> Qiang Xu: Yes, I think for all those flows, those flows have at different
time, different location. That's why distribute -- they distributed over the X
axis. They have different characteristics definitely. But we also show that
in terms of different characteristics, the prediction error roughly -- the
prediction, the error of the prediction in terms of error rate [indiscernible]
roughly the same. Roughly stable.
We just introduce how to build, how to construct regression trees to show the
existence of predictability and prediction accuracy of [indiscernible] trees.
17
So next I'm going to show how to leverage such predictability in applications.
First, the way you [indiscernible] to add sequencing information, because for
regression trees, so important information to compute performance matrix. It's
a packet of sequencing and timing information. If a sender want to send XYZ to
a receiver, the XYZ through the wrapper, we add a sequencing and timing
information over the network. The receiver [indiscernible] wrapper will see
the sequencing timing and track the sequencing timing to the regression tree
and extract the content for the content of XYZ to the application.
This is a very reasonable design to [indiscernible] sequencing and timing
information. We think this way probably is applicable to most type of
applications. So we think this solution can potentially maximize the
applicability. And once the regression tree has the packet sequencing and
timing information, it feeds to the application.
The application, for example, can adjust the jitter buffer size and also send
other information to the sender side. So the sender will get the, for example,
the [indiscernible] error correction, for example, to the adaptation.
And we know that many sensitive applications already include sequencing or
timing information. So we extend our solution, it will be as well. For
those -- now those applications have sequencing timing information. Why don't
[indiscernible] applications feed the regression tree with the sequencing and
timing information. This way, it minimize the overhead of without bothering
the [indiscernible] wrapper.
Very recently, we realize that many those applications, realtime interactive
applications use RTP. RTP already has sequencing and timing information, and
so we can easily locate those sequencing timing information just using
[indiscernible]. And using [indiscernible] the application just send and
receive as they were without knowing Proteus library. [indiscernible]
performance prediction from the Proteus library. So we think the very recent
design potentially maximize the transparency to applications.
Now we valued the benefit of such predictability using video conferencing.
Video conferencing application does two things. First, it collects a
performance prediction from different prediction solutions, like Proteus, AD-1
or AD-2 while ensuring that these were comparing across the different
prediction solutions how to guarantee the natural condition is the same.
18
Once it get performance prediction, it adjusts a source coding rate, the
forward error correction and the dejitter buffer size to make performance
adaptation. [indiscernible] our approach we can't use H.264 reference software
to achieve that. But currently, there is no such open course platform for open
source encoding/decoding platform for mobile.
So we did three things to address those issues. The goal is to achieve
equivalent mobile video conference [indiscernible]. First, we modified the
H.264 reference software to enable per frame adaptation. That means for each
frame, we can adjust the source coding rate, the amount of FEC, forward error
correction and the dejitter buffer size.
Then we modify the H.264 reference software on a laptop. This is
[indiscernible], actually. We run it on laptop. In order to guarantee that
different solution, different predict solutions have the same -- have
reproducible natural conditions, we replay those 400 packet [indiscernible]
with dynamically encoded content over a different prediction solutions. Let's
see how we do that.
This is example of the original packet trace we collected in our
[indiscernible] experiments. In each packet, we have a sequence number time
stamp and the random place holder, random content in the packet. On the
receiver side, we periodically, the receiver periodically send those place
holder packet. In our experiment, those place holder packs are some random
values.
But in our evaluation, we refill those place holder packets with the predict
loss throughput or latency using different prediction solutions.
On the sender side, once they see a prediction packet, it compute the source
coding rate and the forward error correction accordingly and color the frame
according to the source coding rate. Then replace a content of those random
content with a newly encoded content. So we can evaluate the perceptual video
quality on the receiver side. This is a quick example, visual comparison
between Proteus, AD-1 and AD-2 and also TCP. I'll explain later how we compare
with TCP.
This is a quantity comparison where you use fifth percentile PSNR to show the
perceptual video quality. And similarly for each flow, we have a distribution
19
of PSNR. We show the fifth percentile PSNR because we think it reflects user
[indiscernible].
We can see for Proteus, and OPT means hypothetical optimal. They are very
close, hypothetical optimal is that at this moment, always know the performance
in the next time window so I can add forward error correction. I can adjust
the dejitter buffer side and adjust source coding rate. You can see they're
almost identical, just slightly worse.
Definitely is much better than 81 and 82. We also compare with TCP, but there
is an issue, how to guarantee the same network condition between TCP and UDP.
What we do is for each TCP flow, we found -- we try to find the most similar
UDP flow based on average throughput. Then we show on a figure to compare
different solutions. For TCP, it's even worse than the case without
performance prediction. That's actually well known. It's roughly 20 DB.
The previous fifth percentile PSNR ->>:
So how do you determine the network is the same across --
>> Qiang Xu: I cannot ensure for TCP and UDP. For each TCP flow, I try to
find out which UDP flow is similar to the TCP flow. So I based on average
throughput.
>>: Yeah, but for the UDP flow, how do you make sure the network condition
across different 81, 82 or [indiscernible].
>> Qiang Xu: That's how we do here. Wait for different prediction solutions.
This original packet tracing, original packet we have place holder packet.
Those are place holder packets field weights random values at the very
beginning. But one way to prediction, using different prediction solution, we
reveal those packet with the performance prediction.
>>: But this is not running on the real mobile network?
controlled experiment; is that right?
This is under some
>> Qiang Xu: This is controlled experiments because we want to guarantee same
network conditions. So we replace those packet of trees, [indiscernible]
previously and see over those packet trees how much benefit we can achieve.
20
>>:
Have you run the experiment on real mobile networks?
>> Qiang Xu: On real mobile networks, there's another difficulty. It's the
encoding/decoding stuff don't work on mobile platform. Currently, it only
works on desktop. We tried to cross compare that. We didn't succeed.
>>:
What about with USB [indiscernible]?
>> Qiang Xu:
>>:
With USB [indiscernible], that's possible.
Can you run this over --
>> Qiang Xu: We can run this over the USB dongle, but the that we cannot
guarantee same network condition. We can see we received the video quality.
We received the video.
>>: But if your scheme is better than [indiscernible] prediction, then if you
run it over enough time, you should see a statistic difference, significant
difference between the two.
>> Qiang Xu:
>>:
Yes.
[indiscernible].
>> Qiang Xu: Just very simple task.
experiments to show.
We don't have enough number of repeated
>>: Running your experiment is not much different from running
[indiscernible]. You just run it for some time or some location and repeat it
over different time of day. You should be able to see something
[indiscernible].
>> Qiang Xu: Should be. Actually, if there is no -- if there is no such
limitation of running those encoding/decodings on mobile platform, definitely
we will do that. Just so there is no such thing on mobile platforms. So we
think just why don't you just let using packet of trees to show the comparison
across different prediction solutions.
The fifth percentile show more like the quality, video quality affected by
loss. That means the predict loss is lower than the actual loss. So we lost a
21
frame. Then
overestimate
correction.
resource and
FEC overhead
we see bad video quality. We also want to show how -- if we
the, say, the packet loss rate, we add more forward error
Here we add more forward error correction, it wastes network
energy definitely. So we want to show -- we want to compare the
due to overprotection.
The bottom part is actually the necessary forward error correction you need to
add to prevent information loss. And the top part is showing the additional
forward error correction. For Proteus, it's around 5 KBPS. For the other two,
roughly you can tell, 20 KBPS. Even higher.
So in Proteus, again, we did three things. We first to verify or confirm the
predictability of cellular network performance at a time granularity of
seconds. Then we design the Proteus to provide applications with performance
[indiscernible]. Then we evaluate how much benefit we cannot achieve by
leveraging such performance predictability. It's almost identical to
hypothetical optimal. It's a little over estimated because we replayed a trace
rather than do the computation on mobile device. And we compare with existing
adaptations solutions in terms of PSNR. We have 15 DB improvement.
>>: When you say prediction accuracy delay, what are the error bars on the
delay and is the loss there the loss rate or just whether you lost the packet
in that?
>> Qiang Xu: Here I show the result based on loss of current. That means for
100 time windows, for 98 of those time window, we can predict any packet loss
or if there's no packet loss.
>>:
For each time, it was a half second?
>> Qiang Xu:
>>:
For each time, we know it's a half second.
What about delay?
>> Qiang Xu: Delay is similar thing. Delay is higher than the human tolerable
delay. 115 milliseconds. Then we can see, similar to loss, we consider false
positive and false negative. Also, we can quantitatively predict those numbers
as well. But just here just show the binary prediction.
22
>>: So if you were trying actually predict the loss rate, how would these
numbers look?
>> Qiang Xu:
You mean quantitatively predict the loss rate?
>>: Yeah, so rather than not predicting a binary, yes, there won't be loss,
there won't be loss in a half second window ->> Qiang Xu: It will be very close to the actual loss rate. That's why from
this -- from the previous figure, we say it's almost identical to the
hypothetical optimal. Otherwise, it will be lower than the blue points.
The second project I'm going to quickly introduce is YellowPage. In this
project, we identify the routing restriction issues on cellular networks. You
may already know at this moment, but at that moment, it's unknown to most of
us. And we investigated the impact of such restriction issue on latency
sensitive applications such as [indiscernible].
The motivation for the project is actually from the observation about cellular
network -- cellular IP dynamics. This figure is showing this observation. So
for all those blue points, it's showing that your location of a single cellular
IP address. You can see the single cell collar IP address to your location
over time can cover the entire southeastern part of the United States.
In comparison, we plot the location of internet IP address, it's limited to a
pinpoint on the map. So we want to figure out what's the reason for the
cellular IP dynamics. And we think this may affect those typical IP-based
applications on the internet.
So let's review the cellular network infrastructure. This figure is showing
the important network elements along the path from a smartphone to the
internet. The base stations are RNC and GGSN. According to 3G PP, GGSN is a
Gateway for -- it's a first IP hub from the -- on the path from the smartphone
to the internet where IP allocation happens as well.
So we think there must be something related to ways GGSN results in the
cellular IP dynamics. So to specify our problem, we want to determine the
internal of cellular network infrastructure, starting with inferring the
placement of GGSN inside of cellular networks and we expect this will be the
23
root cause for the cellular IP dynamics. Then we investigate the implications
of such routing restriction issue in cellular network.
>>: So by placement, do you mean where, like, where geographically does GGSN
start or could it be topologically where ->> Qiang Xu: Actually, it's not important where exactly location of the GGSN
placement. We are more care about the network location of those GGSN so we
know how it affect the network applications for IP-based application.
So placement is not a physical, physically placement.
>>:
Wasn't this working with the folks at AT&T?
>> Qiang Xu: We had some observations. We confirm with AT&T. But we -- the
solution we propose didn't rely on AT&T's information or other carrier's
information.
So we have the challenge comes from two aspects. Limited visibility and IP
dynamics. In terms of limited visibility, one way -- so [indiscernible] want
to discover the internal of network we do trace route. We do trace route from
device on internet we found most of the -- most of the hubs is just private IP
address with large host name or domain information, which is difficult for us
to infer [indiscernible] information.
In the reverse direction, we do tracer from the internet to the phone.
often, the probes are blocked by the [indiscernible] in the middle.
Very
Another [indiscernible] solution that okay, I have a cellular device. I term
which base station connects with my device and then which RNC connects with
those base stations. Eventually, we know which GGSN connected [indiscernible]
RNCs based on the propagation. But this -- those lower aggregation levels,
those are transparent to us. Those are [indiscernible] information for a
cellular network operators, we don't know.
The second challenge aspect is IP dynamics. In our experiments, we want to
control IP address to do some experiments, but we see for a while, or even with
the [indiscernible] we will lose the IP. It will appear as somewhere far away.
We don't know.
So our solution to that, we consider geographic coverage of IP.
It's a
24
side-channel. We expect that those IPs where it's the same geographical
patterns or same geographical location distribution should be highly likely
allocated or managed by the same GGSN. So the question say that if we can
determine the geographic coverage of each cellular IP address, then we can
roughly infer the placement of those GGSN. So the question is how to determine
the geographic coverage of IPs.
We use two [indiscernible]. One [indiscernible] is a location search service
named YellowPage. It's very similar to Yelp. On the server side, we know that
the IP address of the HTTP request and the GPS location of the request.
The second dataset is 3GTest. No need to measure. It collects some, like the
carrier information, the IP address of each time the user run our experiments.
Then how to infer a GGSN placement based on geographical coverage. We think
there should be some correlation between the GGSN placement and the geographic
coverage. So once we know the geographic coverage of IP address, we group and
cluster them to figure out some patterns of those Joe graphic coverage. Then
[indiscernible] GGSN placement. I'm going to show some examples.
First, let's see how do we determine the geographic coverage of those cellular
IP address. In terms of number ->>: Can I ask a question about [indiscernible]. As I understand the top box
in ivory, you're saying that you expect that the IP for any -- that the devices
using for any given communication, as viewed from the public internet side, is
going to depend upon where the device physically is located in the
[indiscernible]. Is that what your claim is for all communication on the
internet?
>> Qiang Xu: We think, okay, for one IP address, it can be allocated to so
many different devices. So for each IP address, then we can have geographic
distribution for geographic coverage.
>>: Right, but are you saying that the device will always use the same IP
address?
>> Qiang Xu:
No.
>>: Depending on where its geographic location is? Or does it -- what I'm
questioning is there doesn't seem to be anything in there about who it's
25
talking to. Do you see that the -- for a given device if I'm here right now
and I try to connect to, say, some website in California versus some website in
Florida, am I going to be using the same IP address on the public internet for
both those communications, or might I go through some different egress point
into the public internet that allocates a completely different IP address for
that communication?
>> Qiang Xu: I think you will be allocated by the same Gateway. But if you
use a device, you see communicate with the server in Washington and a server
say at Michigan, over a very long time, the IP address may be different.
>>: I have the same issue in at light. So technically, you can have different
IP addresses. So for each phone, you can have different classes of service
that are essential to find by the APN settings. So you can have multiple APNs
tied to each 3G or 4G connection, and those can technically be served by
different GGSNs. So you could contact different services out on the internet
via different IP addresses. So I think your point is valid in that in some
situations, that can happen. I don't know whether the U.S. operators actually
do that. I do know they have multiple APNs, but I don't know if phones -- I'm
not aware of any phones in the U.S. that connect to multiple APNs
simultaneously. There are international ones that do that.
>>:
[indiscernible].
>>: Yes, so that was my second question is basically, is there an assumption
here that all GGSNs offer the same APNs that the provider has? Because I know
technically, you can have, talking about three APNs, you can have some GGSNs
serve APNs one and two, other ones that serve two and three, and so you may not
necessarily have this correlation, direct correlation between geographic
location of users and what [indiscernible] IP they're likely to be served out
of.
>>: I believe there is a service where APNs can be given to some corporations,
right?
>>:
[indiscernible].
>>:
In which case you would see the kind of results, I think.
>> Qiang Xu:
I think first I need to clarify that, how to define GGSN.
If
26
GGSN just a single machine, then it's right, so different APN should probably
go to different single machines. But if you see GGSN probably as a cluster of
machines. It's serving same, roughly the same geographical area, then you can
consider them together as the same GGSN cluster.
So in that case, you have different APN profiles, although you connect to
different GGSN individual machines, but still you are [indiscernible] the same
GGSN cluster. They definitely, with the design system, we want to isolate the
functionality of different GGSN machines. Some of them may serve one APN, some
of them will serve the other.
>>: That's within the datacenter, right? I mean, it's still a valid
configuration to have GGSNs or cluster GGSNs in one datacenter serving a subset
of APNs and GGSNs in another datacenter serving and potentially overlapping the
different set of APNs.
>> Qiang Xu:
>>:
You mean at the same time?
Yes.
>> Qiang Xu: At the same time, it only happens when there is some specific
service, because there's still some motivation for a device to keep IP
addresses. In that case, even if you move to another location, you're still
talking to a regional goodness. That's probably happened in roaming. In other
words, also another aspect of load balancing, sometimes the -- at this moment,
the IP address may be allocated -- managed by one GGSN. In the next moment, it
may be managed by the other GGSN. So you will take time domain into
consideration.
>>:
[indiscernible].
>> Qiang Xu:
>>:
Is that more than ten or less than ten?
>> Qiang Xu:
>>:
That's what I'm going to answer.
It's less than ten.
For AT&T, it's four.
Yeah, so it [indiscernible] in the last few years.
>> Qiang Xu:
It's difficult to change, actually.
You can imagine the need to
27
set up a very big data center to serve all those RNCs.
>>:
A datacenter is not --
>> Qiang Xu: I search on line for like Cisco, you may provide such GGSN
machines. It's not that large, actually. It's more than we expected.
>>:
So I heard [indiscernible] expanded significantly in the last two years.
>>:
I have been told they expanded from the four that --
>> Qiang Xu: I think that's probably one reason they want to acquire T-Mobile,
because if they acquire T-Mobile, they can share the network. They will
combine those centers together to share common network resource.
Anyway, I'm going to speed up. So how to determine the geographic coverage is
the first question. So we have a location search service. We have to serve -we have to [indiscernible] from the service side for each IP, for each
[indiscernible] request, we know the IP address and we know the location of the
HTTP request. In terms of number of [indiscernible] for each single IP
address, it will be small so we aggregate the IP address in the [indiscernible]
using [indiscernible] and it gave us a [indiscernible] prefix. So the first
dataset we have for each [indiscernible] prefix, we know a couple of GPS
locations. So for each [indiscernible] prefix, we know the geographical
coverage.
Also, similarly, we know the carrier name because it has -- the application has
that information. So for each prefix, we know who's the carrier. And we carry
those things to immediate [indiscernible] table together for each carrier, we
know at least the [indiscernible] prefix and the coverage the BGP prefix.
So the next question is how to infer this GGSN placement based on the
geographic coverage. Here, I show some examples. Clearly, in the top two
figures, those two figures, those two 24 address box share very similar
geographic coverage. They're almost identical covering the eastern part of the
U.S. And for the bottom two, they share another geographic coverage, covering
the southeast part of the U.S.
We looked at our entire dataset, we see there are only limited, say four or
eight geographical coverage over the southern BGP prefix. So intuitive
28
solution here that why don't we just cluster those BGP prefix based on
geographical coverage. So we think the [indiscernible] cluster them, we can
see which, probably which GGSN covers which -- accounts for which BGP prefix.
So we do clustering. I'm going to skip the details how we run those clustering
algorithm, how we tune the parameters. But here I'm showing an example using
AT&T. For each cluster, we aggregate the geographical coverage of the BGP
prefix using a cluster. We can clearly see that one covering the western part,
one covering the south part, one covering the south eastern and the eastern
part.
For AT&T, there are four GGSN clusters. For other carriers, there are roughly
the same number. For T-Mobile, six. For Sprint, eight. And for Verizon, six.
So this means that every time we set up communication between our mobile device
for remote server, it goes through some GGSN which is far away, then reaches
the content server. This is the routing restriction issue.
We validate network clustering through full method. I can give one example.
For example, [indiscernible] patterns. For the BGP prefix, [indiscernible]
covering the western part, we count the number of [indiscernible] for the BGP
prefix, we can see a pattern and we do the same thing for the BGP on the
eastern part. Clearly, we see they are offset.
We also use address solutions to validate our clustering result. Next I'm
going to focus on the implication of such routing restriction issue on latency
sensitive applications, such as CDN.
For CDN, a very important decision for the design is where to place a content.
There are several options. We can place content in radio access network. I
know some of the top companies are working at this. But it requests
infrastructure support, because inside the radio access network is lower layer
than IP. And the second option is to [indiscernible] cellular [indiscernible]
cellular IP networks. It request approval from cellular network operators and
that's why currently, cellular network operators are doing their own content
CDN service.
For [indiscernible] CDN server providers, a cost effective approach may be just
[indiscernible] with GGSN. But intuitively, we know the latency is most likely
decided by the wireless part. So you will place the content close with GGSN,
29
the benefits may be very trivial.
So we want to see how much the benefit is.
We do some experiments. In 3GTest, we send a probe to the first IP hop. Then
we send a probe to 20 landmark servers. For those 20 landmark servers, we use
the one with the smallest latency. And we compare this smallest latency with
GGSN. Here, this is a compare -- this is showing the distribution of the
difference. We can see even place content close to GGSN, we can roughly have
six milliseconds benefit. The six millisecond, when we did the study, it's
very trivial, because it's 3G -- in 3G, the [indiscernible] round trip time is
100 to 200 milliseconds. Six milliseconds is too small.
But in current LTE networks we know the latency is reduced significantly. The
six milliseconds may be nontrivial if we consider [indiscernible] GGSN.
Because there are so many GGSNs, there are so few GGSNs, we just need to place
content close to, for example, four locations. We don't need to consider other
locations. So this can be a cost effective approach.
The second thing that we know there's some inconsistent issue between the
network location and the physical location. If we place a content physically
close to those users, to those devices, we may -- it may be non-optimal so we
compare the latency to the first IP hop and the latency to the geographic
[indiscernible] land mark server and we show the difference.
Placing content close, geographically close to users, it will result in roughly
nine milliseconds additional latency. Again this latency may be considerable
for LTE networks.
So in conclusion, in this work, we identified the routing restriction issue in
cellular networks.
>>: On the previous slide, can you explain why this would ever matter? I
mean, it would seem that the topology closest network, the one that's got the
fastest connection to the GGSN would be more important than what its physical
location is.
>> Qiang Xu: In the [indiscernible] networks, there's a proximity between the
network location and the physical location. So sometimes we simply place a
content as ->>:
I'm saying the wire or wireless?
30
>> Qiang Xu: Wire LAN internet. There is a proximity between the network
location and the physical location. So if we still place content, similarly
just based on the physical location, it will be non-optimal.
>>: I'm still missing, it seems to me that the difference between this slide
and the previous slide is simply showing that the connectivity of the landmark
servers to the GGSNs doesn't exactly correlate to where they're physically
located but rather correlates to what their quality of network connection is.
>> Qiang Xu: This figure is not showing the quality of the network connection.
This figure see we have 20 landmark servers. We do probe to those 20 landmark
server. Some of the landmark server is geographically close to the cellular
device. So we see, okay, for this latency, we compare the latency to the GGSN.
How much is latency inflation.
>>:
Physically close to the phone, not to the GGSN?
>> Qiang Xu:
>>:
Ah.
Yes.
Well, then, again, why would that ever matter?
>> Qiang Xu:
Because [indiscernible].
>>: Just talking about where the GGSNs -- I mean, you're basically showing
that the GGSNs aren't optimally placed or there's too few of them?
>>:
GGSN [indiscernible] location of the phone.
>>:
I'm surprised the difference is worse.
>> Qiang Xu:
The difference is worse compared to --
>>: I would have expected this graph to look worse, because as we know, with a
relatively small number of GGSNs, you've got a relatively large distance
between where phones actually are and where the GGSN is.
>> Qiang Xu: It should be worse, because for 20 landmark servers, we select
the -- 20 landmark servers, we choose, I think for this figure, for the
previous figure, it should be worse because we do for 20 landmark servers and
31
we select the minimum latency. For GGSN, we just do once. So if you do more
number of probe, definitely you will have a better chance to see smaller
latency.
So we do, say, 20 probes to GGSN, we probably will see higher benefits of the
latency.
>>: So what's the [indiscernible] that you're trying to tell us? Companies
like Akamai already put caches in networks, you know. So what's -- what's
something that you're telling us here ->> Qiang Xu: You can not solve all the problems, right. But at least you have
the motivation to push the content close to the user, as close as possible.
And there are several options. But maybe the cause and effect approach, it's
just a [indiscernible] close to GGSN. If they move the content further inside
a network, it will require some additional overhead. So we see, okay, place
content at GGSN, intuitively, we think the benefits will be very marginal, but
the [indiscernible] part, we still think dominance latency.
Here, we quantify that. We see this benefits maybe marginal to 3G networks.
But in the future, in LTE, it's not necessary the case anymore. And also,
people are thinking about okay, let's move the first IP hop forward to the
device in GGSN because GGSN is too far away. If we use the IP hop forward,
close to the physical device, there may be other chance for us to place
content. Just give people idea of placing content is, not necessarily
intuitive.
The contribution here, we identify the routing restriction issue in cellular
networks concluding that for all those major cellular network operators, they
only have four to eight GGSNs. And we also investigated the impact of such
routing restriction issue, latency sensitive application example as
[indiscernible] network and we think that placing content close to GGSNs still
beneficial for particularly in the future. And the benefits can be nontrivial
in LTE networks.
In other research project, we have some observations maybe still beneficial to
mobile application maybe. For example, for NetPiculet, we reverse engineering
the middle boxes and we found that some middle box policies just too
aggressive. They interrupt the TCP connection very quickly.
32
The interruption to TCP connection will lead to energy waste. And application
performance degradation. Also in the diversity project, we found that after
20 -- the local application, you would consider most of the traffic, most of
the content requires is from certain geographic area. That will be a local
application. We actually found that 20 percent of applications are local
applications. So this brings up the question how to place content to close for
some applicant. There are significant local applications how to place content
further close to those users. Maybe [indiscernible] infrastructure support if
the local applications are significant.
We also observed some applications always use together. We previously often do
optimization on a single application, but it may be non-optimal if we know that
they always interfere with other application. Probably when we do
optimization, we need to take multiple applications together.
We also observed that non-trivial applications are used when the user
[indiscernible]. We know that when user [indiscernible], there are lower layer
events like [indiscernible] and the connection will be not very reliable. So
when we design adaptation or for those application optimization for those
applications, we probably need to take reliability into consideration, how to
do performance adaptation for those applications since they are used likely in
mobility.
We also have a system named FLOWR. This, as I mentioned, it's identify the app
identity of the realtime network flows and either cellular network or
enterprise network if they want to apply certain policies on the app base for a
security issues for, like, user -- for content customization issues. And we
found out 80 to 84 percent of those applications are identifiable without
supervised learning. That's in mobile networks.
So I think overall the contribution here in our research is we develop
optimization for mobile applications, and we also address several challenges
faced particularly by network operators. And for some of the solutions,
require some effort in terms of large systems scaleability issue. And that's
all. Thank you.