>> Jin Li: It's our great pleasure to have professor Gary Chan from Hong Kong
UST to come here and give a talk. Professor Chan get his Ph.D. degree from
Stanford University in 1999 with a minor in business education. He's currently
associate professor at department of computer engineering -- computer science
and engineering at Hong Kong UST. He's also adjunct researcher at Microsoft
Research Asia and boasting a long list of achievement in the academia, including
associate editor in IEEE transactions on multimedia, vice chairman of
peer-to-peer networking and communication technical committee, and other long,
long list which I will not read all of it.
This morning he will give us a talk on proxy based peer-to-peer networks,
analysis, optimization and algorithms.
Without further ado, let's here what Professor Chan has to say about.
>> S.H. Gary Chan: Okay. Thank you, Jin, for this kind introduction. So I'm
going to talk about today on this proxy based peer-to-peer network and talk about
the problem analysis optimization and algorithms.
So I prepare about 70 to 80 minutes of slides. So I will see how the time goes.
Probably highlight some of the important aspects of the design of this
peer-to-peer network. And leaving some details for individual discussion if you
are interested in that.
So that is the outline. I will first introduce the problem and some of the related
work and talk about the match dealing problem which we are focusing on,
because we find that's okay in lots of mesh protocols. This aspect has not been
considered enough.
Then we will talk about two levels of optimization, the proxy level optimization,
which we are -- which we have come up with a protocol called fast mesh where I
will talk about the problem is problem formulation and the power concepts,
basically how to design and optimize network using this power concept and talk
about some of the centralized and distributed algorithms and some simulation
and experimental results on PlanetLab.
Then I will move on to peer level optimization. So in particular the robust mesh
protocol and talk about this analytic model, the daily optimization problem in the
peer level and at the centralized distributed algorithms and present some
simulation results.
Finally, if time permits I will talk about our system implementation efforts at
HKUST which we have been doing over the past two to three years, which have
attract some industrial investment on that. So conclude afterwards.
Okay. Multimedia streaming. Okay. We all know that traditionally it's done using
client server and using multiple unicasts, okay. Now, so there's a server which
needs to be -- which needs to serve for many users distributed in the network. If
there is a problem, I guess we all know that, it has high load on a serve. More
serves are needed as a number of subscribers increases. It also require much
server and network bandwidth because as a number of users increases, the
server bandwidth, the fair node at the server increases, the network bandwidth,
the network stress is also increased.
So that as number of users increases this system does not scale well. And
furthermore, expensive cost in upgrading and maintenance of servers and
background network will be incurred using this paradigm. So we don't want to
use that to serve many users.
There are peer-to-peer live streamings has been proposed. So basically I have a
server, multiple users. In peer-to-peer basically the server you serve these
users. These users then relay their stream to other users and has a copy to peer
streaming. It has shown to be very effective for many live applications you look
at PPLive and you know some of them representative examples.
Server only uploads streams to only a number of peers and then peers will help
each other. Now, media is then delivered using the uploading capabilities of
peers. Actually nowadays many of the network home network have upload
capabilities, so there is not a problem. The benefit will be to utilize the uploading
capacity of N hosts and the server will no longer be a bottle neck in the network.
The bottle neck can be in terms of bandwidth, the server is only to be designed
with a huge amounts of bandwidth and a huge amounts of computational powers.
Now, PPLive, peer-to-peer live streaming has been around the strength of using
PP -- P to P streaming is very easy, ease of deployment. There's no need of
special routers and equipment and that is very easy to develop I guess
nowadays with a couple of engineers who can basically build up peer-to-peer
system in half a year time, okay.
So it's very easy to develop. And it has high scaleability basically says the more
users the better the system would be, at least initially for small groups, right? As
a group size increases, probably, okay, peer-to-peer stream mix cannot handle a
large number of users but at least initially the more users the better.
Now, it is higher user bandwidth experience it achieves a lower server bandwidth
requirement. It also take advantage of SS locality, so you don't have to -- if you
design a protocol good enough or well enough then the back-bone traffic actually
can be saved because it take advantage of SS locality. Whether today's mesh,
whether today's peer-to-peer protocol achieves that is another story, but
theoretically you should be able to achieve that. And there's no extra resources
beyond a set of box of PCs.
It leverages on the current unicast protocols such as the existing solutions and
functionalities of unicast's protocols can be [inaudible] applied such an RTP,
RTCP extension. There can be also applied in p2p streaming. So that is why it
leads to the ease of development and ease of deployment. Now, p2p concept is
based on the power of resource aggregation. So take some examples and then
the industry, the power resource aggregation. If each clients donates hundred
megabyte, small storage, 10,000 clients would then put one terabytes of storage
at your fingertip, right, in p2p network. 10,000 users would have one terabyte of
storage. So for example for one megabit per second movie [inaudible] no good
quality movie streaming the Internet, 100 megabyte actually correspond to about
10 minutes of video. So if you are able to cache or share each clients would
cache or share about 10 minutes of video, then you have one terabytes of
storage which is equivalents to three months of movies at your fingertips.
So that means that you can access three months worth of movies in the Internet.
So that is a huge amount of storage. And that is why you know at this p2p VOD
or, you know, other movies can be distributed in the network and assessed at
any time. So there's no more missing of your favorite programs using this p2p
technology.
On the other hand, you could consider live streaming if each client can serve on
one clients then we can virtually eliminate the server. So that is a theoretical
bond on the power of resource aggregation. So if the streaming is done properly,
actually both local and back bone network bandwidth can be saved, right,
because actually the hop counts per stream may be reduced using this p2p,
using this p2p stream technology. So that is why it's called ISP again. Whether
you achieve that in today's mesh protocols is another story. So this why we are
looking at how to decide protocols to achieve all that.
Now, there's a drawback of purely using p2p streaming, right? For example peer
may turn and hence affecting stream quality. So if peers churns, peer leaves,
peer fails, then stream quality will be affected and all the downstream nodes will
be affected. And this also legacy a box problem so if you have a setter box
which doesn't -- which have very programming capability with a very low storage
serving capabilities, then how to handle that is another issue.
This long delay from the server, right, as the -- because p2p streaming is based
on multi-hops approach, so the users may experience longer delay. And we also
need distributed and implementable protocols so it's not just distributed but it has
to be implemented in set-up box, in laptop so that it didn't consume lots of
processing. And [inaudible] many proposed p2p protocols do not work well with
large global groups, right? If you have a large global groups of millions of users,
current p2p protocols purely based on user level doesn't scale well.
So because that, they are all based on very ad hoc local connections. Basically
you detect close peers and you connect to them, try to get stream from them or
try to steal stream from them, okay. So if you cannot steal stream from them,
you go to other peers. So it's very ad hoc. The network resource utilization is
not that well. Actually there has been study on the current p2p protocols and find
that's long distance transversal, ping-pong kind of connections exist, okay, in the
network. So it doesn't. So there's a -- we still have lots of way to go in terms of
improving current mesh protocol. So that is the problem.
So that's why we have -- we would like to introduce proxy which are placed close
to users. So that reliable proxies are distributed the network placed close to user
pools. It provide a robust, efficient and high bath back bone so these proxies are
communicated as one level, okay. They provide our variable busts efficients and
high bandwidth backbone for the users. It also capture locality behavior, so if
you find okay, there's some hot spots in your network, you put, you know, some
proxies there, you place them and then the proxies would run additional protocols
to configure themselves as a high speed backbone.
It also save network bandwidth, right, because if you just stream to one proxy
and that proxy would serve the many users in their locality, in their neighborhood.
So peers paint their streams using some p2p protocols, so some peers here then
you form your local p2p network to further scale up the system. So this called
proxy based p2p network. And what is good about this system is that it offers a
natural backward compatibility with existing kinds of architecture. So if some
peers doesn't have legacy set up have some you know, devices which cannot
provide p2p capability such as mobile devices, low end devices, then these
proxies can then serve them. So it provides some advantages in using these
kind of architecture. Now, if -- yes?
>>: If the proxy like high end [inaudible].
>> S.H. Gary Chan: It can be, yeah, high end, yeah, it can be a high end
computer servers. Or it can be some kind of simple proxies, simple servers.
Doesn't need to be extremely high end. Some normal PCs would be enough,
right. But it has to be on some kind of broadband networks, right.
Now, if you look at these two levels actually they are very different in terms of
characteristics. In just a proxy level it is reliable and mostly and most likely it is
static, meaning you put there, you don't tier down, okay, tier it down. Okay. On
the other hand, for the peer it is very unreliable and dynamic, the peers come
and go, they fail, they may reboot their machines and so on, okay. So it's very
unreliable. And if there's a proxy, the introduction and removal of proxies may be
scheduled, so it can be okay occurred at some certain hours of the day and so
on. So it could be scheduled. Where the peer may join or leave at any time
without prior notice. So the -- so the thoughts is very lightly there, okay. Proxies
failures not so frequent or not so often but a peer's may fail frequency
unexpectedly. So to design, okay, a protocol for both levels is a design of them
would be very different.
Stream continuity can be better maintained at a proxy level but not so at the peer
level. So to maintain stream continuity at the peer level can be quite challenging.
So we are going to design protocols for both proxy level and peer level, okay, in
the following. Our industry their design concepts and the difference in terms of
their design methodologies.
So of course, okay, these proxies are running some kind of p2p protocol. You
can picture it, okay, which are based on mesh, okay. Mesh is to achieve
streaming rates with a C measure bandwidth so these proxies may communicate
using their limited bandwidth so they have to form a mesh. And on the other
hand, for the -- at the peer level, they also form some kind of mesh okay, to do
that. So the -- therefore, we have two level mesh. The first level is related to the
proxy level and the second level will be at the peer level. They all based on
mesh. But the mesh protocols are very different, okay. So they have different
consideration can.
Let's look at that, okay. Well, because our research is -- would focus mainly on
the delay issues, so we are going to look at what are the delay components in
the network. That there are two type of delay component, we can roughly
classify them in terms of mesh delay and packets scheduling delay, okay. The
mesh delay is mainly related to the propagation delay in the network, so if you
have two hosts connected in the network, then they have a propagation delay
between them. So the mesh delay would form. The deeper the mesh the higher
this kind of delay would be. So the mesh delay is incurred due to the longest
path length of the packets from the source to the node. So if a node would
experience on the delay because of the path length from the source all the way
to the -- to that node, it accumulates obviously quite fast as the number of users
increases, right, as number of user increases your mesh would be deeper, okay,
and your mesh would be bigger so the path length of the packets would be
increased.
>>: [inaudible] right?
>> S.H. Gary Chan: The mesh delay accumulates, okay.
>>: [inaudible].
>> S.H. Gary Chan: Okay.
>>: [inaudible] number of nodes.
>> S.H. Gary Chan: Yeah, yeah, so you ->> S.H. Gary Chan: So I see what -- okay. Okay. You increases, right, so
basically -- the point here is that you will accumulate as the number of users
increases and now there's the protocol if you look at -- if not designed properly
that it increases in the worst case linearly, right?
>>: Well, yeah, but I mean practically any protocol [inaudible].
>> S.H. Gary Chan: Okay. Okay. I would -- okay. Let's not worry about this fast
work. Okay. It increases, okay. We would like on make this increase the
increasing rates lower. That is the research motivation. Okay. Now, and there's
also a packets scheduling delay. It's due to scheduling packets with multiple
parents, right. So if you have multiple parents then there is a packet
transmission time between the nodes and the parents and there's a loss in the
parents and so this order arrive at the parents so you have to schedule your
packets and this scheduling will incur some delay.
So it depends on the packet and parent characteristics. These kind of delay it
depends on your number of parents usually and not so sensitive to the number of
users here. So it's a weak function of the number of users, okay, in terms of
packet scheduling delay.
Now, so -- yes?
>>: [inaudible].
>> S.H. Gary Chan: Error.
>>: What was [inaudible] of parent.
>> S.H. Gary Chan: Oh, parent in a mesh a peer has multiple parents to serve
them. Now, and their parents may have different bandwidth so you have to
basically grab packets from your parents. So whether -- which packets should be
sent from which parents is a scheduling problem.
>>: So this is a client that [inaudible] scheduling problem, so [inaudible] decides
what packet profile [inaudible].
>> S.H. Gary Chan: Yes.
>>: And you're saying this, the decision is sometime incurred in the making that
decision?
>> S.H. Gary Chan: There is that not just the time but it also depends on the
packets, the [inaudible] of the parents. So some parents may have some
packets missing, right? And some parents may have a difference -- may have
different packets received. So based on their parents received packets,
[inaudible] you have to pull packets from the parents so that you can have and in
order arrival at the node.
>>: Is that already [inaudible] in the mesh delay? What's the difference between
->> S.H. Gary Chan: It is a slightly difference. In the mesh delay you just looked
at the packets, the longest path from the source to the node, okay. We do not
really consider these kind of scheduling like a packet loss along the way. For
example if there's some packet loss then scheduling take care of that. But for the
mesh, we basically assume there's no packet loss in the -- in the tree and so I
would say that these two weakly coupled like they affect each other but when we
look at the mesh we just look at -- we usually look at the tree basically, look at
the tree, the aggregation of the spanning tree without worrying about how to do
the scheduling.
There's a different kind of scheduling algorithms would have difference delay
incurred ultimately at the node.
>>: So basically the first complaint is more like the static [inaudible] determined
by the compile [inaudible] of the trees. The second [inaudible] to capture
additional things.
>> S.H. Gary Chan: Yes. Additional things, the stochastic things you can think
of it, yeah.
So there's an additional delay incurred on that. So we are basically our design
principal is that we would like to first arrange the participating nodes which would
be proxy, which would be peers into some low delay mesh first. Put them in the
low delay mesh to reduce the mesh delay and then use some kind of good
scheduling algorithm on the mesh to further reduce the scheduling delay so as to
achieve an overall load delay for live streaming. So that is the design principal.
And yet [inaudible] work on this one first. So reduce the mesh delay. And look at
the scheduling algorithm later.
Okay. Mesh streaming as an aggregation of spanning tree, right. So suppose I
have mesh where the source is sending data to A and B, okay, and then A will
send some data to D, B will send some data to D, then the -- and D will incur -would then ago gates the stream from A and B and then serve A again. So
there's a cycle here, okay, a cycle. It allow cycle in the mesh, right. And so on.
And A also serves C and C also serve D, so D consolidate all these -- aggregate
all this stream and I go to A, right. So there's a mesh. Now, a mesh can be
considered as an aggregation of trees, right? It may have lobes, so in the terms
of this, if your trees the packet flow of each packets in the network -- in this
mesh, actually it can be -- this is a spanning tree, right?
So one tree is like that, okay. So this is one flow of packets can be like that as to
A and so on, so it's a spanning tree. And another is another spanning tree
[inaudible] by the dot line, okay, which is another spanning tree like that. So
there's two spanning tree here. So up here has a delay in each spanning tree,
right? For A for the first tree it has -- it cares about this propagation delay. This
is what I mean by a mesh delay, right? There's a propagation delay which is 10
here and this is for B is 15 and for A this is -- because A is relayed to A relays
streamed to D, so D has a delay of 26 and so on.
Okay. For the second tree, okay, look at the second tree, so it goes to the -- first
it goes to B, so it has a delay of 15 and then B will serve D so that delay will be -will be accumulated from 15 all the way to 24 and so on. So now each node here
would have, you know, different delay for different tree. So for A, for tree 1 is 10,
for tree 2 is 14. Now, then we say okay, well, how about what is the delay for
that node? The mesh delay we defined the mesh delay is the longest path of all
the trees. So if you look at here A in tree 1 is of delay 10 and tree 2 is of delay
14. Since A has to aggregate the packets anyway, so its delay would be 14.
Okay. For B, since B is aggregating stream so it is the maximum delay of that is
still 15, but for D the maximum delay would be 26. So if you look at that, then
these are the -- these are the -- this is the mesh delay which we did define as the
mesh delay for each of the node.
So the mesh delay is the longest path of all the trees. And we want to minimize
the maximum delay of the node. So again, again, okay, you may not agree with
me. Okay, pull up here. I should say quite quickly, okay. So the delay
accumulates. You can see that as the number of peers increases. So we will
like to reduce that. Mesh delay consideration is that first of all, we want to form a
mesh meeting the streaming rights requirement, right? This is the most critical
part. I have a streaming rate. I need to meet that. And a peer delay is proxy
delay plus the p2p delay. Both of them are mesh, right? So proxy delay appears
I assemble the stream and then I pass it to the peer. And the peer again has
another level of delay. So peer delays are awful delay. So we are going to adopt
this bottom up delay minimization.
So meaning that's peer level delay is -- can be fed back to the proxy level. So
let's say at some peers the delay level of the peers is known to the proxy, okay, it
can be estimated at the proxy, it can be [inaudible].
>>: So what are you [inaudible] stationarity of the delay?
>> S.H. Gary Chan: Station -- stationarity of the delay?
>>: Does that mean how slowly the delay have to change [inaudible] create ->> S.H. Gary Chan: Okay. Well, okay. Well for example for peer level, right, the
-- the peers, the proxy can be estimate -- can estimate the peer level on the mini
spaces or even hourly basis to monitor their -- the peer delay. And then the
proxy with a base on that delay, you know, shift their proxy level mesh. So that
you can reduce the [inaudible] of the peers.
>>: Okay, so you're [inaudible] delay state goes in the order of minutes ->> S.H. Gary Chan: Or hours?
>>: Or hours?
>> S.H. Gary Chan: Yeah, yeah. And then the proxy then has a delay which
depending on this peer delay and then -- and then they would adapt their proxy
level algorithm so as to reduce the overall delay, bottom up delay minimization.
Now, the [inaudible] is that the video stream can be considered to be transmitted
in K independent trees. So you pick up the video stream or you color the video
stream into K independent trees which we call substreams. The proxy we call
fast mesh protocol, the backup parents are not so critical, okay, because mostly
they are reliable and they are reliable nodes so it may have a single parent who
deliver all K substreams. So that is our consideration.
Regarding the peer level which [inaudible] mesh protocol, backup parents is very
essential for video continuity. Peer may fail and it must have at least K distinct
streaming parents, right, because if we have K independent trees so they have K
distinct parents so as to offer [inaudible] in the system and additional backup
parents for [inaudible] and how to find backup parents and streaming parents to
minimize the delay is the major consideration here. So there is a simply a
different consideration in terms of the design of the mesh level, the design of the
peer level and the proxy level.
There's some related work here [inaudible] methods by Michael [inaudible] so
they are all -- they are based on trees and they are very simple and very low
delay. But as we know, okay, trees are valuable to narrow dynamics so we are
looking at aggregation of trees, look at the delay. And there are some mesh
protocol there, so each peer maintains a list of neighbors and they use a gossip
or random search for parents to connect with them and help manner and so they
aggregate as a stream, and it is very robust, and you induce and overcome this
symmetric bandwidth problem and induces high delay and redundancies
because of this ad hoc nature in the connection.
And there are some scheduling algorithms in the mesh so this is not a focus of
work. And there has been some [inaudible] analytic studies on peer-to-peer live
streaming relating to game theory, how to use game theory to make connections,
curing systems, curing analysis on these p2pLive streaming and some
[inaudible] modeling on that, and we present a stochastic analytic model here for
the design of a robust mesh at the peer level. So we are basically coming up
with a model which can be used to find out the number of parents as needed at
the peer level so as to offer a certain stream quality which I will discuss that later.
So let me focus on the proxy level first and talk about peer level mesh and then
later on talk about our implementation effort.
Okay. So I would like just to highlight, okay, some of the for points here. So first
mesh I will first formulate the minimum delay mesh problem and [inaudible] is to
construct a mesh that minimize the maximum delay of the proxies and meets the
streaming rates requirement. And we can show this as MP hard so we come up
with some kind of centralized heuristics to sort of looking at the -- looking at some
of the performing limits on that. Then we propose a distributed protocol which we
call fast mesh which is based on some kind of a power heuristic or power
concept which balance the bandwidth and delay in the mesh -- in mesh
construction and periodic adaptation to further reduce the delay.
So this mesh then adapts themselves so as to keep reducing the delay to some
kind of minimal value. We have done some performance study and simulation
and also PlanetLab experiment. In this sketch the problem of this formulation I
have a proxy network characterized by a graph, okay. V is the proxy node and
some edges. It can be directed or not. It can be full graph or not. And there's
some kind of streaming rates of S units. So basically it means S spanning tree.
And the spanning tree delivers the K substream is denoted as TK. So that is the
Kth substream. And there's some kind of delay for every edge. So two proxy,
okay, there is some delay, DIJ between that. So then we can basically write the
delay of a tree given parents J is that the delay at tree K the parent has some
kind of delay DJ and then plus the propagation delay, the network probably built
the DIJ then you get the node I delay in the tree. And we want to find a sort of
mesh delay DI for node I in the mesh would then be given by the maximum delay
of all tree, okay. That it of all tree and then you get the delay of DI and then you
want to minimize that, minimize the maximum of this delay. So find the
streaming mesh such that every node, every proxy is fully served and you want
to minimize the maximum of the delay.
So this is -- so we are going to focus only on the proxy level, proxy delay here,
okay, without considering the peer delay and we are going to generalize that
later. So the problem is MP hard because it's reducible for a travelling salesman
problem. So I'm now going to show you how it can be reduced, okay, by that.
So a simple version of that would be a travelling salesman problem.
So we look at some kind -- yes?
>>: A question. [Inaudible].
>> S.H. Gary Chan: Yes.
>>: So that edges are [inaudible].
>> S.H. Gary Chan: Yes. For sum IJ, right, proxy I and proxy J you look at
propagation delay, so DIJ.
>>: [Inaudible] E is determined or it's [inaudible].
>> S.H. Gary Chan: There are the possible connectivities is known, is created by
this G, the graph G. So G doesn't need to be a compass graph. G can be some
kind of -- it can become -- it may not become [inaudible] depends on whether
proxy I is -- can connect to proxy J of a node or may connect.
>>: [Inaudible].
>> S.H. Gary Chan: Yeah, yeah. But in general. But our problem is general
enough that proxy I may not connect to proxy J probably is that because of ISP
policy probably whatever policy, so -- yes?
>>: I guess if you're say -- if you simplify it by distances and you're just
continuing them as hops and if the graph is complete then you just have to make
a tree that it's full, right?
>> S.H. Gary Chan: Okay.
>>: A complete tree. And that will solve its problem?
>> S.H. Gary Chan: Not really. Because I want to come up with K trees for that.
And each of -- and each node has a certain capacity. So this K trees cannot
overlap because each node has a certain -- has a fan out constraint. So finding
out a K tree which minimized the maximum delay of all the nodes is a different
problem. [Inaudible].
>>: [Inaudible] because the node is proxy node, proxy node [inaudible] a lot of
bandwidth. So argue that proxy node can serve, basically can itself get a stream
probably without too much difficulty? I mean, even in your early slides you said
that proxy nodes can multiple substreams.
>> S.H. Gary Chan: Right. Right.
>>: From [inaudible].
>> S.H. Gary Chan: Right.
>>: [Inaudible] the capacity of proxy nodes is [inaudible].
>> S.H. Gary Chan: Well ->>: Or it can be [inaudible].
>> S.H. Gary Chan: Yes. If you are considering that each proxy can serve.
>>: Serve the whole stream.
>> S.H. Gary Chan: Can serve the whole stream. But even can serve the whole
stream.
>>: Then it becomes the ->> S.H. Gary Chan: Then it becomes a sharpest spanning tree because
[inaudible] spanning tree then you can solve the problem, right? If not, if they
have had the [inaudible] bandwidth, then it will be -- there won't be a problem. I
agree with you, yes. Yes. So we are consideration a very general problem,
general context where some proxies may not have enough bandwidth to serve a
full stream. Yes?
>>: How do you determine the weight and how do you compute the delay?
>> S.H. Gary Chan: Oh, you mean this DIJ?
>>: Yes.
>> S.H. Gary Chan: Oh, DIJ for this problem we look at only the propagation
delay or end-to-end delay between two nodes, IJ. So it's a network delay
between I and J. It's a [inaudible] delay between I and J. So we are basically
looking at the problem in a very general context.
>>: When you say the delay, the delay is a propagation delay, a minimum
[inaudible] delay from the node I to J.
>> S.H. Gary Chan: Yes.
>>: Something like that.
>> S.H. Gary Chan: Yes. Yes.
>>: That is actually associated with the constraint that [inaudible] because when
the capacity [inaudible].
>> S.H. Gary Chan: Okay.
>>: [Inaudible] you do not talk that much.
>> S.H. Gary Chan: Right, right, right.
>>: [Inaudible].
>> S.H. Gary Chan: We look at only the mesh delay as formulated here. Right.
>>: I think for that [inaudible].
>> S.H. Gary Chan: Yes. Unless you even want to use up the residual
bandwidth after serving the full stream, right? If your proxy has, you know, the
bandwidth 1.5 bandwidth, then you must use up the .5 to do the construction.
Then it will be -- you still have this problem, right? Unless you want to throw
away that residual bandwidth. Then you would affect the delay of the network.
Okay. Very good questions. Okay. So we come up with some kind of
centralized issue. Mistakes for that. These are not heuristics, it's based on
complete knowledge on the network basically you know the network bandwidth,
the fair node of the node, the residual bandwidth, okay, the delay of the DIJ and
[inaudible] location so you know everything then it provides some kind of optimal
performance of the network. Okay. I see some kind of -- because even it's
heuristic, right, it's not an absolute optimum performance.
So it provides some kind of a benchmark for our comparison of distributed
protocol. Yes?
>>: That protocol, the heuristic depend on the compute knowledge of the
network in.
>> S.H. Gary Chan: Our digital protocol does not depend on the complete
knowledge, yeah, but the centralized one, yes, it depends on that.
>>: [Inaudible].
>> S.H. Gary Chan: Yes, it depends on the complete knowledge. There's a
centralized one. Let's say you assume, okay, let's say you assume that you
know everything about the network. How well can you do, okay? That is the
[inaudible] and the distributed protocol is that how much you sacrifice, you know,
make it distributed.
Well, I would -- I don't want to tree off too much into it. Let me skip that, okay.
So it's a centralized heuristic. Okay. Now, in coming up with this [inaudible]
heuristic, okay, we omit use of this kind of power concept. So what is power,
okay, in traditional network? Power is defined as a throughput divided by the
delay, right, so we are going to use that, okay. So what is throughput, what is
delay, how is it -- how can it be cast into this p2p context is the issue.
Okay. So first of all, we asked a proxy what is a high bandwidth and low delay
nodes to be his parents, right? Everyone wants a high bandwidth and low delay
nodes to be his parents because if high bandwidth nodes then you are going to
get a complete stream from it.
But at the same time, if the node is low delay, then you want to have it as a
parent because then your delay will be lower, right. So but how to balance them,
right? Sometimes the high bandwidth nodes are farther away from you, okay.
Sometimes the low delay nodes may not have enough bandwidth to serve you.
So you need to do a balance between them.
So if we consider a node I so we look at this power, try to balance the throughput
and delay, okay, so the throughput is defined as the rates that node J can stream
to node I, okay. So meaning that if node J, okay, has a high residual bandwidth,
then it might be a good parent of mine, of me. So it is the rates that node J can
stream to node I, okay. We like to be large, okay. So in the centralized heuristic
the through puts of this spanning tree is one unit. So if the residual bandwidth of
that node, okay, can serve one substream to me, then I would make this
throughput as one, okay. If it's .5, then I use it as .5 and so on. So as using this
throughput, I can rank my potential parents.
Delay is the source to not delay to node I. So we would like it to be low too. So
having high bandwidth or high throughput, low delay nodes, then this power
would be very high. So by picking those high power nodes, then we can have,
you know, a decent selections of my parents. So power balances, throughput
with delay and makes sensible choice on my parents.
So for the centralized algorithm with tree bandwidth of one unit, so if everything is
one unit then we simply look for the node with the lowest overall source to end
delay to be pushed into the tree. So we keep pushing things into the tree until
we fulfill all the streaming requirement, meaning until we construct K trees.
Our centralized heuristic. Now then we look at how to do it distributively. The
proxy join is that the joining of I then I even obtain some existing proxies from the
LP, from the linear point, and for each P or J obtained you calculate the power
between J and I, because you can do a pain and then you can look at the
residual bandwidth and then you can calculate this power. And then after a few
runs then you basically connect the proxies with the largest power until you are
fully served. So proxy maybe introduced or removed. So then we can let's say if
proxy is introduced or removed then there is some adaptation algorithm going on
to continuously improve the mesh delay by pushing up and down the nodes.
So the mesh initially formed would be continuously being improved and so
basically you promote those high bandwidth nodes closer to the source and
denote those low bandwidth nodes away from the source to optimize the mesh.
So the way to do that is to through some kind of process like a request grant and
accept, so each node periodically will [inaudible], okay, their parents, to see
whether their parents have high bandwidth or not, okay.
If your parents have low bandwidth than you, then basically the child can be
promoted, okay, promoted higher up and so on. So you use this [inaudible] and
through this grants, this grants meaning that those parents will then telling, okay,
the child their bandwidth, their residual bandwidth so as to grant them, okay, the
rights to be promoted.
And finally the child will select, okay, certain nodes to do this swapping, to do this
promotion and demotion. So that go through some kind of three steps.
>>: [Inaudible] I mean a mesh [inaudible].
>> S.H. Gary Chan: Sorry. Proxy. This is proxy. This is a proxy level. Even for
proxies they need to continuously optimize their network. Okay. Again, okay,
the power is computed, okay, similarly as before. You look at the residual
bandwidth of the parents and the streaming rates of the -- of the parents which is
S is the maximum streaming. So if you are -- if the residual bandwidth of the
node is higher than S, then you will use S because of the parents can serve a full
stream to you.
But if the residual band is lower than that, you will take the residual bandwidth.
>>: [Inaudible] residual bandwidth is?
>> S.H. Gary Chan: Well, it depends on because each node when they serve a
child they will allocate some kind of bandwidth, right. The video is divided into K
substream so they would know, okay, how much bandwidth they used. And then
they will also know how much bandwidth they have. So subtracting that will get
the residual bandwidth. Okay.
>>: So depending on how much bandwidth they have then [inaudible].
>> S.H. Gary Chan: Right, right.
>>: [Inaudible] a priori?
>> S.H. Gary Chan: Yeah. It is known a priori, yes, right.
Okay. Let me see. Okay. So somewhat generalization. So suppose your peer
level feedback to the proxy, their bandwidth let's say the maximum delay or the
peer level feedback to the proxy their average delay so let's say the proxy knows
the average delay of his peers, then you can modify your power computation
accordingly so as to form a better proxy mesh, okay, given this information. So
this is generalization of delay optimization. I will not draft too much into that.
Let's not worry about that.
So that give the details of how to do the proxy promotion and demotion. No child
has -- if the child has a lots of residual bandwidth then it should be promoted to a
higher level for delay improvement, right, because your fair node would be larger
so you want to -- you want it to be promoted. Some nodes may need to be
demoted because of that. So you go through some kind of three steps.
So let me not worry about this, basically talk about the details of the algorithm.
Now, let's look at some results. Yes?
>>: [Inaudible].
>> S.H. Gary Chan: You want to look at it? Okay. Sure. Okay. Now, okay,
now, let's say I'm at the bottom, this child. This child is periodically exchange his
residual bandwidth, his bandwidth statistics to the parents. Now, so it will first
have what we call TTL, or time to live, basically telling how many levels up that it
was to visit, okay, so how many ancestors he want to visit.
So first, okay, F will tell his parents is available, is available bandwidth TTL, so
how far the message be forward and its IP. So F would tell his two parents.
Now, the two parents we look at their bandwidth and compare its bandwidth with
the bandwidth of F. If they find out, okay, their bandwidth is lower, okay, that
means that they are a poor choice of a poorer choice of parents than this child.
So they will -- they would cross the child, the rights to be promoted. So first a
forward to those two nodes, okay. The two nodes receive the message compare
their bandwidth with the bandwidth of the child, okay, because a TTL is two, right,
so they would -- they again forward the message by F to next level higher up. So
E would then forward to D and then D will also forward, okay, to C and A. And so
on.
So now A, C, and B will then compare the bandwidth with F bandwidth and then
to C, okay. Whether they a good choice of ancestors or not. Okay. For F. So
everyone checks that and grants E, okay, E is a poor choice so E grants to F the
right to take his place and furthermore others will do the comparison. And let's
say C, B, and E has a lower bandwidth than F so they are -- they will send a
grand step to F. Okay.
Now, F receives, okay, the bandwidth statistics of all these nodes. And then he
has to make a choice of which nodes to be promoted. Okay? Let's say F would
like to replace B, so the way to do that is either take the place of B so you can
picture it as a [inaudible] so S you then serve F. And then F will then serve B.
Okay? And then you cut away this tool. So the way to do that is -- let me see. F
has chosen B to swap, so it does the promotion like that.
Now, F is then promoted up, okay. So all the way from the bottom to be
[inaudible] S and to serve B. Because F has a high bandwidth so it can fan out
much faster, right, than B.
>>: [Inaudible] also need to know F's distance to B, C, and A's parents. We
need to know that, right?
>> S.H. Gary Chan: Yes. This is based on power. So also it somehow has this
information.
>>: So they can [inaudible] need to promote [inaudible] search their radius to the
distance?
>> S.H. Gary Chan: Right.
>>: You actually need to know all the radius B's parents, right?
>> S.H. Gary Chan: Okay. No. No. Actually you only reach to B and that's all.
So you don't look at B's.
>>: But you need to know the [inaudible].
>> S.H. Gary Chan: Yeah, yeah, yeah, yeah because -- yes. Because S
basically you swap with B, so you have to know B's parent in order to be swap,
right.
>>: Another issue is that this power definition is basically throughput divided by
delay?
>> S.H. Gary Chan: Yes.
>>: Right?
>> S.H. Gary Chan: Yes.
>>: That means if you have a very thick swoop of nodes.
>> S.H. Gary Chan: Yes.
>>: It can be [inaudible].
>> S.H. Gary Chan: Yes.
>>: It may not be a good choice for [inaudible] but just doing [inaudible] say I
mean let's say [inaudible].
>> S.H. Gary Chan: Okay.
>>: [Inaudible].
>> S.H. Gary Chan: Right, right.
>>: Sources [inaudible]. This delay's throughput is actually maybe favorable
than the node in [inaudible].
>> S.H. Gary Chan: I agree, yeah.
>>: [Inaudible] something?
>> S.H. Gary Chan: Yes. It's a balance basically. Yeah, yeah. So it's not
perfect. I would say in all scenarios. So the balance between the throughput
and delay and the fair node and the depth of the tree and so on. So if you have a
better idea how to do it, how to come up with a metrics to waste them, then
certainly you would be good.
>>: [Inaudible].
>> S.H. Gary Chan: Right. Right. But, yeah, something we come up with I think
is work pretty decently. So we look at simulation result [inaudible] using
[inaudible] some routers, lanes and the peers because we need proxy, okay, are
distributed in the network there's a streaming rate so we build 10 trees, 10
spanning trees, okay. And the again proxy bandwidth distribution, okay, is
heterogenous and proportional to this value.
Okay. Now, so this shows the maximum delay against the proxy number, okay,
P meaning proxy number here. Our centralized algorithm is this one, okay,
which is quite flat, okay, independence of number of peers, which is quite good.
And then this is our fast mesh, this is our proxy, okay. As the number of proxies
increases, okay, the delay is also increases.
And some of the other mesh protocols like all rich, okay, and if you look at the
closest parents, it is like that. So it increases. So if you look at the mesh you
build the mesh carefully, indeed you can cut the traditional closest parent
approach of a mesh construction, cut it by half. Okay. Almost like half here.
So that you can see this is a substantial reduction in terms of bandwidth. And in
terms of delay. In just a hop count it follows the same trail basically they are
related so in term of hob counts, okay, you follow the same trend against the
closest parents, look at the closest parent you have again a reduction in terms of
the hob counts using the fast mesh.
The reason is that you promote those high bandwidth high up, right, so of course
you are hob counts will be reduced and your delay will be reduced.
>>: [Inaudible].
>> S.H. Gary Chan: Oh, centralized algorithm. Okay. It's a heuristics based on
power.
>>: Okay.
>> S.H. Gary Chan: So let's say you know everything about the network. So
instead of knowing some local, you know, one or two hops away from a node,
you know everything so you can optimize things globally to connect to that,
connect the mesh together. Okay.
>>: Another thing is [inaudible].
>> S.H. Gary Chan: Yes. So in a centralized one, then you basically look at
each node and then you allocate some bandwidth, some bandwidth to each of
the tree. So you don't want to consume all bandwidth. So that's a -- so you
leave some bandwidth for later tree construction. So you put a ceiling on the
amounts of bandwidth allocated to tree K. So there is a -- there is some kind of
maximum ceiling, a ceiling in bandwidth allocation for the tree K.
So based on that, you can construct something which is decent, which is good.
Delay reduction due to [inaudible] so we have adaptation. We get adaptation just
through the promotion and demotion, right? So if you do not have adaptation,
meaning that you -- once you join the network you stay there, you never change,
then this is the delay, okay. But if we do adaptation, then actually this is the -this is the delay curve. So you see that adaptation does has a defense, okay, if
terms of the delay of the proxy level. No need to have a high TTL in the
adaptation because obvious we have -- if you have TTL of one, so you just
exchange it to your parents, so average delay of delay reduction so then you
reduce some delay, okay? But if you have TTL of seven, which is really high up,
so you exchange message with lots of your ancestors, then this is your delay
reduction. So we just -- it doesn't worth it.
So we basically can have a delay, have a TTL of a few would be enough. One or
two would be good enough. Low server, very low server workload. So that -this is the centralized algorithm, this is the fast mesh outreach and closest pair.
This is the all rich, and this is the closest parent.
>>: [Inaudible] unit of the server and [inaudible].
>> S.H. Gary Chan: The streams. The ->>: [Inaudible].
>> S.H. Gary Chan: The stream, number of stream provided by the server.
>>: How many [inaudible].
>> S.H. Gary Chan: How many what?
>>: How many [inaudible].
>> S.H. Gary Chan: Oh, the number of proxies, which is 1,000, right? So one
stream. It's one video.
>>: One video and the video unit is one?
>> S.H. Gary Chan: Yes. S [inaudible] units. So -- okay. Okay. This is a serve
workload is in terms of the unit, so if you -- let me try to see. Yes. This is -- this
is -- this is -- okay. One stream is -- okay. Let's say one unit here. So this is 150
stream here.
>>: In that case, the centralized stream, the server [inaudible].
>> S.H. Gary Chan: Yes.
>>: From [inaudible].
>> S.H. Gary Chan: Yes.
>>: Okay.
>> S.H. Gary Chan: So here ->>: [Inaudible].
>> S.H. Gary Chan: This is a server, that is the -- that is the server capacity, and
you can picture that. It's a server capacity. That is the server capacity as
needed to serve these users.
>>: Okay.
>> S.H. Gary Chan: So the -- you can see that the centralized algorithm does
take advantage of the peer bandwidth.
>>: Why then choose to serve lesser bandwidths? I mean, basically minimal
and the server only needs to serve one stream now, right? [Inaudible].
>> S.H. Gary Chan: Yes. But the -- we would like to minimize the maximum
delay. So I [inaudible].
>> S.H. Gary Chan: Yes, [inaudible] that, yeah, so you don't want to [inaudible].
>>: [Inaudible] why doesn't the server just send directly to minimize the delay?
That would minimize [inaudible] I mean, are you putting a limit on -- I mean, isn't
this the bandwidth [inaudible].
>> S.H. Gary Chan: That's a good question. Let me see. If the server the
slowest workload I know that there is a limit on the server bandwidth. There's a
limit on the server bandwidth. But it's not infinite. If it's infinite then certainly a
[inaudible] would be the best, definitely. I have to check the paper. Actually this
has appeared in the [inaudible] so I have to check the parameters. But I know
that there is a limit on the server bandwidth, so that meaning you cannot serve all
the users here.
Okay. Now, we also -- we also look at the loop base and loop base and loop free
mesh construction. Okay. So loop free meaning you impose a loop free
condition on the mesh. You cannot have loop. And you also? Let's say you
have a loop base, meaning the mesh may have loops there. So we can see that
if you have a loop free condition, the average delay is higher. But if you have a
loop based condition, meaning you may have loop, then the delay is lighter
[inaudible]. So meaning that if you are -- if your bandwidth is high enough then
the loop free -- the mesh will be constructed less likely to have loops.
So but if your bandwidth is not really enough, then having loops in the network,
okay, having this loop free, having loops in the network may -- can reduce your
delay. Of course it is again reasonable. So that is this what we have found. And
we have also done this [inaudible] experiments which took place in August 2008,
and there are 45 nodes and so are consistent of all these places. So we have
some statistics like a proxy delay which basically shows that it peaks at, okay,
some value and then there's no -- there are not many outliers there. This one of
the mesh server is at Hong Kong. You see that, okay, these are all, okay, the
mesh are constructed in this way. So it looks like, okay, it looks like we are
performing on K. This data is something like that here, okay, poor because
there's a high speed link between them, okay. High speeds we measure the
delay. That delay is very low, so that's why there's a high speed link there. But
->>: [Inaudible].
>> S.H. Gary Chan: Okay. So this is the source and, yeah, we can put some
number there, the delay, okay, the delay number there to look at, okay, the delay
of the node. Yes, I think we can do something there. Put a delay there. But
these high speed links when you paying that delay is very low. That's why
there's this kind of [inaudible] there. And in China it's very, very interesting. Like
the node here does not serve directly to the node there, but go through this node
and serve there, okay. Because of policy, some ISP policy there.
>>: What is [inaudible] there's not much speed formulation -- so I mean one
thing is that the mesh component is not [inaudible] basically for one of the
[inaudible] receiving something like [inaudible].
>> S.H. Gary Chan: Right. Right. Yes. Yes. Yeah. That is the point. If you
look at here, this node actually is served by two parents.
>>: Yes.
>> S.H. Gary Chan: Right. But there's not many. Like 10 percent. One way you
find is 10 to 20 percent of the nodes are -- have multiple parents.
>>: Most of that is actually a tree.
>> S.H. Gary Chan: Right. Right. Yes. Yes. That is basically saying this
algorithm is K, okay, because we're supposed -- tree is the most efficient if you
want to build things. Actually our ->>: [Inaudible] I'm not should sure if [inaudible].
>> S.H. Gary Chan: Actually if you are -- if you have abundance bandwidth hour
algorithm reduces to prime algorithm so minimum spanning tree.
>>: [Inaudible].
>> S.H. Gary Chan: Yes. There's one special case of a algorithm.
>>: The closest parent algorithm [inaudible].
>> S.H. Gary Chan: The closest parent -- oh, the mesh. The mesh, meaning
that you keep paying the nodes until you find the closest parents which is in
terms of distance and then you ask the parents to pull.
>>: In terms [inaudible] of distance.
>> S.H. Gary Chan: In terms of distance. So you keep paying until you find the
closest one, and you'll make them as your parents. So the closest one.
The closest parent -- the closest node with residual bandwidth. So you make
them as a parent.
>>: [Inaudible].
>> S.H. Gary Chan: Closest in narrow distance.
>>: What is [inaudible].
>> S.H. Gary Chan: Paying distance.
>>: [Inaudible].
>> S.H. Gary Chan: Yes. Which is the roundtrip time. Okay. Fast mesh
conclusion. We have formulated problem [inaudible] centralized algorithm, so
power concepts which performs quite well, and we have a distributed protocol
which dynamic -- which have a dynamic adaptation to continually improve the
mesh delay. And the studies in experiments, we have done that.
Now, okay. Well, this robust mesh, I guess I cannot go much further than this.
Okay. Robust mesh is for the peer level, okay. So the design is slightly different
from the -- from the proxy level because we have to offer a certain stream
robustness at the peer. So we have to consider, okay, suppose you have
multiple parents and your parents have a certain churn rates, okay, apparently
they go. Now, then we need to model it such -- we need to model that such that
if a parent goes you still have some backup parents to help you so that your
stream continuity can be maintained, your streamy loss can be maintained.
So the question is how many streaming parents you should have and how many
backup parent you should have. So that if your parents departs in a stochastic
manner, your stream continuity would not be affected, okay. So the way to do
that is that you model the network as a queuing network because every time your
parent goes, okay, then you start to find another parent. Now, during that
process, as in the process of finding the parents, some of your parents may also
go. So the probability of having the number of parents lower than the full stream
capabilities has a below so that you guarantee the stream continuity.
So basically, okay, the way to do that is again this multiple tree approach and
look at the number of parents a node may have because which is -- which is the
state of a node, okay. You might have zero parents, meaning that all your parent
churns, churn away in the process of finding new parents, okay. Or you can
have one parents, two parents all the way. If you have K parents then you have
a full stream, right. You have K parent you have a full stream. Now, if you have
K plus one parent, meaning that you have one backup parent, you have K plus
two parent. You have two backup parents and so on. So you have -- so you
have to find K distinct parents and T backup parents. So this is the states, okay,
the number of parents you can have at one time, okay. So this is the state.
Now, if the -- because the churn rates is mu, so the downward transition is when
you are in state K is K mu, so if you are state 4 then you have less than K
parents then your stream continuity would be affected. So around these states
you have stream loss, you be substream loss, okay. But beyond that, if one of
your backup parent goes away, you still have a full stream. So you are not
affected, right.
Now, if one parent churns, then you have to find other parents. That parent
would take some time to search for the parent. And so the search would be
again [inaudible] the explanation process and so on. So this is an amazing
model. Yes?
>>: [Inaudible] each tree are different, right, so having K tree doesn't always
mean having a full stream [inaudible].
>> S.H. Gary Chan: The rates are the same, okay, meaning I pick up the video
stream into K equal substream. Right? For simplicity. You can -- yeah, yeah,
for simplicity purpose. We do it that way. And so on. So we can basically based
on this mistake transition we can then look at their loss, stream loss
characteristics.
So then we can design the algorithm accordingly. So we not worry about this.
So this shows that our analysis and simulation agrees quite well. Now, and
some of the results here. So let me try to talk about our project, HKUST. We
have some slides for that. So at HKUST actually we have IP TV project called
AnyView. So what is AnyView? Some of you may wonder. Okay. So AnyView
stand for view anything, anywhere, anytime in any way, okay. Any way mean
that you have interactivity. Anyway. So Chinese is like that. Okay.
So this AnyView project is a government fund in industry supported project, okay.
Actually this is by the Hong Kong information technology fund, okay, that we
work with Quantum Companies, Cisco, Sun, and some Hong Kong companies to
make it possible. We collaborate with university in China to do some field trials
and testing because China network is really a very different kind of network as
compared to US and Hong Kong, okay, so we have to do some testing. And a
lots of strange behavior, okay, comes out if -- when we work in China on few
trials. So we develop some p2p solutions to IPT [inaudible] movies so we have a
system on that, and naturally we are in the process of spinning off, okay, that
company.
So the protocol we used is the -- is called SIM, Scalable Island Multicast.
Basically this is we reported about two years ago and we build a p2p network
making use of multicast capability, which is called multicast islands, so we
basically we first defect multicast islands in the network with the islands
[inaudible] and then build overlay to wire them up, okay. So that's to make it a
seamless overlay IP multicast capable network. So because IP multicast is more
efficient, so we want to make use of that every time we hit multicast island.
So this protocol you note like it has IP framing because you use IP multicasting, it
has forced tolerance because each P actually has multiple parents, and for error
recovery it support dynamic user traffic and it support net transversal. So the
way to do that is to have a server and the server will then use overlay to serve
peers. Now, and then once you detect an island that peers would then multicast
its packets in the island using multicasting. And then you -- if you do not detect
islands, you use p2p, okay.
And then all the way until you hit an island, then that peers would send the
multicast packets out into the island. So we have this kind of distributed
protocols there to address three issues. How to construct the overlay tree which
is this one, okay, which is the multicast incapable connection. And how to
integrate it with IP multicasting. Okay? And some of the protocol implementation
issues are lots of threading, lots of operating system issues there. Okay. So
these are the -- so we are focussing on these two areas in terms of protocol
design.
So there are two groups there, okay, for each video, okay, there are two groups.
One is the control group where to let the peers communicate with each other is a
multicast group, okay, communicate with each other so it's a detached island.
There's a control group. And there's a data group which basically is a video,
video stream, video stream group. So peers get their video from this data group
and communicate with each other using this control group. And so on. Okay.
Each island has a unique ingress so we have to have ingress node selection. It
has a unique ingress.
And basic, basic [inaudible] ingress node receive packets outside the island and
multicast it within this island so it is a very important node in the island. But when
the ingress leaves or fails, then it can elect a new ingress for that island and so
on. So he has a periodic multicast some kind of messengers in the control group
so as a signal to others that there's an ingress in the node, in the island and
serve the -- and being and serve the community. So on.
So these are the protocol. We do basically first construct a tree and then you
detect islands. So on. Let me not trail off into the details of that. And we have
done some simulation on that and it has been shown in some of the show there,
okay, in some demo. And we have a corner showing this, these are the set up
box prototype, so on. And now if you work with some quantum companies and
some [inaudible], right, in China, to work on that. Okay. Thank you. Any
question?
>>: On this [inaudible].
>> S.H. Gary Chan: Okay. So far we have one test on that for more than
hundred nodes there.
>>: Okay.
>> S.H. Gary Chan: The trials had some data we're analyzing some data. Some
of them are on multicast islands, some of them are not, so we look at, you know,
their performance, their delay performance and so on.
>>: I'd be very interested to know [inaudible] multicast islands.
>> S.H. Gary Chan: Yes.
>>: How much of those islands are actually [inaudible] extend beyond the
university [inaudible].
>> S.H. Gary Chan: Okay. Actually we did some study on this cafe, Internet
cafe. They're all on multicast islands. So if an Internet cafe is on multicast
island. University of course. Even one ether net cable is a multicast island. So it
is there everyone.
Now, for HKUST, when we are in congregation then the whole campus would
then enable this multicast capability.
>>: So for this multicast [inaudible] how many of the [inaudible] observe?
Basically I mean [inaudible] cafe.
>> S.H. Gary Chan: Right.
>>: It is on the multicast island.
>> S.H. Gary Chan: Right. Right.
>>: How many of the users actually go on that [inaudible].
>> S.H. Gary Chan: Oh, I -- a few probably, a few. In Hong Kong if we have a
Teleco, PCCW, and they are providing IP TV solutions to all the users in Hong
Kong, millions of them, half a million actually, actually the PCCW's backbone is a
multicast capable backbone, so they use multicasting solution to serve this IP
TV. Yes?
>>: [Inaudible] heuristics, okay, I wonder how you can exchange the data in
order to get the centralized view [inaudible].
>> S.H. Gary Chan: Okay. Okay.
>>: [Inaudible] delay and delay [inaudible].
>> S.H. Gary Chan: Right. Right. Right. Okay. Okay. Yeah. Centralized
algorithm. We don't look at the messaging problem because a centralized
algorithm or centralized heuristic basically means that suppose you are a god,
okay, you know everything in a network. How well can you design it in how well
can you design the network? So you don't really look at the protocol issues or
the scaleability issues and so on. So it's a -- it's like that if you have information
how well can you do? So there's a limit.
>>: And the other question was the amount of the churn [inaudible] did you
further study this issue?
>> S.H. Gary Chan: The churn rates?
>>: Churn rate of a [inaudible] model.
>> S.H. Gary Chan: Yes. Yes. Yes, I did. Yeah, so suppose the may fail or
leaves at any time without prior notice with some rates [inaudible] then how
should you design the mesh so that it can -- it can guarantee a certain video
quality, right?
>>: [Inaudible].
>> S.H. Gary Chan: Sure. Yes. We have a working paper on that. You can
send me e-mail, we have a working paper on that. So I can send you the
working paper.
>>: And the other things about the proxy design, what when I asked you about
the high end computers.
>> S.H. Gary Chan: Yes.
>>: Okay. The question was how to distribute this, you know, who's going to
own the computers. Because currently like there is this cooperation between like
Comcast and [inaudible].
>> S.H. Gary Chan: Okay.
>>: [Inaudible].
>> S.H. Gary Chan: Right. Right.
>>: [Inaudible].
>> S.H. Gary Chan: Okay. So do you suggest those computers be online by
their ISP or by individual companies or by [inaudible].
>> S.H. Gary Chan: Okay. Now, actually that proxy based p2p network comes
up from our development, okay, from the same DB implementation, we find that
using a pure p2p technology doesn't work for large number of users. So we start
to put proxy everywhere in the network to help peers. So that proxy in our home,
in our lab, in somewhere with a higher bandwidth we put the proxy together and
then a sort of partition the network into some small groups. So and then the
proxy would then help to get the stream for the peers. So to answer your
question, where do you put the proxy? Campus, okay, our home, and
everywhere. So it is by the content providers it can be put by the content
providers.
Now, if it was to manage a proxy better then certainly ISP has to help you to
manage the [inaudible] servers.
>> Jin Li: Any more questions?
>> S.H. Gary Chan: Yes.
>>: Outreach algorithm, what it is.
>> S.H. Gary Chan: Yes.
>>: What is that?
>> S.H. Gary Chan: That's based on a mesh by the Professor Li and it is mesh
and it has additional information in building this mesh. It's also look at the
bandwidth of the node. So it basically look at the bandwidth of the node and try
to put things similar to -- similar to our setting basically. You know the bandwidth
of the node, you know the delay and you know how to configure, yeah, the mesh.
>> Jin Li: Okay. Gary will be here for two weeks, so if you have any further
questions feel free to catch him or if he wants you're free to e-mail him. Okay.
Thank you very much.
>> S.H. Gary Chan: Thank you.
>> Jin Li: And thank you.
>> S.H. Gary Chan: Thank you.
[applause]