Subject: Re: [ppsp] problem statement of ppsp(new version)

From: "Hui Zhang" <[email-masked]>
Date: Thu, 13 Nov 2008 19:05:31 -0500

Hi,hui,Please check inline of every question for the reply.Wish to get
your reply.

1. The motivation/selling point for PPSP is not very strong/clear. If

PPSP is to offer a full stack (signaling+transport) of specification,

will service providers like PPLive be willing to rewrite their code from

scratch? 

Should we more consider PPSP as an incremental part to the existing many

P2P multimedia applications?

Answer:I've talked with PPLive about its participation in standards.It's
active in 

this matter.In my final vision,PPSP can provide a full stack for a new
application developer and for the existing applications,PPSP can provide
interface to these applications which can interact with full PPSP stack
applications.

[Hui Zhang] my concern is that a full stack could be very heavy and then
specific to video streaming services. This could limit its adoption to
both the existing video streaming services and other P2P multimedia
services, as compared to a light protocol which offers a set of
functional blocks such as load balancing, high-quality peer selection,
resource discovery, etc. anyway, it is a first point for discussion.

 

2. Should we consider VoD application in PPSP? Given the nature of VoD

requests is one-to-one (video server to a requestor), we might want to

focus PPSP on broadcast-based video streaming applications. Do current

service providers like PPlive really use P2P tech for VoD delivery?

Answer:Oh,I have a different view of it.The requester requests a file
name to a certain server(maybe not video server,just a certain tracker
according to DHT algorithm)but the real data are stored in many peers.In
this sense it's one to many communication.

PPlive has deployed P2P tech for VoD delivery.You can refer to
"Challenges, Design and Analysis of a Large-scale P2P-VoD System"
appeared in Sigcomm2008

[Hui Zhang] yes, I agree. there is P2P VoD, although they still heavily
rely on content servers from the service providers themselves for data
delivery. But from PPSP peer's view, it is still about get a chunk from
somewhere (either peer or content server), the same as in channel
broadcasting. The difference from channel broadcasting lies in how the
data chunks are distributed from content servers to peers in data
caching.

3. The idea of bringing CDN into PPSP design is interesting. This CDN

issue can be thought of being a part of the ALTO solution in PPSP, and

the question for discussion is where in the PPSP protocol stack an

interface to the ALTO solution should be explicitly designed and

provided? 

Answer: This is a good suggestion.I like it&#61514;

[Hui Zhang] actually current service providers like PPlive already had
this CDN+PPSP architecture if you consider their backend content server
cluster as a CDN point.

4. The discussion on PPSP transmission protocol (Step 5) got me

confused. Do we really want to enumerate all possible parameters the

current P2P streaming protocols implemented in their chunk

transmissions? Or should the chunk transmission process be mainly left

as a black box to hide individual implementations, which could be deemed

as the core tech by P2P streaming provider, and PPSP will focus on the

interfaces between transmission protocol and signal protocols, and the

transmission protocol and the common new service part such as CDN or

other ALTO parts?

Answer: Good.This is a question we need to have a sound discussion. In
my point of view, all the interactions that cannot be done by a peer
alone should be standardized by PPSP including chunk transmission
process. If PPSP transmission protocol focuses on the

interfaces between transmission protocol and signal protocols as
mentioned, I haven't a clear view of what it really includes. I agree
that the common new service part such as CDN or

other ALTO parts can be standardized in PPSP transmission protocol like
p2p-type CDN as delivery platform transmitting from source to CDN nodes
which is not discussed in current CDN or CDI standards in IETF. Also the
interface between ALTO and PPSP transmission part can be standardized
here. But it may has similar effect as step2 goes.Right?

[Hui Zhang] as in Zong Ning's survey, the transmission protocols are
typically either TCP or UDP. My concern here is can we (or if it is
needed to) work out a new transmission protocol for video streaming.
Sure RTP seems not to be a fit for trunk transferring in P2P streaming.

4. We need a good survey on current P2P streaming technologies. I know

there are some surveys on internet video streaming technologies, but

they typically cover multimedia techniques in traditional centralized

architectures; as for the detailed technologies used by popular P2P

video providers such as PPlive, does anyone known good related articles?

Answer: Exactly right. In fact we arrange such a survey presented in the
bar bof.

As for survey paper and pplive paper, several good papers are
recommended:

1)    Insights into PPLive: A Measurement Study of a LargeScale P2P IPTV
System

2)    A survey on peer-to-peer video streaming systems,byYong Liu,Yang
Guo,Chao Liang

3)    Challenges, Design and Analysis of a Large-scale P2P-VoD System

4)    PPLive -A Practical P2P Live System with Huge Amount of Users

[Hui Zhang] thanks a lot!

Best regards,

Hui

_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: "James Seng" <[email-masked]>
Date: Fri, 14 Nov 2008 09:56:53 +0800

I am speaking on the behalf of Shanghai Synacast Media Tech aka PPLive.com.

Rewriting our protocol is a major engineering effort and is something
we cannot commit at this moment.

Nevertheless, we are interested in PPSP and would be glad to
participate in the working group (assuming it is approved).

> specific to video streaming services. This could limit its adoption to both
> the existing video streaming services and other P2P multimedia services, as
> compared to a light protocol which offers a set of functional blocks such as
> load balancing, high-quality peer selection, resource discovery, etc.
> anyway, it is a first point for discussion

Generally speaking from experience, a lightweight protocol is easier
to reach rough consensus than a heavy one. It also allows
differentiation between competing technology providers while retain
certain level of interoperability (which is the purpose of the working
group).

> [Hui Zhang] yes, I agree. there is P2P VoD, although they still heavily rely
> on content servers from the service providers themselves for data delivery.
> But from PPSP peer's view, it is still about get a chunk from somewhere
> (either peer or content server), the same as in channel broadcasting. The
> difference from channel broadcasting lies in how the data chunks are
> distributed from content servers to peers in data caching.

It is possible to design a P2P VOD system that is independent of
content service provider. For instance, PPLive has a technology
product known as PP Video Accelerate which does P2P VOD for any video
website including Youtube, Tudou, Youku.

See http://newteevee.com/2008/09/14/p2p-is-coming-to-youtube/

The design is quite different from the P2P Live streaming or P2P VOD
system we have however, and so is the architecture of the design. We
would be happy to present our architect at a future meeting.

> [Hui Zhang] actually current service providers like PPlive already had this
> CDN+PPSP architecture if you consider their backend content server cluster
> as a CDN point.

Yes, PPLive is a Hybrid CDN+P2P solution. However, we have CDN
accelerator within the swarm for a very different purpose, for video
QOS.

> typically either TCP or UDP. My concern here is can we (or if it is needed
> to) work out a new transmission protocol for video streaming. Sure RTP seems
> not to be a fit for trunk transferring in P2P streaming.

For P2P Streaming (Live or VOD), we have to optimize the bandwidth
throughput of the users. When average users is on 1mbps downlink and
video bitrate is at 700-800kbps, the overhead on the transport must be
kept to a minimum.

In our system, at any point in time, a node in the swarm monitors
200-300 peers constantly, while transmission occurs between 15-20
peers, vary from time to time. It is not a constant 20-30 peers, but
pick based on the peer selection algorithm we have.

Therefore, a TCP and RTP may not be suitable for our purpose.

> Answer: Exactly right. In fact we arrange such a survey presented in the bar
> bof.

We have over 10 published research papers on our system (another 4-5
we working on with Yale and Tsinghua to be publish next year) that we
would be happy to share.

-James Seng