-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdiscussion.tex
64 lines (55 loc) · 3.23 KB
/
discussion.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
\tightsection{Discussion on Practical Limitations}
While our results look promising, the magnitude of the improvements
may seem underwhelming. However, we believe that this is not due to
the lack of potential of our approach, but it merely comes down to the
inherent limitations that are typical to any first instantiation of a
radical approach. In the reminder of this section, we consider some of
these limitations which, when removed, will result in much higher
improvements.
\myparatight{Midstream selection} Today, GO makes decisions only at
the sessions' start times. For a long session this can be far from
optimal, as, for example, the quality of the selected CDN may degrade
during the session's lifetime. We are currently working on making the
decisions during the midstream, as well. Note that in this case, the
prediction is equally important, as switching to a new CDN is not
guaranteed to increase the quality, especially if the quality
degradation is due to the last mile or due to the client inability to
render at a high bitrate.
\myparatight{Leveraging network and CDN information} GO makes
decisions based on client side information only. While clients provide
the most accurate information regarding the quality experienced by
users, this information is not always optimal when making
decisions. The decision process can be considerably improved if GO
were to leverage information from other entities in the distribution
ecosystem, including CDN servers, caches, and routers. Using such
information, GO could significantly improve the prediction
accuracy. For example, GO could learn much faster that a CDN server is
overloaded by getting load information directly from that server than
inferring this information from clients that experience quality issues
when connected to that server.
\myparatight{Finer grain selection} Currently, GO selects the resource
at the CDN granularity. This means that GO can't do much if the CDN
redirects the client based on its location (e.g., IP address) and the
servers the CDN redirects the client to are congested. However, if
the client were able to specify the servers to stream from, GO could
avoid the overloaded servers and dramatically increase the
quality. We believe that we will soon have the ability to perform
such fine grain selection, as CDNs are incentivized to expose such
fine grain information to clients. Indeed, a CDN operator will prefer
that a quality impacted client to move to other servers in the same
CDN rather than migrate to a different CDN! Furthermore, an ISP CDN
that also runs its own software on setup boxes or other user devices
would be in the perfect position to run a GO like algorithm that
makes decisions at server granularity.
\comment{
\myparatight{Join network optimization} The decisions made by GO are
oblivious to the network conditions. As such, there is little GO can
do if the network is congested. GO can perform considerably better if,
in addition to the endpoints, were able to select the network
paths. Again, this would make perfect sense in the context of an ISP
CDN where the ISP controls both the network and the distribution
infrastructure.
}
%\myparatight{Behaviore-related attributes}
%\myparatight{Finer granular server selection}
%\myparatight{Traffic load balance}