17216
>>: Jin Li: It's our great pleasure to have Professor Keith Ross to
come here and give us talk again on the Advances in P2P Live Streaming.
Professor Ross is a Chair Professor in the CS Department of Polytechnic
Institute of NYU.
That's basically Brooking-Poly merged with NYU. I believe he also is
the current department head of CS Department. Professor Ross has
worked on a large range of topics including peer-to-peer
networking, internet measurement, video streaming, web caching,
multi-service loss network, etcetera. He also has popular books,
Computer Networking: A Top-Down Approach Featuring the Internet, that
many of us have read. And this book is already in its fifth edition,
being translated into 12 languages, I believe, and is the most popular
book nationally and internationally for the CS Department networking
aspect.
Professor Ross is an IEEE Fellow and serves as Associate Editor for
IEEE/ACM social networking and is PC chair of many, many conferences.
Today he will talk about the new research work on peer-to-peer video
streaming including View-Upload Decoupling theoretical analyses of how
we upload the coding. Decoupling is going to help with peer-to-peer
live streaming.
Without further ado, let's hear what Professor Ross has to say.
>> Keith Ross: Thank you very much, Jin. Also thank you very much for
inviting me to Microsoft once again this summer to MSR. It's always a
great pleasure to be here. It's a very, very simulating environment.
>>:
[inaudible].
>> Keith Ross: Yeah. So it's something that I enjoy every year. I
mean, every year I come here it's like having a mini sabbatical. It's
very, very pleasant.
So what I want to do is talk about two recent papers that we've
completed in the area of P2P Live Video Streaming. And both of them
appeared at Infocom in Rio de Janeiro this past spring.
The first one appeared in the mini conference, and the second one
appeared at the regular conference. The second one also, much to our
surprise, also won the best paper award this year at Infocom. So
that's what we're going to talk about here today.
They're two very related papers; and so it makes for one coherent
presentation, I hope. So first just a very brief overview of P2P Video
Streaming. We have many experts here in this room here on P2P Video
Streaming, so I don't want to spend too much time. I assume that we
have right here in this room some of the leading researchers in the
field.
So we'll talk about that quickly; and then we'll talk about video
uploading, video upload -- View-Upload Decoupling. That's VUD, which
stands for View-Upload Decoupling. And then some queing models for P2P
Streaming, which apply both to traditional designs of P2P live
streaming and also to VUD as well.
So peer-assisted video streaming, for those who have not seen this
before, the basic idea is that peers redistribute video chunks to each
other, similar to BitTorrent. It's really been inspired by the
BitTorrent design. The idea is to use the peer upload capacity and
reduce the load on the server. The main reason why you're doing this
P2P video streaming is, in fact, to reduce the load on the server and
use the upload capacity of the peers to do the work for you.
So the basic, you know, situation is as follows: You have a single
live video that a server wants to transmit to a large number of peers,
maybe a thousand or more. Here is just a fixture of six. The server
sends video chunks to just some of those peers -- in this case peers 2,
6 and 5 -- and then the peers redistribute the chunks among themselves.
Again, the idea is the peers are assisting the video distribution of
the live video channel. There are many large-scale deployments today
of this. This concept has been demonstrated, you know, to work quite
well. There's a number of them: CoolStreaming, PPStream, PPLive. So
let's just say a few words about them, some historical things.
CoolStreaming was the first one. I believe it was developed at the
University of Hong Kong of Science and Technology. And so that was
sort of the first one to show that this concept can actually work. It
had over one million users.
More recently there's a number of other companies involved. PPLive is
one example. It has today over 85 million users. It has over 800
channels available. Another very popular one, which is perhaps the
most popular now, at least my post doc tells me that, is PPStream.
That has over 350 million installations and 12 million active users
every day. So it's really more on the order of something like Skype
with 12 million active users every day and has thousands of channels as
well.
So what are some of the common features of the live streaming systems?
These companies I just talked about, they offer both live and on-demand
streaming. We're focusing here today on live streaming.
What are some of the common features? One major feature is that they
have multiple channels. That's something we want to look at
carefully in this talk today. In addition to there being peer churn,
there is channel churn. That is users tend to jump from one channel to
another. Most of the literature in P2P is focused on system churn,
just on the actual -- people bringing their laptops and starting up the
P2P application and then turning off the application. But there's
actually another type of churn that happens at a much faster time scale
than tradional churn, and that's channel churn. So we'll come back to
that. But that's something that we're very concerned about in this
talk here.
Another thing is of course their heterogeneous streaming rates.
Different channels are being offered at different rates, some at high
HDTV rates, some at VCR quality rates, et cetera. Of course the
channels have heterogeneous popularity. Some channels are extremely
popular with tens of thousands of simultaneous users, and others have
just maybe a handful of users watching simultaneously.
In all of the existing systems of PPStream, PPLive, et cetera, they use
today what we refer to as an isolated channel design or ISO. And in
this design, the traditional design that's going on now, is a viewer
only distributes a channel that it's watching. So if a viewer is
watching the World Cup Soccer game, then it will redistribute the World
Cup Soccer game. It will not redistribute something else, like a
tennis match or Desperate Housewives. It only redistributes what it's
watching. This is the classical design. This is similar to the
BitTorrent philosophy. In BitTorrent when you're downloading a file,
the same file that you're downloading you're redistributing it; you're
not redistributing some other file. So what are some of the problems?
Even though they're very successful with tens of millions of
simultaneous users, these systems still have some performance problems.
There's room here for improvement, so room here for a competitor to
come onto the market and try to build a better system that overcomes
these problems. One of the bigger problems that we've observed is that
there's generally a large channel switching delay. As we know when we
watch TV at home which comes from cable or sattelite, the switching
delay from one channel to another is on the order of only one or two
seconds typically. But in these systems the switching delay is much
longer. It's in the order of 10 to 60 seconds. The systems still have
a while to go to really approach the switching delay that we have in
the systems that we're used to.
Another problem is that there's often a large playback delay. The
playback delay is defined from when -- for example, if you're watching
a soccer game, from when the goal actually occurs in realtime until it
appears on your screen. So the playback delay in these systems can be
from five to even 60 seconds long. So what that means is when you see
the goal, it actually occurred a minute earlier. So you might hear
your neighbors cheering and screaming 30 or 40 seconds before you
actually see the goal occur. So that's one problem. Another thing
that's been observed is small channel you have sometimes poor
performance for small channels. So if the channel is very small, just
three or four simultaneous users, and you have a lot of those channels,
performance may be erratic and not very good. You have a similar type
of phenomena in BitTorrent as well. Generally speaking, in BitTorrent
you get better download rates when you join a channel that has a larger
number of users than when you join a swarm that
has a
small number of users. Now, one of the root causes of these three
problems here -- there are really two root causes.
One, we argue, is channel churn where we have these users who are
rapidly jumping around from one channel to the next; and because of
that -- we're going to show you some slides here. But they're
impacting the distribution swarms in a very negative way. The second
is resource and balance. That is to say that there's this notion of a
resource index in these P2P live streaming systems. Each channel has
its own resource index, and it can be very different from one channel
to the next. That causes problems as well. We're going to elaborate
on that in a few seconds.
So let's look at the channel churn problem in the ISO designs. Here we
have a very simple situation where there's only two channels, Channel 1
and Channel 2. So Channel 1 might be World Cup Soccer game. Channel 2
might be Desperate Housewives, for example. So we have viewers in
Channel 1, and we have viewers in Channel 2. They're each getting
their video chunks and redistributing their video chunks to each other.
Everyone is happy. But now we have some channel churn. And viewers 3
and 1 all of a sudden decide they want to watch Channel 2. Viewers C
and F all of a sudden decide they want to watch Channel 1. So what's
going to happen then? That's going to cause the following: Now all of
a sudden, for example, Peer 4, who was previously getting chunks from 1
through 6 is no longer getting chunks from Peers 3 and 1. It's missing
these chunks. Now it has fewer places to go to get chunks. So that's
going to potentially cause problems. Now we're setting up for a
situation for missed chunks. We're not going to get all the chunks
that we need. Also probably you may need to find other peers, other
sources of data where we can get chunks from. That's going to take
some time for, say, Peer 4 to find that. Same thing when C and F come
here and join, because now it's not a very stable system if peers are
leaving and going. It's going to take a longer time for C and F to
find stable peers that can supply chunks. That is going to impact the
performance of the system. That was the first problem. That was the
channel switching problem. The other problem is the resource and
balance that we mentioned. So to describe resource and balance, we
need to introduce this concept here of this instantaneous resource
index. Many people have used this measure in analyzing video streaming
systems over the years. We're not the first to introduce it, but it's
an important measure. Basically what it is is if you have end users
watching a channel -- this is for a particular channel -- and the rate
of the channel is "r", this is a total demand for that channel.
It's n x r. This is how many bits that need to be uploaded to all the
end users. This here is the upload capacity that's brought by the end
users. This is the upload capacity of the server and the upload
capacity of the end user. This is the aggregate upload capacity. So
in order for the channel to function properly, the total upload
capacity needs to exceed the demand, n x r. So the supply needs to
exceed the demand. If this value segment here is less than one, then
you're going to have trouble. Then the supply cannot meet the demand.
So we're going to come back to this. This is an important ratio here,
this resource index. We're going to come back to it a few times during
this talk.
Now the problem we have is there are multiple channels. This resource
index, which is also a function of time -- because things are changing.
The number of peers in a channel are changing.
The resource index from one channel to the next is typically very
different. Some channels may have a very high resource index, and
others are very low. And there's potentially a great imbalance when
you're using this isolated design. So that's another thing that we're
going to solve. I'm not only going to try to solve the channel
switching problem but also this resource index imbalance across
channels. So that gets into this new design that we refer to as VUD or
View-Upload Decoupling. So let's talk about that. Here's the new
design. As an example here, we have two channels for illustrative
purposes. What we're going to do is first we're going to break each
channel into a certain number of substreams. The reason we're doing
this is because -- I'm going to come back to this a little later. But
this VUD design introduces new overhead. In order to reduce the
overhead, we use this substreaming. But we're going to come back to
that.
So we're going to break each channel into a substream.
>>: For example, right now you are doing -- let me just propose some
possible links here.
>> Keith Ross:
Okay.
>>: So for example 1, 3 left, right-hand side.
hosts. [inaudible] problem for the other.
>> Keith Ross:
Now there's other
Right.
>>: The simplest way to start using this one would be -- the problem
you ask [inaudible] even though they are switching to another channel,
you can still supply to the [inaudible] user up. Essentially they
become useless. [inaudible] longer meaning overlap [inaudible]
consistency.
I swap. I switch to another channel, commence supply five minutes or
whatever over some fixed time supplier until five more minutes or do
something. Would that solve a problem instead of using that more
fancier version?
>> Keith Ross: I guess this is fancier than that. Um, that is
something a little bit along the lines of this in some sense. But
would that solve the problem as well if those guys are still
there.
>>:
Five more minutes.
>> Keith Ross: But here though we have a lot of users that are jumping
around every ten seconds. You've got to keep in mind that we find that
the average -- 70 percent of the holding times in a study that's been
given by Atelephonica -- is less than ten seconds you're staying in
there. So a guy is going to go in there for ten seconds, and you're
going to ask him to stay for another five minutes.
>>: Five minutes as a simple rule. Until you become useless. Meaning
[inaudible] therefore you can go now.
>> Keith Ross:
Right.
>>: I'm just throwing something directly.
simplest version.
Just asking you if that's a
>> Keith Ross: I'll have to think about it more. But my gut feeling
is that that might make sense. If users really were staying there for
a long time, then why not just have them stay for another ten seconds.
But here they're really jumping around quite a bit here.
>>: Usually in the peer systems such as this, mostly important
resources rather than the cache. So in effect a piece of video may not
actually be that worse rather than the resource.
>>:
But well probably to include --
>> Keith Ross: Okay. So now what we're going to do is we are going to
-- since we have all these peers that are jumping around all the time,
we're going to say if you're one of those peers or persons, one of
those users, we're going to put you in a fixed channel. Your job now
is to distribute that channel no matter what you're viewing. So this
is why we're decoupling -- it's called Video-Upload Decoupling. What
you're uploading is going to be independent of what you're viewing.
That's the basic idea. So what we're going to do is organize the peers
so these three peers here are assigned to substream one. No matter
what they're watching, they just always redistribute substream one, as
long as they're in the system. This is crude form. And these guys
here -- and then so we send channel substream one and they redistribute
it among each other. Usually it may be a bigger group here. But in
the end each one of these guys gets all of substream one, has all the
chunks of substream one. These guys here redistribute, get substream
two. And going over here, these guys get Channel 2 substream one; and
these guys redistribute substream two of Channel 2. So these guys are
fixed here, and they just serve as redistribution groups. These guys
here, all these peers -- 1, 2, 3, 4, 6 -- want to watch Channel 1, then
what they need to do is get substream one from this group here; and
then they need to get substream two from this group over here. So what
that means here now is that each peer -- for example, peer one it's
downloading these two substreams because its viewing these two
substreams; but it's also getting a substream here, this orange one
that's not even interested whatsoever. This might be watching World
Cup Football; and this might correspond to Desperate Housewives. He's
downloading Desperate Housewives even though he doesn't want it. But
that's part of the design here.
>>:
[inaudible].
>> Keith Ross: Yeah, we're going to get into that. There's an
overhead issue, there's no doubt about that. There's an overhead
issue. So putting aside the overhead issue, let's suppose now that all
of a sudden we have some switching just like before. So C and F move
over to Channel 1 and start watching Channel 1 and 1 and 3 start
watching Channel 2. When these people switch
channels -so they're switching back and forth -- these distribution groups remain
constant. Nothing happens in the distribution groups. So when C comes
over here, it's relatively easy for C to find the substream that it
needs because these guys are constant. They're always there. They're
always providing the video. We don't have to search too hard, ask a
lot of peers, "Do you have the chunks?" Those guys have the chunks.
So that will help us reduce the switching delay significantly. So
putting aside the overhead issue, let's suppose now that all of a
sudden we have some switching just like before. So C and F move over
to Channel 1. They start watching Channel 1, and 1 and 3 start
watching Channel 2. When these people switch channels -- so they're
switching back and forth -- these distribution groups remain constant.
Nothing happens in the distribution groups. So when C comes over here,
it's relatively easy for C to find the substream that it needs because
these guys are constant. They're
always there. They're
always providing the video.
We don't have to search too
hard, ask alot of peers, "Do you have the chunks?" These guys have the
chunks. That will help us reduce the switching delay significantly.
So the other thing we can do here is we have the possibility of
dimensioning the substream groups in some kind of sophisticated manner
if we want. We can now, just like in traditional teletraffic
engineering, we can start to try to dimension these groups to suit the
demand. So there's going to be demand for each substream, and we can
try to dimension these groups to try to match the demand for the
substreams. In that way we're going to be able to get to this up here,
this cross-channel provisioning. Since we can dimension each of these
substream groups, we can dimension them in a
way that the
resource index hopefully is basically
balanced. Before we
said that the resource index is often very highly -- it's very
different. Often small channels have a lower resource index than large
channels. What we can do now is dimension those so that they have
essentially the same resource index. So the two advantages of this
approach so far is that we can address this channel churn, and we can
have a more balanced resource index across channels. The third thing
also that this provides is more structured streaming. So within a
distribution group -- let's see if we can go back here. There's a lot
of work on how you should do the distribution within an ISO system.
Should you do a Push-Push system, a Pull system, Push-Pull trees?
There's been already twenty papers written on that in the world. But
in fact, the thing is that when the system is very stable, you can go
back to sort of tree-like structures, which have better performance
properties. So the advantage again with VUD here is that since this is
very stable, we can optimize the distribution, the scheduling and
routing, within the group to improve performance. So that's the third
advantage here. If I can just get up there. So that's the structured
streaming. Scheduling and routing can be optimized within the stable
VUD swarms. So as mentioned here, one of the problems is overhead.
The way we address the overhead is to use substreaming. The more -- if
you take a channel and you break it up into more and more substreams,
you're going to reduce the overhead because the amount that you're
downloading now -- how much do you download as a user? You download
the video that you want to watch, just like you've always had to, plus
one or more substreams. Suppose you're only assigning one substream
and that substream is very thin, then you're not downloading very much.
So the total amount of upload traffic in these.
Systems is equal to the total amount of download traffic. The total
amount of upload traffic across all users is equal to the total amount
of download traffic across all users. So by using substreaming -you're using very thin substreams, you reduce the overhead traffic
significantly. And we'll have some figures on that in a few minutes.
So that's that there. The other issue is how do you go about
dimensioning these groups? In particular there's still peer churn
here. Peers are still coming and leaving. And some channels are
becoming more popular than others over time. So you need to do
something intelligent to dimension these groups and in realtime. So
that's what we're going to talk about. The goal is to maximize the
resource index across substreams. And you can formulate this as an
optimization problem. And this turns out to be a mixed-lineation
programming problem, which is -- you know, it's something we wouldn't
want to do in practice anyway. We need to do this in realtime.
So I'm going to skip over this. This is what we want to do. So how do
you create these groups dynamically? How do we maintain these groups?
So we're going to do this with the goal of maximizing the minimum
resource index. So each channel or each substream has a resource
index. We would like to get all those resource indexes as high as
possible, equally high. So the goal is going to be to maximize the
minimum resource index. Hopefully in doing so, all of these resource
indices will be significantly above 1. So what do we do here? So when
a new peer joins, where do you put that new peer? This is the main
method we use to dimension a group. So when a new peer comes, we look
at all the resource indices of all the groups; and we find the one
that's the lowest. So we assign that peer just to that one. So the
peer joins the resource group for the group that needs it the most, it
needs the upload capacity the most. So assign peer to the most
resource-poor substream distribution group. We may actually assign it
to more than one group. So the peer comes with a certain amount of
upload bandwidth available, say one megabit per second or two megabits
per second. And maybe the video rate is 500 kilobits per second. So
we can assign it to more than one group. I'm going to talk about it in
a second how we do that. But we may assign it to more than one group.
>>:
Like a reserve?
>> Keith Ross:
Reserve?
>>: Yes, for example, like [inaudible] you put some people wait until
you have [inaudible] and here it's a great algorithm, whenever a new
peer join, what do you start a new channel, for example. Now you have
a problem.
>> Keith Ross:
>>:
New channel.
So a channel becoming very tolerant, for example.
>> Keith Ross:
Right.
>>: Then the ratio would be unbound. Then you look around and you
don't have a reserve. What I want to do is provision each channel to
reach a certain provision level, for example. 1.5. 1.8, whatever.
And all those have got to be reserved, meaning they're not joining any
channel and because I think one reason actually is -- suddenly one
becomes popular and one can may not, [inaudible] supplied by a
particular channel.
>> Keith Ross: Right. The reserve is an interesting idea. It's
another approach taken. There's many variations. That's an
interesting one. So, yeah, good.
So basically this is just the approach we take in this particular
simulation, heuristic we're using here but there are other interesting
variations is the following thing.
So basically we're going to use a water filling policy. Here's the
different groups here and here's the current values of their resource
index, and when a new peer arrives we're going to assign its up load
capacity most likely here but we don't have to assign all of it here.
If we assign a little bit and it brings us up to here, for example, we
might now go ahead and start assigning some of its extra upload
capacity to this peer over here.
So what we're going to do is we're going to allocate when I arrive, I
have a certain amount of up load capacity that I bring to the system.
And I'm going to first look at the subsidy, the group that needs it the
most. Allocate some of my resource capacity to that group.
If there's still some capacity left, I go to the next group over here
and allocate that. And when I do these allocations I follow this rule
here, this is a detail we won't worry about that but there's some
number of little rules that we must follow.
So okay that's basically it. That doesn't necessarily solve the
problem. So because there might be a flash corral like you say or
something going on, maybe not an immediate change in the popularity of
the channel but a slow change of the popularity of the channel.
If the sigma K falls below the threshold then what happens, maybe you
can't wait for new peers to arrive to repair the problem. You need to
repair the problem immediately. So then you're going to have to do
something. The first thing we try to do is shift bandwidth without
being, without being reassigned to new sub streams.
So let me just finish that and I'll get to that. When I'm in there,
I'm typically uploading, the way this is designed, I may be uploading
more than one substream as part of VUD. I'm not just up loading one
substream. I'm opening two, three, up to five substreams.
If I see that, if I know that one group needs more bandwidth, I can
shift some of my bandwidth from a substream that doesn't need it to a
substream that does need it.
So in this way, in doing that
groups. Everyone can stay in
things a little bit simpler.
that need it from groups that
I don't have to get reassigned to new
their same group and so this will keep
We just shift our bandwidth from groups
don't need it to groups that need it.
And just one last thing. So there's still not might not be enough.
There's still some situations where just shifting bandwidth is not
enough. And there are times when we may even need to actually move
peers from one group to another. That's sort of the worst case
situation and that happens as well but we account for that in our
design. Another question?
>>: I realize I actually don't understand the resource ratio. So
my -- first I thought sort of the views are the capacities of the
upload capacities.
>> Keith Ross:
>>:
Right.
Versus the amount that they're actually consuming.
>> Keith Ross:
Exactly.
>>: But now that you have multiple things going on, I'm not sure I
understand. So the use -- the upload capacities don't change, right?
Or they do?
>> Keith Ross: The up load capacities of peers don't change. But I'm
going to take my up load capacity, whatever that is, and I'm going to
allocate portions of that to different groups. Different distribution
groups.
>>: Okay. Allocated, not necessarily used. So, for example, if we're
just counting the use as being as how much bandwidth say UI is the
bandwidth that we're actually using to up load, up load I for
something.
>> Keith Ross:
Right.
>>: Then the resource ratio is going to be identitily at one, that's
for all those different channels, right, if that was ->> Keith Ross:
You're right.
That's right.
>>: But that's not obviously not the interpretation, because you have
these different resource ratios varying one.
>> Keith Ross:
>>:
Right.
So they must be the allocated bandwidth for that stream.
>> Keith Ross:
It's the allocated, right.
The allocated, right.
>>: So is that a different, another problem, then? It used to be that
you don't allocate it, you just have some upload bandwidth. And now I
mean how are these resource ratios defined really? What do those use
now? Because you're going to have different channels, different use
for each channel coming out of a particular node? And you have to
allocate them. You have a total amount of up load from a particular
node.
>> Keith Ross:
Right.
>>: You're going to compute resource ratios for each of the channels
separately, right.
>> Keith Ross:
Right.
>>: Now we're going to have somehow have different -- partition the
total upload bandwidth into the different channels.
>> Keith Ross:
>>:
Those would be the use for each channel.
>> Keith Ross:
>>:
Exactly.
So --
I don't understand it.
>> Keith Ross:
>>:
Right.
How do we do that partitioning?
>> Keith Ross:
>>:
Right.
Huh?
Go ahead.
>> Keith Ross: Well, how we do with that assignment. So, again, like
I come in with -- I'm not sure -- two megabits per second of bandwidth.
And I look at the current resource ratios using -- and again the
resource ratio is defined on how much is allocated as you say. And I
find the group that has the lowest ratio, maybe it's, I find a group
lowest one maybe it's 1.1. The 1.1 is a dangerous situation to be in.
It's still above -- even though 1.1 has been allocated, even though -in theory it's enough to supply. Some peers may not have actually the
content and others will. So you may be missing a lot of chunks. So
you want to be at -- so the lowest one is 1.1 I see this guy is 1.1
I'll give all my bandwidth maybe to him and all my upload bandwidth
that I'm ready to allocate. So now he goes up to 1.3 and he's in a
better situation. That group is in a better situation now.
>>: But do the peers have to communicate with each other their
location?
>> Keith Ross: Right now they're just assuming centralized design.
that some central controller sees everything. I mean, future works
might look at some decentralized version.
So
>>: Another thing say you allocate for peer, allocate [inaudible] for
the stream but actually is not using because it's not using 200
[inaudible] because that means that part of the bandwidth cannot be
used by others.
>> Keith Ross:
It cannot be used by others, that's right.
Right.
>>: And that's there. And it depends on whether their system is pull
or push. There could be -- if you allocate to 200 it can be. But not
enough pull coming from there, then that resource is based ->> Keith Ross:
I guess -- I guess that's sort of true.
>>: In a sense it's going to be wasted anyway, right? Just because
you allocate it is not going to use it. If the total -- if the
presumption is that all the -- as a whole system the whole use will be
something more than what you're consuming.
>> Keith Ross: I think in a future paper we can look at some kind of a
more intelligent scheduling algorithm where you do this allocation and
those allocations are just priorities. If someone else went to use
that bandwidth when no one else is using it, then you could let other
channels use that bandwidth, for example, right? But for the time
being we're not doing that.
>>:
So how do you figure out the bandwidth at the beginning?
>> Keith Ross:
>>:
That you --
[Inaudible].
>> Keith Ross:
That you make available?
>>: I mean, how do you know like the UI, the value?
it may change.
Because I think
>> Keith Ross: How much your UI is? Well, like -- yeah, in bit turn
you can figure in bit turn how much your upload bandwidth is going to
be. How much up load bandwidth you're going to supply to the bit torn
application. So that's basically so what's going on here, is that you
can figure that value and that's what you would report to the server.
That's what you would report to sort of centralized controller.
>>:
What would happen if you cannot bridge that break?
>> Keith Ross: Then you won't give -- I guess -- those are issues -those are issues that can be worked on in a more refined discussion,
design. But I think roughly if you don't contribute all the bandwidth
that you -- you still have the overall system measuring how much
uploading is going on in the channel and what the demand is. So the
system is still measuring the resource index sigma for everyone. And
if because someone is not contributing as much as they said they are,
then you'll just see a lower sigma value than perhaps you're expecting.
So you'll have to put more people into that channel.
Okay.
So here's a simulation result. And so this simulation basically we
used a packet level simulator that was developed at Chingwa University
and modified that a bit. And the simulation takes into account channel
switching, peer churn, heterogeneous upload bandwidth, packet level
transmission, round trip time latency. Vise [phonetic] light channel
popularity. And we're going to use push/pull scheduling for both ISO
and VUD to make this comparison fair.
And in the simulation there are the trace-driven simulation.
50 channels. Each one has 400 kilobits per second.
There are
The 2000 peers, we use the upload rates that came from a study that was
done here at Microsoft a few years ago.
The average peer system time is 67 minutes. We just take that -- the
channel churn that we use follows an IPTV study that was done out of
Telefonika a year or so back. So we used the numbers there.
Again, we found in that there's a huge amount of channel churn with 70
percent of the peers staying in there for less than a channel for less
than 10 seconds, if I recall.
And five substreams per channel. And so just some results here is that
here we're looking at popular and unpopular channels for both VUD and
ISO. And this is the channel switching delay. And we see that the
channel switching delay for -- there's the channel switching delay is
the time to acquire five seconds of the new channel, by the way.
And we see that the switching delay for five tends to be almost less
than 10 seconds, whereas the switching delay for isois, can be much
much longer. We have a lot of delays that are over 25, 30 seconds for
both the popular and unpopular channels.
So we see that VUD does much better in terms of switching delay.
Playback lag is a similar kind of thing. We see -- this is the VUD
design here, and this is the playback delay for ISO. You see play back
lag for ISO is particularly very long 15, 20 seconds. It can be long
for some peers here as well in VUD but on average it's much smaller
than it is for ISO.
Chunk missed ratio. Similar kind of thing. This is what we get here
for VUD here. This is chunk missed ratio is relatively low. This is a
situation where the resource index is, the overall resource index is
low. So performance is tight. Whereas the chunk missed ratio for ISO
is again in this particular scenario is very, very high. It's really
unacceptable.
And finally just getting on the overhead from the simulation, we look
at a different number of substreams and determine the overhead, define
the overhead as the bandwidth used to upload video to distribution
peers, divided by the bandwidth used to upload video to the viewing
peers. I just burnt out the laser, I guess.
And as expected as you increase the number of substreams the overhead
can drop down. So as we get down to five, six substreams, the overhead
is less than 20 percent.
So there's a trade-off here. We are introducing more additional
overhead. We need more upload capacity to do this, maybe 20 percent
more upload capacity.
But it seems that the advantages outweigh the disadvantages.
>>: I don't quite understand this. The collecting bucket. Overhead I
think is probably the following, a simple way -- you know how many
substream you're going to have. Let's focus on one stream.
>> Keith Ross:
>>:
One channel?
One substream.
>> Keith Ross:
One substream.
>>: You have one substream, multiple, doesn't matter. So let's do a
very simple high level supply demand analysis. Okay. So no matter
what -- substream I assume they have received all sub streams. So
let's look at one substream. Original support you have end users in
your channel. They all need to supply end units. And [inaudible]
centrally account for receivers. That's the end.
>> Keith Ross:
>>: Yes.
N times.
N receivers.
Receive one substream?
Or NP four, watch this channel.
>> Keith Ross:
So it's going to be cheaper
Right.
>>: Now the overhead now is essentially is the size of the [inaudible]
group. Write an analysis of the substream to N users. Suppose you
have, okay, distributed node. Now a total number of receivers of this
one would be N plus K. [Inaudible] so overhead K divided by N.
>> Keith Ross:
>>:
K divided by N.
Because ordinarily --
>> Keith Ross:
K is --
>>: K is the size, how many users in the distribution group. So
originally 100 people watching. So if I get help, [inaudible] overhead
five divided by 100. So given this, I don't understand why these are
even [inaudible] with substream.
>> Keith Ross: Again, I think the way to look at it is the amount of
up load capacity is used, is equal to the aggregate amount of up load
capacity is used is equal to the total amount of download capacity
that's used.
The download capacity that's used, right, is how much is being used is
everyone needs, and for the overhead, is that we're downloading now
just rather than a whole channel, we're downloading just a substream
that we distribute.
And so if we can make that substream thinner, the amount that we're
downloading, the aggregate amount we're downloading is less therefore
the aggregate amount that we're uploading is less.
This is a tricky issue. We have actually worked that out in the first
paper. Maybe we can talk about that a little later. Okay.
>>:
Look at the second paper.
>> Keith Ross: Yeah, we'll get into that.
on -- how much time do we have.
>>:
We have one and a half hours.
So now this one is more
40 minutes left.
>> Keith Ross: I don't want to bore everyone too much. We have
queueing models. So this is the second paper. This is a bit more
mathematical. So our goal is to -- but not very mathematical. It's
very simple math, actually. So the goal is to develop analytical
framework for multi-channel live video streaming systems.
So that apply both to ISO, what we were just talking about and VUD.
And the other thing we want to do once we have this analytical
framework we want to use it to optimize by performance. We'd like to
use it to dimension those VUD groups.
And in this discussion we're going to use the following performance
measure a lot. It doesn't have to be this measure. There are other
ones that could be used that are also tractable. But just to keep
things simple we'll use this one here. It's what we call the
probability of universal streaming.
And that's the fraction of time, the resource index is greater than one
for all channels. So, again, we want that resource index is sigma. We
said if sigma is greater than one typically a channel has good
performance.
And so we want to now look at the time, the fraction of time that all
the channels are happy. Every single channel has a resource index
that's one. Maybe that happens 10 percent of the time 20 percent of
the time. If it happens 20 percent of the time then our probability of
universal streaming is .2. If it happens 90 percent it's .9.
That's what we'll focus on here. Here's this very simple qeueing
networking model of the system. We'll view each channel as a queue and
view each viewer as a customer.
So a customer is going from one Q to another because they're changing
channels. When a viewer changes channels it's going to be rooted to a
new queue. We assume there's some kind of matrix, switching matrix
given over here. This is the probability that a user goes from channel
I to channel J.
And so customers move about -- customers don't
other, obviously, as they move from channel to
channels, it's not going to have any impact on
channels. So because of that we naturally use
each queue here.
interfere with each
channel. If I change
whether Jin changes
an infinite server at
And let's let 1 over mu J denote the average sojourn time. Since we
have infinite server queues there's the so called insensitivity
property from queuing theory which says we can have any distribution we
want for the sojourn time. We're not limited to exponential
distribution. We can use an arbitrary distribution here. We're not
assuming anything about the distribution amount of time is someone
spends in the channel.
But let's let 1 over mu J denote the average time we spend in a
channel. So this is a classic queueing model. I don't know how many
of you studied qeueing theory, but when I was a Ph.D. student back in
the old days that was like one of the main things they were always
teaching was qeueing networkings. And now it's sort of gone out of
fashion a little bit but it's turns out it's very useful here. It's
not a real stretch to use it. It's a very natural model. It's not
like we're trying to put a square peg into a round hole. It's actually
the right model for the situation.
So anyway so once you have that, then you can actually -- okay. So
first thing you have is that this very standard result is that the
probability that there are M 1 users watching channel 1 and M 2 users
watching channel 2 and MJ users using channel J as given by this
expression here. And here we're going to look at, first of all, in the
closed qeueing network. Assuming here there's no peer churn.
It says that peers come and they stay in the system forever for the
time being. We're going to look when there's peer churn as well. But
peers stay in the system but there's channel churn. This would be a
situation and model, for example, set top box environment.
So you have this whole thing running at set top boxes which are always
on. So there will be no peer churn, only channel churn.
And so, and there's a number of, number of peers. Row I is lambda J
times mu J. So 1 over mu J is the average sojourn time in channel J.
Lambda J is what you get from the trapping equation, the standard thing
you get from qeueing theory from a trapping equation. Well known
result from Jackson networks.
And so everything is pretty straight forward. The case of -- when you
have a case of pure churn then we use an open qeueing model.
And so there peers would arrive at some constant rate and join a
channel J with probability P 0 J. There's a new traffic equation
that's the standard equation that's used for open qeueing networks.
You get a new value of row J accordingly and you get a slightly
different formula.
In this talk we're going to talk about the closed [inaudible] case, the
whole analysis goes through for the open qeueing case as well.
You can definitely handle peer churn. We're going to look at the
closed case when there's no peer churn for illustrative purposes here.
So given that now, we're going to go ahead and do some analysis. And
it's very, very straightforward analysis we'll see here. So first
thing we want to ask is the goal is we want to determine the
probability of universal streaming. The probability of universal
streaming is the probability that every channel is happy.
Okay? And we're going to do this for the case of VUD initially. And
so what is this quantity here? This is the resource index for channel
J substream S. S substream and channel J. And MJ is currently, is a
random variable. It's the number of users watching channel J.
That has the distribution over here that we could drive from over here.
So this is the resource index for channel J and of course it's random
because the number of users watching channel J is random.
We want that to be greater than one for all substreams in channel J for
all channels.
If that is the case, if this is greater than one for every single
substream, then we have universal streaming. So we want to calculate
that probability.
Again, that's the measure we're using here. There are other measures
that are possible. So it's the probability of universal streaming.
So, again, the resource index, just go back up here for channel J is
given by this formula. Again, this is the number of users watching
channel J. This is the -- so this is channel J's substream S. This is
the rate of substream S. And this is the amount of bandwidth that's
been allocated to that amount of substream. This is the amount of
bandwidth coming from the server. This is the amount of bandwidth that
we're getting from each of the users that have been assigned the
substream S in channel J. And this here is the rate that is being
taken away because there's -- because this is the rate that's being
taken away because there's some users watching us. This is the number
of users watching substream S and this is the rate at which they're
watching it.
So that's the sigma J there. And so just one assumption that we're
making here, we're assuming for the time being in this analysis, just
to make things simple, that a user allocates all its bandwidth to one
of the substreams. So we don't break up our bandwidth among multiple
substreams, we allocate all our bandwidth to one substream, in this
analysis here.
So that's the thing. And so then you can go ahead then and since you
have an explicit equation for the joint distribution of MJ, from
Jackson network, you can go and calculate this probability. And the
probability looks like something like this.
And then that is the kind of thing like if you look in the literature
and lost networks and qeueing networks, people wrote half a -- dozens
of papers on that on how to calculate that efficiently.
So you can just use that if you want. And sigma J is given by this
expression here. So it's all very straightforward type of stuff. So
the thing is that once you have this kind of qeueing and loss network
model, what you can go ahead and do, you don't have to reinvent the
wheel, you can just go into the literature and start reusing, not
exactly you have to modify things a little bit but not a lot. You can
crank out all kinds of nice results. That's basically what the paper
was about, is going back to the old literature and just applying it to
this kind of context here.
>>: Check my -- so if you know the number of people watching a
particular -- I guess substream a channel, a substream. Then you can
compute sigma -- so the sigma -- the equation on the top just a
function of -- I mean all the numbers besides M are.
>> Keith Ross: Are constant, exactly, uh-huh, right.
numbers are constant.
>>:
Don't depend on N.
All the other
>> Keith Ross: Don't depend on N. Here what we've done is we're doing
VUD and we're assuming now that we have assigned, we have a fixed
number of peers in the system N. And we have assigned each peer to a
particular VUD group, fixed for the time being.
And each peer gets assigned to exactly one VUD group. Okay? And so
that's -- so the groups are determined here. So NJS is a set of peers
that have been assigned to the substream, the group substream S channel
J.
All right. So one thing we can do, for example, is an asymptotic
analysis of VUD. So if you look at the literature things like Frank
Kelly did on loss networks back in the '90s where what he did is he
studied loss networks, which are like circuit switch telephone
networks, and there's a product form solution there. And then what you
can do is that he looked at what happens when those loss networks get
larger and larger, things simplify.
We looked at doing something similar to that and came up with a theory
that works out nicely here. So here, for example, we fixed the number
of channels, the number of channels are fixed.
And we let the number of peers go to infinity. So you get larger and
larger. We'll look at bigger and bigger systems. And for simplicity
we're going to assume there's no sub streaming. You can do this for
sub streaming but to make it simple suppose there's no sub streaming.
And we're going to look at an asymptotic regime. This is the number of
peers that we assign to channel J and the number of peers we assign to
channel J will be proportional to the total number of peers in the
system according to a fixed ratio here, factor KJ. So K sub J, which
is going to be fixed in this model here is the relevant -- is the
relative number of peers or the fraction of peers that have been
assigned to channel J. Channel J for distribution.
So the question is then for a large system, how should we set KJ? We'd
like to know how big each of our VUD groups should be. Can we come up
with a simple formula that tells us how big -- what should be the
relative number of peers we assign to channel J?
So that's one thing we're looking at here. So I'm not going to go
through the proof. It's not that hard, actually. But it turns out,
let's look first at the case at the homogeneous case, when each upload
rate is the same. Turns out there's this critical parameter that's
called alpha given explicitly by this formula. What's this formula, RJ
is the rate of channel J. Row J is essentially the utilization of
channel J. It's the lambda J divided by mu J. U is the up load
capacity of a peer, and RJ is the rate of a peer, I'm sorry, the rate
of channel J. And the theorem says that if alpha is greater than one,
then the probability of universal streaming goes to zero.
system gets larger, universal streaming goes to zero.
That as the
You're not going to have good performance if alpha is greater than one.
On the other hand, if alpha is less than one, then if you set the KJs
equal to this particular value here, and there's other -- but this
value here, RJ times row J divided by this then the probability of
universal streaming goes to one.
So there's this alpha provides this kind of threshold here, this
dichotomy, where if alpha is greater than 1 there's nothing you can do,
you have bad performance. If alpha is less than 1 you can have good
performance. If you dimension properly, the fraction of peers that you
put into channel J is given by this value over here.
So that's just kind of
analysis. Then if you
you have heterogeneous
rate, UL and some that
dimension the system?
the results you can get from this qeueing
look at a somewhat more interesting case where
peer types where you have some that have low
have high rate, UH, can you still find how to
And so let's suppose the fraction of low rate peers is F. That's
given. And again you have these two rates. How do we find the alpha
model allocation so KJL would be the fraction of low rate peers you put
into channel J and KJH is a fraction of high bandwidth peers that you
put into channel J. And then what you can do is you can formulate this
linear program here where A to Js -- these are put in here they're
given constants that come from the basic data of the system. I didn't
bother to write it here.
These are the variables. The KJs, and you can solve this simple linear
program. This is a relatively easy linear program to solve. You can't
solve it by hand, generally, but you only have two times J variables
here and not very many equations, obviously.
And turns out that if the value of this linear program is less than
zero, then you can prove that the probability of universal stream goes
to zero as the system gets very large.
And if the value is greater than one then the probability of universal
stream goes to one and the KJs you're going to use are the optimal
solutions. So the amount of peers you're going to put into each group
high and low bandwidth peers are given by the solution to this
equation.
Okay. Now if you want to do analysis of ISO, then you still have these
MJs. It's the same expression for MJ is the number of peers watching
channel J. It has nothing to do with the design. That's just user
behavior that determines how many peers are watching channel J.
And so the probability of universal streaming is given by this
expression. Now what is this here? Script MJ, that's the set of peers
that are currently watching channel J.
So the amount of -- this is isonow. It's not VUD anymore. The amount
of bandwidth that's being provided to channel J is the amount of
bandwidth that's coming from the server plus the amount of bandwidth
that's coming from the set of peers that are watching channel J. So if
you're watching channel J then you're providing all your bandwidth to
channel J. That's the amount of upload bandwidth that you're providing
to channel J. This is demand for channel J. The number of peers
watching channel J times the rate of channel J.
So in order to get this basically -- this is greater than this, and
sigma is greater than 1 for that channel and you need that to hold for
all the channels. So that's the probability of universal streaming for
the traditional isolated design.
Once again you have this thing here. Now, this is more difficult to
solve, right? And as it turns out in the VUD case you have this nice
little formula if you wanted to, you could go ahead and solve this
using standard convolution algorithms very quickly. Here you don't
have anything like that. But because of the special structure, you
could use Monte Carlo important sampling methods to rapidly solve that
if you wanted to.
Again, that thing has been looked at in the qeueing literature. So for
the asymptotic analysis, there's a critical value as well for ISO it's
even easier to derive. It's given by this expression. And once again
if alpha is less than one then probability of universal streaming goes
to zero.
Now what we could do
asymptotic case, VUD
just an example here
bandwidth peers have
rate of 2 R.
is we could compare, for example, in the
and ISO, by using those analysis. And this is
where we have heterogeneous bandwidth, the high
a rate of 4 R and the low bandwidth peers have a
There's two types of streams in there. One stream has a rate of 5 R.
One video channel has a rate of 5 R and the other has a rate of R. I
guess there's just two channels in this example. There's just -- and
one channel has, channel 1 has a row value of .2. Channel 2 has a row
value of .8 and you can easily go through the calculations. Isohas an
alpha value that's greater than one that means the probability of
universal streaming will go to 0 in this particular case. And in VUD
you can do the allocations so that -- well, the alpha in this case is
less than 1. And so in theory you can do the allocation. So
probability of universal goes to 1, in fact you can do those
allocations.
So this is just a little example there. So some -- any questions about
any of this at this point here? Any of this kind of stuff? Okay.
>>:
Can you, going back to the sample, there's only one rate case.
>> Keith Ross:
>>:
Okay.
Can you give an interpretation for the allocation?
>> Keith Ross: That's a good question. I don't know if I can. I'm
trying to find it here. Here it is. Alpha here is just sort of the
excess. I wouldn't worry about that too much. So alpha here is less
than 1. So -- okay, but anyway, some interpretation here is that one
thing we see is that KJ is proportional to row J. Row J is the
popularity of the channel. It can be viewed as the popularity of the
channel, the relative popularity of the channel. Row J is actually the
expected number. It's the -- it's the relative -- it's the fraction of
peers, right, that are watching channel J on average.
So the more peers that are watching -- so that's fairly intuitive. The
more peers watching channel J the bigger we need to have the bigger
distribution group.
Second, also we have this RJ here, in there, but it's not quite
proportional to the example to RJ down here. But as you would expect,
as the streaming rate becomes larger and larger for that channel, then
you would want to have more peers in that channel to distribute there.
Because here each peer is contributing the same amount of upload
capacity U in this homogeneous case.
Finally, how should we interpret this.
And --
U minus RJ.
Term there.
>>: [Inaudible] I mean generally in this assignment you would not be
actually assigning the peer, which is watching the channel, to that
channel.
>> Keith Ross:
Exactly.
>>: So if that's alignment, I mean let's say you've done everything
wrong. You are wasting RJ for each of the peer you designed that way.
Of course that peer doesn't need that basically channel J but you are
downloading it anyway.
>>: When you're doing the ISO analysis for a single upload rate, up
load rate, does it reduce to this thing without the RJ at the bottom?
>> Keith Ross: Isoanalysis you don't do any assignments there.
There's no notion of KJ in ISO and ISO -- yeah.
>>:
Do you have any ways of --
>>:
Okay, maybe what I mean is the alpha then, the critical parameter.
>> Keith Ross:
that.
>>:
The critical parameter.
Okay.
Let's take a look at
Here you kind of -- let's say UL and UH are the same.
>> Keith Ross: Right.
intuitive there.
So that becomes just U.
Right.
So it's very
So basically what we're saying in the ISO case is that the maximum rate
has to be less than the upload rate of a link in order for that to work
there.
So that's very easy to derive in that case.
>>: I think basically if I try to interpret the case, can you go back
to the ->> Keith Ross:
>>:
Sure.
[Inaudible].
>> Keith Ross:
This one here.
>>: So my interpretation is this: Each of this RJ row J divided by U
minus RJ is a kind of supply and demand factor for each of the
channels. But the demand is this RJ times row J. If we break up the
channel kinds of popularity of the channel, the supply's U minus RJ,
how much rate is available minus redundant rate that you think you
need.
Now, the sigma of all the channels which derives R is the forgiveness
factor of all the systems. Basically each channels you have to
basically -- it's an oversupply and undersupply which says how much
resource you can allocate more to each channel.
But if you look at over all the systems, how hard is the value
[inaudible] whether the system is oversupplied, overdemand.
>> Keith Ross:
>>:
That's right.
That may be basically -- maybe [inaudible].
>>: So in the previous paper you mentioned if you have more substreams
you have lower [inaudible] but in this model only universal substreams,
just the one substream.
>> Keith Ross:
Right.
>>: So if that's true, if you have more substreams here, then that
equation can be changed.
>> Keith Ross:
>>:
[Inaudible] change, right.
Right.
>> Keith Ross: That's right. And I think in the paper we actually -actually, we created an extended version of the paper for journal
submission. And we do it for sub streaming case there. Go ahead, I'm
sorry.
>>: Suppose you have infinite number of substreams and we will -that's the equation that evolves to U minus RJ becomes U minus zero.
Is that true.
>> Keith Ross: Good point. I think it is true, actually. That's
correct. Yeah, that should be the case. Okay. So this is an example
here that shows even though when you're not using substreams, even in
the case where you're not using substreams, there's still situations
where some natural situations where Y is going to be doing even better
in ISO there. Even with the additional overhead that VUD brings you
still have better performance with VUD. And why is that? It's because
VUD is handling the channel switching a lot better than ISO is.
>>: But, for example, you're going to have from ISO case you're always
going to have zero doesn't go to zero. For channel one demand 5 R.
The output supply ratio is four, therefore channel one cannot ever
supply itself.
>> Keith Ross: Zero. Always zero.
an illustrative example here, yeah.
>>:
PS is zero for all cases.
This is
In that case [inaudible] because it's always what it wants.
>>: Yeah because my supply R [inaudible] in particular you're shopping
resources a little bit.
>> Keith Ross: Right. VUD offers that flexibility to be able to
shuffle resources to be able to meet the demand.
Some more numerical results here very quickly. These results are not
simulations, they're are all results calculated from the qeueing model
here. If we can look at much bigger systems. We have 1800 peers, 20
channels. We have two classes of links here, upload rates. .2 R and 3
R, we're assuming that every video is at rate R in this situation here.
So we have some that can upload at three times video rate and some that
can only upload at 20 percent of the video rate.
And we use these asymptotic heuristic to mention the substream swarms.
And so here's the kind of -- this is a plot where now we're looking at
the probability of universal streaming versus a Zipf parameter. We see
popularity falls with Zipf distribution, and what we're seeing here VUD
versus ISO in that example, as you increase the Zipf parameter, then
you increase the number of small channels.
And the problem with ISO with small channels is that you very often
have a resource index that's lower than 1. Why is that, do you think?
So a small channel with ISO, small channel means you have like two or
three users, the resource index can go below 1, because what we're
having here is there's the channel's going to be composed of these high
bandwidth and low bandwidth peers. And in the small channel, in a
large channel, there's a law of large number effect where so that you
have all these, in the peers joining randomly. And on average the
amount of resources that they contribute will be greater than demand.
In a small channel, very often you're going to have the -- you're not
going to -- the resources contributed will not meet the demand. That's
why small channels are particularly -- are a particular problem for the
ISO design, whereas for VUD where we're dimensioning to handle those
small channels to some extent, that, so when we use that heuristic, we
still have some drop-off here with the small channels. But we don't
have -- we have performance on the whole that's much better. So the
probability with universal streaming is much better in this example
here.
Here now what we're looking at is the probability of universal -- of
having a resource index greater than one for each individual channel
when using Ziff parameter set to one. If Zipf parameter is now set to
one we're looking at the channel IDs here ranging from 2 to 20. These
are the biggest channels, the most popular channels to the least most
popular channels.
And once again we're seeing that for ISO, for these smaller channels,
ones that are less popular, we have the -- they might have, for
example, probability of -- the probability that sigma is greater than 1
is only 80 percent. Whereas for VUD we see that it's very high and
consistently.
Very quickly here, there's one additional refinement that one can do to
get better performance. It's just a heuristic but it's a very simple
idea. Now what we'd like to do is try to get the probability that the
resource index is greater than one to be the same for all channels or
all substreams. So we're going to develop a heuristic now to get it to
be, so that we give -- we give -- we make each channel of equal
importance.
The channels that are popular and channels that are unpopular. And in
this heuristic we're going to assume a normal distribution for MJ. So
we're going to solve this equation. Rather than using the distribution
that comes from the product form solution we're going to use a normal
distribution, which the actual distribution is binomial. This is going
to approximate the binomial. And just for a time being let's assume
that all stream rates are R.
When you do that you get this following closed form solution for how
you should dimension all the divide groups. So channel J, substream
S -- this is the number of high bandwidth peers that you should put in
channel J, substream F. Number of low bandwidth peers that you should
put in there. You get these closed form solutions here using this
normal distribution.
And when you do that we get now -- this is what we get for ISO this is
what we get for VUD using that asymptotic heuristic, this is what we
get using this new heuristic, you get solid performance even for the
unpopular channels, the probability universal streaming is essentially
one using that heuristic. So that's just sort of nice.
So just in conclusion, then, what this stream of research was about
was, first of all, sort of identifying that in addition to peer churn
there's channel churn which happens at a much higher scale. And try
to -- and also taking notice that among channels there's typically a
very large resource imbalance across channels. So try to design a new
kind of P2P live video streaming design that takes into account this
channel churn and that was the first half of the talk and the second
half of the talk was about developing some simple mathematical models
that can be useful for modeling both the isodesign and the VUD design.
And so I'm going to thank everyone again for your excellent questions
and comments. If you have more, we can do it now or later.
>> Jin Li:
[applause]
You have an excellent talk.
>> Jin Li:
Questions from the audience?
>>: I have a question. Probably related to [inaudible] like
application [inaudible] at least when I was talking with like a live
stream allocation, those two developers, they tend to like -- they're
software is even like nonpopular channels may suffer when the peers
[inaudible] channels, they don't worry too much about uncovered
channels, because this is out there like -- they don't put much effort
on that, on those channels. But they worried a little -- a lot more on
their like popular channels, serving a lot of people.
But so in the solution, I feel that you're trying to somehow switch or
use those like some like extra capacity of those popular channels to
surf on, those public channels.
>> Keith Ross:
To some extent.
>>: Do we have any indication or evidence that a real system have that
like motivation [inaudible].
>> Keith Ross: Well, I think they look at like, for example, we've
done a different study on bit turn recently. Bit turn, it turns out,
has a very thick tail, for example. There's a lot of people
downloading videos and the swarms are very small. There's some swarms
that are big, like 10,000, 20,000 people. But the vast majority of the
swarms, 90 percent of the swarms have fewer than 10 users in it. Most
likely in these systems in the long run you probably expect to see a
lot of small channels there.
Now, this is a very competitive business. Bau Chen and Li was talking
about. He works with some of the companies out there so he knows this
better than anyone, but I'm trying to convince him how important it is.
But here's all these companies in there, right, China. This is another
way that one can distinguish themselves from one company can
distinguish them from another by saying that we support small channels.
We have lower switching delays. We have [inaudible] it's one
possibility. I'm just going to say I had a very interesting
discussion, and the point he made I agree is that he's been very quiet.
We figure they would say some of the things that's very polite. But
his argument would be, Well those companies, one thing live streaming
is not their main concern right now. Their main concern is video on
demand. Much more action happening in video on demand than live
streaming. That's probably true. So they're less concerned about
perhaps improved lives improving which more or less works, it's
possible they could get additional improvements using this or something
else. But their focus is really on on demand since that's the more
killer of the applications.
But what we're seeing in the literature in Infocom and elsewhere is a
lot of focus on live streaming, one of the reasons why is it's
intellectually interesting, I personally think it's more interesting
than the video on demand stuff. But anyway.
Fair enough.
>>:
Did I paraphrase your comments properly?
There's other ones.
>> Keith Ross:
Right.
Technical demand.
>>: One last comment, it seemed like when people watch TV initially
they switch between channels but once they start therefore. Seemed
like for that kind of user we can switch from this channel-based, your
thought ->> Keith Ross: Right. We've been looking at actually that, too. So
we've been -- we've sketched out some designs for that. I'm not sure
if we're going to write a paper on it. But we sketched out -- in the
end it's just -- it's true, it's something we can do if you get better
efficiency.
>> Jin Li: Okay. [Inaudible] if you
need to discuss with him, he's on the
second floor. 7975. Let's thank him
again.