Subject: [ppsp] Charter Proposal

From: Cullen Jennings <[email-masked]>
Date: Sat, 13 Mar 2010 07:33:31 -0700

The PPSP could easily be one of these groups were we spend the first few
years trying to chooses which protocol to start with in various
places. That would just remove the will to do anything in the group. I
have been lurking and watching this work from the beginning and it seems
like there are probably many things that most the participants agree to
that we could just nail down in the charter.  Doing so would help get
the work done faster and provide others a clear idea that had not been
been participating a much clearer idea of what this work is about.

For example:

Centralized or distributed trackers. My belief is that most the folks
want to do a centralized tracker. On a side note, I think they would be
hard to do a distributed one before a centralized as centralized is much
easier. The obvious protocol to use for a centralized one is to add the
needed extensions to the HTTP based version of bittorrent tracker
protocol. If they want to do a distributed one, RELOAD would meet the
needs and at least be worth looking at.

Similarly for the media transfer, I suspect that many people would be
happy with RTP. It's hard to imagine anything else given the end goal
for this. I guess one could argue for a new protocol or a protocol that
transferred data tunneled in the peer signaling protocol.

The peer signing protocol needs to be able to set up the RTP sessions
and work thought NATs. I think the NAT traversal scheme will end up
being ICE or something that more or less amounts to ICE with no TURN
option given the deployment models. Both RTSP and SIP are candidates
here. In some ways at first glance, RTSP might seem simpler. But a bunch
of that simplicity comes from the model of it being deployed on server
all clients can easily reach without nat nightmares and less
negotiation. Much of SIP complexity comes form too many intermediaries
and forking which would not apply in this case.  We will have to add a
bunch to RTSP to get it to work or subtract some SIP to get it to
work. Not an easy call and not a call that the WG is in a great position
to sort out. I'd love to hear others thought on it.

The alternative to the RTSP/SIP approach is to replace the signaling and
SDP with a capabilities something more like the Advertisement / Proposal
architecture the Jon and I have been discussion (See
draft-peterson-sipcore-advprop ).

There are a few other topics which are not addressed in this charter
that worry me a lot. The currently protocols being proposed and related
discussion does not seem to address what is the incentive for anyone to
serve content. It's clear why you would receive but not clear why you
would bother to transmit. Bittorrent put a lot of effort into this and
IMHO got it "right enough" that the system is very successful. I worry
about it in this work. A second topic is that the desired privacy
properties of the system are also pretty vague. If we are not clear
about these in the beginning, we run the risk of getting very bogged
down in arguing about them as the protocol starts to get close to done.

To try and help get things moving along, I have proposed charter bellow
that is very conservative .  As an individual, I would probably have a
slight preference for a more risky approach than the proposal below but
.

------------------------------------------------

The Peer-to-Peer Streaming Protocol (PPSP) working group develops two
signaling and control protocols for a peer-to-peer (P2P) streaming
system for transmitting live and time shifted media content with near
real-time delivery requirements.

Two kinds of nodes exist in the targeted P2P streaming system, i.e.,
"peers" and "trackers". Peers are nodes that are actively sending and
receiving streamed media content, and include both statically connected
hosts as well as mobile devices with connectivity and IP addresses that
change over time. The set of peers that are participating in a streaming
session will dynamically change over time. Trackers are well-known nodes
with stable connectivity that maintain meta information about the
streamed content and the dynamic peer set. The working group is only
addressing centralized trackers and not the distributed tracker.

The PPSP WG designs a protocol for signaling and control between
trackers and peers (the PPSP "tracker protocol") and a signaling and
control protocol for communication among the peers (the PPSP "peer
protocol"). The two protocols enable peers to receive streaming data
within the time constraints required by specific content items.  The
tracker protocol handles the initial and periodic exchange of meta
information between trackers and peers, such as peer lists and content
information. The peer protocol controls the advertising and exchange of
media data availability between the peers.

The tracker protocol will be modeled as much as possible to match the
exiting bittorrent protocol with appropriate extensions for to cary
information that is needed for selection of a peer suitable for real
time streaming. Media descriptions will use the syntax and semantics
from SDP where that is possible.

The peer protocol will be be an extension of SIP and use ICE for NAT
traversal.

RTP will be used for the encoding and transmission of the media content
between peers. PPSP is not chartered to work on media transmission
protocols, media encoding techniques or other components of a P2P
streaming system such as playout scheduling and control, etc.

The work items of the PPSP WG are:

(1) A "problem statement" document that gives an overview of the
    proposed P2P streaming system, motivates the desire for standardized
    protocols, defines the envisioned scope of those standardized
    components and discusses common terminologies and concepts.

(2) A "requirements" document that details the specific functional,
    operational and performance requirements of the two PPSP protocols.

(3) An "architectural survey" document that summarizes current P2P
    streaming architectures, in particular tracker-based P2P streaming
    systems, and highlights best current practices.

(4) A detailed specification of the PPSP peer protocol.

(5) A detailed specification of the PPSP tracker protocol.

(6) A "usage guide" that describes how the two PPSP protocols and
    existing IETF protocols, such ALTO, can be combined to create a
    deployable operational P2P streaming system.  This document will
    also discuss use of layered media encoding and related media chunk
    descriptions in the peer protocol for more robust streaming.

The work items of the PPSP WG interacts with the work performed in other
IETF WGs, including SIPCORE, AVT, ALTO, LEDBAT and MMUSIC. Whenever
extensions or modification to the protocols developed in other WGs are
deemed necessary, PPSP shall communicate and discuss the requirements
for such extensions with the relevant WGs but is not charted to make
such changes.

Goals and Milestones:

Sep 2010   Submit problem statement to IESG as Informational
Dec 2010   Submit architectural survey to IESG as Informational
Dec 2010   Submit requirements document to IESG as Informational
Aug 2011   Submit PPSP peer protocol to IESG as Proposed Standard 
Aug 2011   Submit PPSP tracker protocol to IESG as Proposed Standard
Dec 2011   Submit usage guide to IESG to IESG as Informational

----------------------------------------------------------------

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "David A. Bryan" <[email-masked]>
Date: Sat, 13 Mar 2010 10:22:42 -0500

So in general I think there are a lot of good comments here, and
thanks for sending things to the list. A few things I had comments on
inline...

> needs and at least be worth looking at.

I'm a bit confused about why you want to exclude distributed trackers.
Most of the information that would be exchanged -- i.e. the maps of
chunks etc -- are going to be the same between the two. I am still
trying to get my head around where the "edge" is here, but from
hacking at ideas a bit, it seems to me that the tracker protocol might
have two parts: query/place information from the peers to the tracker,
and information between trackers. If the separation is clean, it might
be possible to only focus on the part between peers/trackers and not
consider distributed trackers, but otherwise I think in protocol
design we should at least consider it...seems like a bad idea to
design a P2P protocol that neglects P2P at a different level (i.e.,
between trackers)

> transferred data tunneled in the peer signaling protocol.

Absolutely agree. Devising new mechanisms for media transport seems
way out of scope to me.

> draft-peterson-sipcore-advprop ).

Not quite as clear to me here, but I mostly agree. Definitely need to
negotiate streams, and need to traverse NATs. SIP seems like using a
fighter plane to kill a fly here, but may very well turn out that many
of the capabilities end up being needed once we get into it. The
problem is if the peers are speaking SIP, aren't they expected to have
the full SIP capabilities. We seem to need a SIP-Lite...(and yes, I
know that has been discussed oh, once or twice before, but here it
would be for devices with distinctly different applications)

My first take on the proposed charter below is that I like seeing
things get more concrete, but it has two problems from my perspective:

I agree bit-torrent is a very good model and we should be looking at
it, but the survey work is also bringing in work from some other very
widely deployed solutions (PPLive, for example), and I'm personally a
bit reluctant to just say bit-torrent wins.

I'm aware that PPLive and Bit-Torrent address slightly different
problems, which is actually my biggest concern with the charter --
still not clear that the live and time-shifted content really call for
the same protocol or share as much as might be thought in common.
Particularly for the real-time streaming, I'm not at all sure
Bit-Torrent is the right choice. (although I can see using a tracker
to find candidate peers and establishing live sessions between
them...so it's possible)  I'd rather wait just a little bit for the
survey document to evolve to make that call, and get more visibility
into if one protocol can be used for both streaming and time-shifted
content. That's part of the motivation for hacking together some
strawman work on the tracker as well -- let's see what hard problems
we stumble in that process. I agree if we don't firm it up we'll spin
for a long time, but I also don't want to jump to a wrong conclusion.

My biggest objection is with the proposal below is saying SIP is the
right choice for the Peer Protocol. That seems not-quite-right (even
if SIP is used to establish the connections). The peer protocol here.
again, is doing several things -- possibly maintaining an overlay
(possible RELOAD usage, although we have to make sure a full DHT is
needed, which with a central tracker it may not be) and in the live
stream case, establishing connections. Unless we resurrect dSIP (which
I'd love ;) ), SIP can't do the former, and I still think it is way
overkill for the later unless we come up with a lighter version. I'll
take a look at the advprop draft you mention -- that might be exactly
what I am thinking of but I have to admit I haven't read it. I guess
my worry here is that your version of the draft seems to be taking the
"I have a SIP hammer so this is a SIP nail" approach, and I'm not
quite convinced that's right (at least not yet, but I must admit the
problem looks very nail shaped. Maybe just a really small nail).

Reuse of SDP and RTP seem like no-brainers and I definitely agree.

Anyway, interesting thoughts,and my 2 cents...

David

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

---

From: Ning Zong <[email-masked]>
Date: Mon, 15 Mar 2010 10:39:37 +0800

Hi, Cullen
Thank you for your proposals on PPSP. My general comment is that although it
is the motivation of PPSP to narrow down the problem space, i.e. what we are
going to solve, it is too early to narrow down the solution space, i.e. what
protocols we are going to reuse or use as model.
More thoughts, please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Saturday, March 13, 2010 10:34 PM
To: [email-masked]
Subject: [ppsp] Charter Proposal

[ZONG]: Yes, we have been trying to narrow down the scope of PPSP since 74th
meeting.

For example:

[ZONG]: If my memory is correct, there was no specific discussion on
choosing centralized or distributed tracker in PPSP. When we say "tracker",
we mostly refer to the function (please see PPSP problem statement draft
where we focus on the information exchanged between peer and tracker). The
choice of centralized or distributed tracker is still an open question. But
I suspect that such topic is currently not in the scope of PPSP.

[ZONG] I agree with you, RTP seems to me the proper data protocol for
streaming, so far. I could not see reason why new data protocol is needed.

[ZONG] NAT traversal, signaling protocols for media session are all
necessary concerns in developing peer protocol. Thank you for putting
RTSP/SIP discussion together. But if we need to include these topics in the
current charter is still an open question and depends on group consensus.
Personally, I agree with you to include these topics into the charter.

[ZONG] IMO, the incentive issue (like other chunk scheduling algorithms for
better performed streaming system) is implemented in application layer of
P2P streaming system. As specified in PPSP problem statement, we are not
building a whole streaming system, but standardize components in
communication layer. Of course, if incentive solution brings any
requirements to peer and/or tracker protocol, we can adopt them in
developing peer/tracker protocols.

[ZONG]: I noticed that you change the "pre-recorded media content" to "time
shifted media content". Can you explain more on this change? Thank you.

[ZONG]: As mentioned early, we have not reaching the consensus on choosing
centralized or distributed tracker, yet.

[ZONG] For the above 3 paragraphs, I don't think it is good idea to specify
the solutions in the charter for NOW. Charter is the text for describing the
problem space, right?

Goals and Milestones:

Cullen Jennings

---

From: Lars Eggert <[email-masked]>
Date: Mon, 15 Mar 2010 07:47:21 -0700

Hi,

> been participating a much clearer idea of what this work is about.
...
> slight preference for a more risky approach than the proposal below but

since I got some offline questions, I want to quickly chime in. The intent of the proposed charter change that Cullen has sent is to discuss with the folks interested in PPSP if the charter can be more concrete on how we'd expect the main outcome of a PPSP WG to look like.

If we can come to an agreement on how to more tightly describe what the outcome would look like, that would be good. Either in the way that Cullen has proposed, but maybe also in a different way if the consensus of the group is that e.g. a BitTorrent-like tracker protocol is not the way to go, but another way is.

The idea is to be more concrete in the charter on what the group believes the best technical direction is, and not to mandate from the IESG that the group follow one technical approach.

I'd personally like to hear from folks on this proposal over the next few days. The intent is that we have clarity by next weekend, so that I can ask the IESG to charter the WG during our Sunday meeting (either with a revised charter that will come out of this discussion, or with the original charter), in order for you to have a first WG meeting next week.

Thanks,
Lars

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 15 Mar 2010 10:04:13 -0600

+1 on what Lars is saying here. 

My goal is to help get a concrete charter that is clear what problems the WG needs to go solve. I can imagine many ways to do this and I'm not arguing for any particular approach, just that we need to be clear on what it is we plan to build. Right now I'm not sure  things are clear. For example, the IESG was under the impression that there was rough consensus about doing a centralized tracker but watching the email here over last couple days, I'm beginning to wonder if the the IESG is confused about this.

Cullen

Cullen Jennings

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 15 Mar 2010 10:26:40 -0600

> design a P2P protocol that neglects P2P at a different level (i.e.,

I was just trying to put into the charter the direction I thought the group wanted to go or at least surface the issues so we could feedback of the form "yep, looks good" or "nope, we want distributed". Obviously I'm a bit of a fan of distributed approaches. 

> would be for devices with distinctly different applications)

Right - for example, I see no need for forking in one uses SIP which greatly the use of SIP. If the the plan it to simplify SIP in this way, we probably need to express that in the charter.  My view on using SIP is this work would only need a subset of it. However if we use RTSP, we need to add a bunch in RTSP. Typically cutting away stuff is faster than growing new stuff but that is not always true. Either could be made to work. So could something new. 

> for a long time, but I also don't want to jump to a wrong conclusion.

Fair enough - what you are saying there does seem very reasonable to me - but if we go down the plan then I think we should probably  spin up an Exploratory Group to go make some choices like that. 

> problem looks very nail shaped. Maybe just a really small nail).

Well I understand how something like RELAOD might get used for the peer to tracker protocol, but once you know a peer you are going to try and set up an RTP session with and, assuming the use of RTP,  it seems you need a protocol were host  A can tell host B to start sending the following data in an RTP steam.  Do I have this about right? 

Cullen Jennings

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 15 Mar 2010 10:38:40 -0600

> [ZONG]: Yes, we have been trying to narrow down the scope of PPSP since 74th

And in case I did not say it, I think this group has done a great job of bringing this all together. People seem to have a pretty crisp idea of what the problem is we are trying to solve and uses cases for it. When I first read this work long ago, I could not figure it out but really good work. 

> I suspect that such topic is currently not in the scope of PPSP.

Right  - I'm not worried about how the tracker is internal implements its data store, perhaps it is a hue DHT, or google big tables or something like that, but the important thing is does peer to tracker protocol designed such there is a "centralized" tracker it is contacting or does it participate in the distributed nature. Let me give two example, when I go to a large website like youtube.com, clearly there is a large set of distributed servers behind the scenes that all server up content and synchronize that so everyone gets the same thing. From my web browser point of view and from point of view of design of http protocol, the web server is a centralized server. Contrast this with say Skype where the signaling from my Skype client actually participates in the disrupting the information around. Now I can easily see how this Wg could build either or both of these models, but I think we need to be clear  about it. 

> Personally, I agree with you to include these topics into the charter.

I think this has lead to they type of information I was hoping to get out this email. It seems that most the people I have heard from so far think that most likely RTP is the right thing but that we don't have consensus around other things like RTSP vs SIP.  And that's fine, it just means we need to sort out some of theses and see if we can get to rough consensus. 

Cullen Jennings

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 15 Mar 2010 20:46:22 -0400

So just a few little followup points, mostly because I think I was a
bit unclear about my comment about distributed trackers, inline...

> I was just trying to put into the charter the direction I thought the group wanted to go or at least surface the issues so we could feedback of the form "yep, looks good" or "nope, we want distribu…

Given this, and the followup Ning had, I think things became more
crisp than my original comment, but just to be clear, I think what I
am getting at is that I see the tracker, as Ning mentioned, as a
logical function. It could be implemented in a centralized way (and
likely would be), or could actually use a DHT in the background. It
may be that we don't really need to consider that in the design of the
protocol to query the "tracker" (whatever that may be), and I
certainly don't want to muddy things by insisting it be distributed.
I'd personally suggest some wording akin to what we did in P2PSIP,
where we crafted a DHT for SIP but tried not to break it for other
possible applications. So here, maybe we say we are building for a
centralized tracker, but will try to consider the problem of a
distributed, and make sure the protocol for the logical process of
tracker calls doesn't do something that explicitly breaks distributed
functionality later.

I definitely don't want to give the IESG (or anyone else, really) the
impression that there is a big group of us looking to do a distributed
tracker up front. As far as I know, there isn't.

> Right - for example, I see no need for forking in one uses SIP which greatly the use of SIP. If the the plan it to simplify SIP in this way, we probably need to express that in the charter.  My vie…

Yep. Fully agree, particularly about hacking rather than
growing...(i.e., SIP easier than RTSP. At least in my opinion, I'd
agree.)

One wrinkle I see is that while these look good for real-time, it
isn't quite clear to me that SIP (or actually even RTP on the
transport side) is right in the time-shifted context. If I am
retrieving the file then playing locally ala Bit-Torrent, it seems
possible that you would use a bulk transfer block-by-block in that
scenario and assemble and play locally, rather than stream from the
peer that has it as would be the case in real-time. The more I've dug
into this in the last few months, the more the real-time and
time-shifted cases differ for the actions after you contact the
tracker.

> Fair enough - what you are saying there does seem very reasonable to me - but if we go down the plan then I think we should probably  spin up an Exploratory Group to go make some choices like that.

+1. I'd very much support that and would be willing to help if
volunteers are needed.

> Well I understand how something like RELAOD might get used for the peer to tracker protocol, but once you know a peer you are going to try and set up an RTP session with and, assuming the use of RT…

Yep, I think you do have it right, and like I said, given that
description, SIP (in the old original session establishment sense) may
really be right, I'm just not quite convinced yet. I'm sure you know
this since you have too, but as someone who has hacked a bunch of SIP
stuff together over the years, I know how much there is in SIP, and
how much of that we don't need in this context. Certainly don't mean
to imply it isn't a pretty strong candidate.

David

---

From: Ning Zong <[email-masked]>
Date: Tue, 16 Mar 2010 13:59:38 +0800

Hi, Cullen & David

Given the information and clarification provided by Lars and Cullen, I
understand the points raised by Cullen. My feeling is that PPSP may need
more priority on efficiency since it focuses on real-time streaming. So one
potential advantage of centralized tracker would be a quicker response to
the peer list request, rather than a hop-by-hop routing & response mode
defined in RELOAD. But the tracker is not necessarily a stand-alone server
(what I mean centralized in the previous email), it could be a group of
servers organized by some distributed way (for better robustness and load
balance, etc) and serve the peer list request as a whole logical tracker.
How to implement the latter case of group of servers is currently not in the
scope, but definitely needs to be considered later.
Another word, the peer-to-tracker message is sent to some single function to
return peer list as quick as possible, not routed hop-by-hop, for the sake
of real-time efficiency. I remember there are some comparison drafts
presented in PPSP to emphasize this motivation.
Of course, that's only my two cents, I'd like to hear more opinions from the
group.

BR,
Ning Zong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David A. Bryan
Sent: Tuesday, March 16, 2010 8:46 AM
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [ppsp] Charter Proposal

On Mon, Mar 15, 2010 at 12:26 PM, Cullen Jennings <[email-masked]> wrote:
> I was just trying to put into the charter the direction I thought the
group wanted to go or at least surface the issues so we could feedback of
the form "yep, looks good" or "nope, we want distributed". Obviously I'm a
bit of a fan of distributed approaches.

> Right - for example, I see no need for forking in one uses SIP which
greatly the use of SIP. If the the plan it to simplify SIP in this way, we
probably need to express that in the charter.  My view on using SIP is this
work would only need a subset of it. However if we use RTSP, we need to add
a bunch in RTSP. Typically cutting away stuff is faster than growing new
stuff but that is not always true. Either could be made to work. So could
something new.

> Fair enough - what you are saying there does seem very reasonable to me -
but if we go down the plan then I think we should probably  spin up an
Exploratory Group to go make some choices like that.

> Well I understand how something like RELAOD might get used for the peer to
tracker protocol, but once you know a peer you are going to try and set up
an RTP session with and, assuming the use of RTP,  it seems you need a
protocol were host  A can tell host B to start sending the following data in
an RTP steam.  Do I have this about right?

David

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 16 Mar 2010 15:39:02 +0800

Hi All,

Just trying to split the discussions in separated threads.

>From the reply of Ning, the problem here, I think, is the understanding of centralized and distributed tracker and if PPSP should consider it. Both Ning and David has mentioned that " tracker" was a logical  function, which could be one server or a group of servers organized by DHT. Cullen considered both of the models as "centralized tracker", if only one interface is given for tracker to communicate with peers.  That's why he said only "centralized trackers" (no matter a stand alone one or a group of them) were considered in PPSP.  Because from the perspective of peers, it's only a logical function offering tracker services. 

IMOH, PPSP does not need to care about how many trackers and where they are allocated if  the communication can be set up between peers and the "tracker function" by a single logical interface. The search of the trackers should be out of the scope of PPSP. Therefore, PPSP should not be bothered by the issues of finding and collecting tracker information from distributed trackers individually. It should be allowed that a group of trackers are organized by DHT to offer tracker services as if "one logical tracker". The signaling between the trackers should be looked as internal, which are not cared by PPSP. In this point, RELOAD  might be used to organize the trackers, which is invisible to PPSP from outside. So, why not delete the terms of "centralized" and "distributed", which cause confusion, and look the tracker just as a single logical function. 

Br
Lin Xiao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Ning Zong
Sent: Tuesday, March 16, 2010 2:00 PM
To: 'David A. Bryan'; 'Cullen Jennings'
Cc: [email-masked]
Subject: Re: [ppsp] Charter Proposal

Hi, Cullen & David

Given the information and clarification provided by Lars and Cullen, I understand the points raised by Cullen. My feeling is that PPSP may need more priority on efficiency since it focuses on real-time streaming. So one potential advantage of centralized tracker would be a quicker response to the peer list request, rather than a hop-by-hop routing & response mode defined in RELOAD. But the tracker is not necessarily a stand-alone server (what I mean centralized in the previous email), it could be a group of servers organized by some distributed way (for better robustness and load balance, etc) and serve the peer list request as a whole logical tracker.
How to implement the latter case of group of servers is currently not in the scope, but definitely needs to be considered later.
Another word, the peer-to-tracker message is sent to some single function to return peer list as quick as possible, not routed hop-by-hop, for the sake of real-time efficiency. I remember there are some comparison drafts presented in PPSP to emphasize this motivation.
Of course, that's only my two cents, I'd like to hear more opinions from the group.

BR,
Ning Zong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David A. Bryan
Sent: Tuesday, March 16, 2010 8:46 AM
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [ppsp] Charter Proposal

So just a few little followup points, mostly because I think I was a bit unclear about my comment about distributed trackers, inline...

On Mon, Mar 15, 2010 at 12:26 PM, Cullen Jennings <[email-masked]> wrote:
>> > The PPSP could easily be one of these groups were we spend the 
>> > first
few
>> > places. That would just remove the will to do anything in the 
>> > group. I have been lurking and watching this work from the 
>> > beginning and it
seems
>> > like there are probably many things that most the participants 
>> > agree to that we could just nail down in the charter.  Doing so 
>> > would help get the work done faster and provide others a clear idea 
>> > that had not been been participating a much clearer idea of what this work is about.
>> >
>> > For example:
>> >
>> > Centralized or distributed trackers. My belief is that most the 
>> > folks want to do a centralized tracker. On a side note, I think 
>> > they would be hard to do a distributed one before a centralized as 
>> > centralized is
much
>> > easier. The obvious protocol to use for a centralized one is to add 
>> > the needed extensions to the HTTP based version of bittorrent 
>> > tracker protocol. If they want to do a distributed one, RELOAD 
>> > would meet the needs and at least be worth looking at.
>>
>> hacking at ideas a bit, it seems to me that the tracker protocol 
>> might have two parts: query/place information from the peers to the 
>> tracker, and information between trackers. If the separation is 
>> clean, it might be possible to only focus on the part between 
>> peers/trackers and not consider distributed trackers, but otherwise I 
>> think in protocol design we should at least consider it...seems like 
>> a bad idea to design a P2P protocol that neglects P2P at a different 
>> level (i.e., between trackers)
>
group wanted to go or at least surface the issues so we could feedback of the form "yep, looks good" or "nope, we want distributed". Obviously I'm a bit of a fan of distributed approaches.

Given this, and the followup Ning had, I think things became more crisp than my original comment, but just to be clear, I think what I am getting at is that I see the tracker, as Ning mentioned, as a logical function. It could be implemented in a centralized way (and likely would be), or could actually use a DHT in the background. It may be that we don't really need to consider that in the design of the protocol to query the "tracker" (whatever that may be), and I certainly don't want to muddy things by insisting it be distributed.
I'd personally suggest some wording akin to what we did in P2PSIP, where we crafted a DHT for SIP but tried not to break it for other possible applications. So here, maybe we say we are building for a centralized tracker, but will try to consider the problem of a distributed, and make sure the protocol for the logical process of tracker calls doesn't do something that explicitly breaks distributed functionality later.

I definitely don't want to give the IESG (or anyone else, really) the impression that there is a big group of us looking to do a distributed tracker up front. As far as I know, there isn't.

>
>>
>> > Similarly for the media transfer, I suspect that many people would 
>> > be happy with RTP. It's hard to imagine anything else given the end 
>> > goal for this. I guess one could argue for a new protocol or a 
>> > protocol that transferred data tunneled in the peer signaling protocol.
>>
>> > The peer signing protocol needs to be able to set up the RTP 
>> > sessions and work thought NATs. I think the NAT traversal scheme 
>> > will end up being ICE or something that more or less amounts to ICE 
>> > with no TURN option given the deployment models. Both RTSP and SIP 
>> > are candidates here. In some ways at first glance, RTSP might seem 
>> > simpler. But a
bunch
>> > of that simplicity comes from the model of it being deployed on 
>> > server all clients can easily reach without nat nightmares and less 
>> > negotiation. Much of SIP complexity comes form too many 
>> > intermediaries and forking which would not apply in this case.  We 
>> > will have to add a bunch to RTSP to get it to work or subtract some 
>> > SIP to get it to work. Not an easy call and not a call that the WG 
>> > is in a great
position
>> > The alternative to the RTSP/SIP approach is to replace the 
>> > signaling
and
>> fighter plane to kill a fly here, but may very well turn out that 
>> many of the capabilities end up being needed once we get into it. The 
>> problem is if the peers are speaking SIP, aren't they expected to 
>> have the full SIP capabilities. We seem to need a SIP-Lite...(and 
>> yes, I know that has been discussed oh, once or twice before, but 
>> here it would be for devices with distinctly different applications)
>
greatly the use of SIP. If the the plan it to simplify SIP in this way, we probably need to express that in the charter.  My view on using SIP is this work would only need a subset of it. However if we use RTSP, we need to add a bunch in RTSP. Typically cutting away stuff is faster than growing new stuff but that is not always true. Either could be made to work. So could something new.

Yep. Fully agree, particularly about hacking rather than growing...(i.e., SIP easier than RTSP. At least in my opinion, I'd
agree.)

One wrinkle I see is that while these look good for real-time, it isn't quite clear to me that SIP (or actually even RTP on the transport side) is right in the time-shifted context. If I am retrieving the file then playing locally ala Bit-Torrent, it seems possible that you would use a bulk transfer block-by-block in that scenario and assemble and play locally, rather than stream from the peer that has it as would be the case in real-time. The more I've dug into this in the last few months, the more the real-time and time-shifted cases differ for the actions after you contact the tracker.

>> still not clear that the live and time-shifted content really call 
>> for the same protocol or share as much as might be thought in common.
but if we go down the plan then I think we should probably  spin up an Exploratory Group to go make some choices like that.

>> stream case, establishing connections. Unless we resurrect dSIP 
>> (which I'd love ;) ), SIP can't do the former, and I still think it 
>> is way overkill for the later unless we come up with a lighter 
>> version. I'll take a look at the advprop draft you mention -- that 
>> might be exactly what I am thinking of but I have to admit I haven't 
>> read it. I guess my worry here is that your version of the draft 
>> seems to be taking the "I have a SIP hammer so this is a SIP nail" 
>> approach, and I'm not quite convinced that's right (at least not yet, 
>> but I must admit the problem looks very nail shaped. Maybe just a really small nail).
>
tracker protocol, but once you know a peer you are going to try and set up an RTP session with and, assuming the use of RTP,  it seems you need a protocol were host  A can tell host B to start sending the following data in an RTP steam.  Do I have this about right?

Yep, I think you do have it right, and like I said, given that description, SIP (in the old original session establishment sense) may really be right, I'm just not quite convinced yet. I'm sure you know this since you have too, but as someone who has hacked a bunch of SIP stuff together over the years, I know how much there is in SIP, and how much of that we don't need in this context. Certainly don't mean to imply it isn't a pretty strong candidate.

David

>> > There are a few other topics which are not addressed in this 
>> > charter that worry me a lot. The currently protocols being proposed 
>> > and related discussion does not seem to address what is the 
>> > incentive for anyone to serve content. It's clear why you would 
>> > receive but not clear why you would bother to transmit. Bittorrent 
>> > put a lot of effort into this and IMHO got it "right enough" that 
>> > the system is very successful. I worry about it in this work. A 
>> > second topic is that the desired privacy properties of the system 
>> > are also pretty vague. If we are not clear about these in the 
>> > beginning, we run the risk of getting very bogged down in arguing about them as the protocol starts to get close to done.
>> >
>> > To try and help get things moving along, I have proposed charter 
>> > bellow that is very conservative .  As an individual, I would 
>> > probably have a slight preference for a more risky approach than 
>> > the proposal below but .
>> >
>> >
>> > The Peer-to-Peer Streaming Protocol (PPSP) working group develops 
>> > two signaling and control protocols for a peer-to-peer (P2P) 
>> > streaming system for transmitting live and time shifted media 
>> > content with near real-time delivery requirements.
>> >
>> > Two kinds of nodes exist in the targeted P2P streaming system, 
>> > i.e., "peers" and "trackers". Peers are nodes that are actively 
>> > sending and receiving streamed media content, and include both 
>> > statically connected hosts as well as mobile devices with 
>> > connectivity and IP addresses that change over time. The set of 
>> > peers that are participating in a
streaming
>> > streamed content and the dynamic peer set. The working group is 
>> > only addressing centralized trackers and not the distributed tracker.
>> >
>> > trackers and peers (the PPSP "tracker protocol") and a signaling 
>> > and control protocol for communication among the peers (the PPSP 
>> > "peer protocol"). The two protocols enable peers to receive 
>> > streaming data within the time constraints required by specific 
>> > content items.  The tracker protocol handles the initial and 
>> > periodic exchange of meta information between trackers and peers, 
>> > such as peer lists and content information. The peer protocol 
>> > controls the advertising and exchange of media data availability between the peers.
>> >
>> > The tracker protocol will be modeled as much as possible to match 
>> > the exiting bittorrent protocol with appropriate extensions for to 
>> > cary information that is needed for selection of a peer suitable 
>> > for real time streaming. Media descriptions will use the syntax and 
>> > semantics from SDP where that is possible.
>> >
>> > The peer protocol will be be an extension of SIP and use ICE for 
>> > NAT traversal.
>> >
>> > RTP will be used for the encoding and transmission of the media 
>> > content between peers. PPSP is not chartered to work on media 
>> > transmission protocols, media encoding techniques or other 
>> > components of a P2P streaming system such as playout scheduling and control, etc.
>> >
>> > extensions or modification to the protocols developed in other WGs 
>> > are deemed necessary, PPSP shall communicate and discuss the 
>> > requirements for such extensions with the relevant WGs but is not 
>> > charted to make such changes.
>> >
>> > Goals and Milestones:
>> >
>> > Sep 2010   Submit problem statement to IESG as Informational Dec 
>> > 2010   Submit architectural survey to IESG as Informational Dec 
>> > 2010   Submit requirements document to IESG as Informational Aug 
>> > 2011   Submit PPSP peer protocol to IESG as Proposed Standard Aug 
>> > 2011   Submit PPSP tracker protocol to IESG as Proposed Standard

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 16 Mar 2010 16:06:09 +0800

Hi,

I'd like to open a new thread for the discussion of allowed PPSP media type. 

It is true that there are lot of different requirements and behaviors of real-time streaming, VoD and file downloading. However, PPSP is only a set of signaling protocols but not media transmission protocol. From this point, there must be common structure and signaling process flow shared by these three use cases. A "usage type" was defined to identify the type of content transmitted in PPSP system (requirement draft -03).  Parameters can be adjusted according to different "usage types" for different kind of transmission. 

As far as I know, most of the P2P streaming software, e.g. PPlive and PPStream, support both live streaming and VoD services. Recently, PPStream even allow downloading the whole film file to users' local disks, just like Bit-Torrent does. It means common signaling and control method can be designed for all the "usage types".

Br
Lin Xiao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext David A. Bryan
Sent: Tuesday, March 16, 2010 8:46 AM
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [ppsp] Charter Proposal

On Mon, Mar 15, 2010 at 12:26 PM, Cullen Jennings <[email-masked]> wrote:
>> > first few years trying to chooses which protocol to start with in 
>> > various places. That would just remove the will to do anything in 
>> > the group. I have been lurking and watching this work from the 
>> > beginning and it seems like there are probably many things that 
>> > most the participants agree to that we could just nail down in the 
>> > charter.  Doing so would help get the work done faster and provide 
>> > others a clear idea that had not been been participating a much clearer idea of what this work is about.
>> >
>> > For example:
>> >
>> > centralized is much easier. The obvious protocol to use for a 
>> > centralized one is to add the needed extensions to the HTTP based 
>> > version of bittorrent tracker protocol. If they want to do a 
>> > distributed one, RELOAD would meet the needs and at least be worth looking at.
>>

>> > simpler. But a bunch of that simplicity comes from the model of it 
>> > being deployed on server all clients can easily reach without nat 
>> > nightmares and less negotiation. Much of SIP complexity comes form 
>> > too many intermediaries and forking which would not apply in this 
>> > case.  We will have to add a bunch to RTSP to get it to work or 
>> > subtract some SIP to get it to work. Not an easy call and not a 
>> > call that the WG is in a great position to sort out. I'd love to hear others thought on it.
>> >
>> > signaling and SDP with a capabilities something more like the 
>> > Advertisement / Proposal architecture the Jon and I have been 
>> > discussion (See draft-peterson-sipcore-advprop ).
>>

David

>> > peers that are participating in a streaming session will 
>> > dynamically change over time. Trackers are well-known nodes with 
>> > stable connectivity that maintain meta information about the 
>> > streamed content and the dynamic peer set. The working group is only addressing centralized trackers and not the distributed tracker.
>> >
>> > The work items of the PPSP WG interacts with the work performed in 
>> > other IETF WGs, including SIPCORE, AVT, ALTO, LEDBAT and MMUSIC. 
>> > Whenever extensions or modification to the protocols developed in 
>> > other WGs are deemed necessary, PPSP shall communicate and discuss 
>> > the requirements for such extensions with the relevant WGs but is 
>> > not charted to make such changes.
>> >
>> > Goals and Milestones:
>> >

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 16 Mar 2010 10:25:32 -0400

My understanding of the work of the PPSP group is yes, it would be
limited to the tracker and peer protocols. However, what Cullen was
proposing went further (since he was talking about the actual
negotiating of establishing a session), so my comments were about
that. My most recent understanding after the Hiroshima meeting (and I
may be confused) was that PPSP was more focused on just the tracker
and peer protocol part of the puzzle for now.

David

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 16 Mar 2010 20:57:11 +0100

Hi Cullen, all,

A few comments to the changed charter proposal: 

I'm also in general support of narrowing the charter proposal to something that will work out near term. However, the charter proposal is probably a step too much into the direction of narrowing it down. 

It seems that you have added the requirement to focus on the bittorrent protocol as basis for the tracker communication and to use RTP for the media transport.

My point is that most p2p video streaming seems to  use chunks to exchange data between the peers, where a chunk can have the size of multiple RTP packets (if used at all), i.e., aggregating even multiple movie frames into a single chunk.

I would propose to fine tune the " RTP will be used for the encoding and transmission" to something along the lines that "the functionality of RTP should be re-used to the largest extent."

For re-using the bittorrent tracker protocol: The current text suggest that we copy the protocol semantics but do not use the protocol? Is that intentionally, I did I misunderstand this?
If we are going to re-use the protocol, are we running into trouble because the protocol itself is not under IETF's change control?

  Martin

> Sent: Saturday, March 13, 2010 3:34 PM
> To: [email-masked]
> other

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 18 Mar 2010 11:43:44 +0800

Just some followup points to David's idea.To make all read easier, also copy the reply part here.
----------------------------

[Yunfei]I agree with you on the understanding of the tracker protocol.This is just
 a functional protocol independent of its implementation on centralized way or distribution.
Yep.  Fully  agree,  particularly  about  hacking  rather  than
growing...(i.e.,  SIP  easier  than  RTSP.  At  least  in  my  opinion,  I'd
agree.)

[Yunfei]You are right.What's more,even in the real-time p2p streaming context, some
implemenations like PPLive use just a block-by-block transfer like simple UDP*WITHOUT*
explicit timing signaling, but the scheduling algorithms(which is out of scope of PPSP)ensure
the real-time requirements according to our measurments. Of course I agree that RTP can be 
good candidate in actual data transfer.
One point I want to say is that peer protocol is initially intended to do the following task:
chunk availability exchange between peers.Suppose peer A and peer B, A asked B,hey, which specific
chunk do you have(pre-condition:A and B have the same chunk slicing regulation(common structure).
The task of how to set up the connections between peer A and peer B is out of our current scope.I remember
that Ning had raised the question that there is a gap between peer protocol and the real data transfer in the 
mailing list and we got consensus in this point.

Yunfei

zhangyunfei
2010-03-18

发件人： David A. Bryan
发送时间： 2010-03-16 09:02:37
收件人： Cullen Jennings
抄送： [email-masked]
主题： Re: [ppsp] Charter Proposal

On  Mon,  Mar  15,  2010  at  12:26  PM,  Cullen  Jennings   <[email-masked] >  wrote:
> >  On  Sat,  Mar  13,  2010  at  9:33  AM,  Cullen  Jennings   <[email-masked] >  wrote:
> >   >
> >   >
> >   >  that  we  could  just  nail  down  in  the  charter.  燚oing  so  would  help  get

[Yunfei]I agree with you on the understanding of the tracker protocol.This is just
 a functional protocol independent of its implementation on centralized way or distribution.

> >   >  and  forking  which  would  not  apply  in  this  case.  燱e  will  have  to  add  a
>  Right  -  for  example,  I  see  no  need  for  forking  in  one  uses  SIP  which  greatly  the  use  of  SIP.  If  the  the  plan  it  to  simplify  SIP  in  this  way,  we  probably  need  to  express  that  in  the  charter.  燤y  view  on  using  SIP  is  this  work  would  only  need  a  subset  of  it.  However  if  we  use  RTSP,  we  need  to  add  a  bunch  in  RTSP.  Typically  cutting  away  stuff  is  faster  than  growing  new  stuff  but  that  is  not  always  true.  Either  could  be  made  to  work.  So  could  something  new.

[Yunfei]You are right.What's more,even in the real-time p2p streaming context, some
implemenations like PPLive use just a block-by-block transfer like simple UDP*WITHOUT*
explicit timing signaling, but the scheduling algorithms(which is out of scope of PPSP)ensure
the real-time requirements according to our measurments. Of course I agree that RTP can be 
good candidate in actual data transfer.
One point I want to say is that peer protocol is initially intended to do the following task:
chunk availability exchange between peers.Suppose peer A and peer B, A asked B,hey, which specific
chunk do you have(pre-condition:A and B have the same chunk slicing regulation(common structure).
The task of how to set up the connections between peer A and peer B is out of our current scope.I remember
that Ning had raised the question that there is a gap between peer protocol and the real data transfer in the 
mailing list and we got consensus in this point.

> >  them...so  it's  possible)  營'd  rather  wait  just  a  little  bit  for  the
>  Fair  enough  -  what  you  are  saying  there  does  seem  very  reasonable  to  me  -  but  if  we  go  down  the  plan  then  I  think  we  should  probably  爏pin  up  an  Exploratory  Group  to  go  make  some  choices  like  that.

>  Well  I  understand  how  something  like  RELAOD  might  get  used  for  the  peer  to  tracker  protocol,  but  once  you  know  a  peer  you  are  going  to  try  and  set  up  an  RTP  session  with  and,  assuming  the  use  of  RTP,  爄t  seems  you  need  a  protocol  were  host  燗  can  tell  host  B  to  start  sending  the  following  data  in  an  RTP  steam.  燚o  I  have  this  about  right?

David

> >   >  that  is  very  conservative  .  燗s  an  individual,  I  would  probably  have  a
> >   >  within  the  time  constraints  required  by  specific  content  items.  燭he
> >   >  ?爌roposed  P2P  streaming  system,  motivates  the  desire  for  standardized
> >   >  ?爌rotocols,  defines  the  envisioned  scope  of  those  standardized
> >   >  ?燾omponents  and  discusses  common  terminologies  and  concepts.
> >   >
> >   >  ?爋perational  and  performance  requirements  of  the  two  PPSP  protocols.
> >   >
> >   >  ?爏treaming  architectures,  in  particular  tracker-based  P2P  streaming
> >   >  ?爏ystems,  and  highlights  best  current  practices.
> >   >
> >   >  ?爀xisting  IETF  protocols,  such  ALTO,  can  be  combined  to  create  a
> >   >  ?燿eployable  operational  P2P  streaming  system.  燭his  document  will
> >   >  ?燼lso  discuss  use  of  layered  media  encoding  and  related  media  chunk
> >   >  ?燿escriptions  in  the  peer  protocol  for  more  robust  streaming.
> >   >
> >   >  Sep  2010  ?Submit  problem  statement  to  IESG  as  Informational
> >   >  Dec  2010  ?Submit  architectural  survey  to  IESG  as  Informational
> >   >  Dec  2010  ?Submit  requirements  document  to  IESG  as  Informational
> >   >  Aug  2011  ?Submit  PPSP  peer  protocol  to  IESG  as  Proposed  Standard
> >   >  Aug  2011  ?Submit  PPSP  tracker  protocol  to  IESG  as  Proposed  Standard
> >   >  Dec  2011  ?Submit  usage  guide  to  IESG  to  IESG  as  Informational
> >   >
> >   >

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 18 Mar 2010 11:44:25 +0800

+1 for the understanding.

Yunfei

zhangyunfei
2010-03-18

发件人： Ning Zong
发送时间： 2010-03-16 14:15:59
收件人： 'David A. Bryan'; 'Cullen Jennings'
抄送： [email-masked]
主题： Re: [ppsp] Charter Proposal

Hi,  Cullen  &  David

BR,
Ning  Zong

-----Original  Message-----

David

other

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 18 Mar 2010 11:46:22 +0800

This is also what I want to clarify.+1.
Peer protocol is only for chunk availability exchange from our current discussion both in the meeting and in the mailing list.

Yunfei

zhangyunfei
2010-03-18

发件人： David A. Bryan
发送时间： 2010-03-16 23:07:12
收件人： Xiao, Lin (NSN - CN/Beijing)
抄送： [email-masked]
主题： Re: [ppsp] Charter Proposal - real-time and time-shifted

David

On  Tue,  Mar  16,  2010  at  4:06  AM,  Xiao,  Lin  (NSN  -  CN/Beijing)
<[email-masked] >  wrote:
>  It  is  true  that  there  are  lot  of  different  requirements  and  behaviors  of  real-time  streaming,  VoD  and  file  downloading.  However,  PPSP  is  only  a  set  of  signaling  protocols  but  not  media  transmission  protocol.  From  this  point,  there  must  be  common  structure  and  signaling  process  flow  shared  by  these  three  use  cases.  A  "usage  type"  was  defined  to  identify  the  type  of  content  transmitted  in  PPSP  system  (requirement  draft  -03).  燩arameters  can  be  adjusted  according  to  different  "usage  types"  for  different  kind  of  transmission.
>
> > >   >  charter.  燚oing  so  would  help  get  the  work  done  faster  and  provide
> > >   >  case.  燱e  will  have  to  add  a  bunch  to  RTSP  to  get  it  to  work  or
> > >   >  bellow  that  is  very  conservative  .  燗s  an  individual,  I  would
> > >   >  content  items.  燭he  tracker  protocol  handles  the  initial  and
> > >   >  Sep  2010  ?Submit  problem  statement  to  IESG  as  Informational  Dec
> > >   >  2010  ?Submit  architectural  survey  to  IESG  as  Informational  Dec
> > >   >  2010  ?Submit  requirements  document  to  IESG  as  Informational  Aug
> > >   >  2011  ?Submit  PPSP  peer  protocol  to  IESG  as  Proposed  Standard  Aug
> > >   >  2011  ?Submit  PPSP  tracker  protocol  to  IESG  as  Proposed  Standard

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 18 Mar 2010 12:01:30 +0800

Exploratory Group is a cool idea.I am also keen of contributing on this.

BR
Yunfei

zhangyunfei
2010-03-18

发件人： David A. Bryan

David

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 18 Mar 2010 12:16:18 +0800

Please see inline reply.

BR
Yunfei

zhangyunfei
2010-03-18

发件人： Ning Zong
发送时间： 2010-03-15 10:55:58
收件人： 'Cullen Jennings'; [email-masked]
抄送： 
主题： Re: [ppsp] Charter Proposal

Hi,  Cullen

-----Original  Message-----

For  example:

[Yunfei]Agree.Schems like"tit-for-tat" in Bittorrent to assure the user incentive to share are
actions for neighbor selection and scheduling after the peer executes the tracker protocol 
(for neigbor candidates)and peer protocol(for chunk candidates).And many p2p streaming systems
use simple random selection for replacement.

Goals  and  Milestones:

Cullen  Jennings

---

From: Ning Zong <[email-masked]>
Date: Thu, 18 Mar 2010 12:16:39 +0800

For the current scope of peer protocol, +1

For launching an Exploratory Group (provided not to delay current PPSP) to
look further the choice for SIP/RTSP/RTP/etc, +1

Ning

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
zhangyunfei
Sent: Thursday, March 18, 2010 11:46 AM
To: David A. Bryan; Xiao, Lin (NSN - CN/Beijing)
Cc: [email-masked]
Subject: Re: [ppsp] Charter Proposal - real-time and time-shifted

Peer protocol is only for chunk availability exchange from our current
discussion both in the meeting and in the mailing list.

Yunfei

  _____  

zhangyunfei

2010-03-18

  _____  

发件人： David A. Bryan

抄送： [email-masked]

My  understanding  of  the  work  of  the  PPSP  group  is  yes,  it  would
be

limited  to  the  tracker  and  peer  protocols.  However,  what  Cullen
was

that.  My  most  recent  understanding  after  the  Hiroshima  meeting  (and
I

may  be  confused)  was  that  PPSP  was  more  focused  on  just  the
tracker

David

<[email-masked] >  wrote:

>  It  is  true  that  there  are  lot  of  different  requirements  and
behaviors  of  real-time  streaming,  VoD  and  file  downloading.  However,
PPSP  is  only  a  set  of  signaling  protocols  but  not  media
transmission  protocol.  From  this  point,  there  must  be  common
structure  and  signaling  process  flow  shared  by  these  three  use
cases.  A  "usage  type"  was  defined  to  identify  the  type  of  content
transmitted  in  PPSP  system  (requirement  draft  -03).  燩arameters  can
be  adjusted  according  to  different  "usage  types"  for  different  kind
of  transmission.

>  As  far  as  I  know,  most  of  the  P2P  streaming  software,  e.g.
PPlive  and  PPStream,  support  both  live  streaming  and  VoD  services.
Recently,  PPStream  even  allow  downloading  the  whole  film  file  to
users'  local  disks,  just  like  Bit-Torrent  does.  It  means  common
signaling  and  control  method  can  be  designed  for  all  the  "usage
types".

>  So  just  a  few  little  followup  points,  mostly  because  I  think  I
was  a  bit  unclear  about  my  comment  about  distributed  trackers,
inline...

> > >   >  others  a  clear  idea  that  had  not  been  been  participating
a  much  clearer  idea  of  what  this  work  is  about.

> >  I  was  just  trying  to  put  into  the  charter  the  direction  I
thought  the  group  wanted  to  go  or  at  least  surface  the  issues  so
we  could  feedback  of  the  form  "yep,  looks  good"  or  "nope,  we
want  distributed".  Obviously  I'm  a  bit  of  a  fan  of  distributed
approaches.

>  Given  this,  and  the  followup  Ning  had,  I  think  things  became
more  crisp  than  my  original  comment,  but  just  to  be  clear,  I
think  what  I  am  getting  at  is  that  I  see  the  tracker,  as  Ning
mentioned,  as  a  logical  function.  It  could  be  implemented  in  a
centralized  way  (and  likely  would  be),  or  could  actually  use  a
DHT  in  the  background.  It  may  be  that  we  don't  really  need  to
consider  that  in  the  design  of  the  protocol  to  query  the
"tracker"  (whatever  that  may  be),  and  I  certainly  don't  want  to
muddy  things  by  insisting  it  be  distributed.

>  I'd  personally  suggest  some  wording  akin  to  what  we  did  in
P2PSIP,  where  we  crafted  a  DHT  for  SIP  but  tried  not  to  break
it  for  other  possible  applications.  So  here,  maybe  we  say  we  are
building  for  a  centralized  tracker,  but  will  try  to  consider  the
problem  of  a  distributed,  and  make  sure  the  protocol  for  the
logical  process  of  tracker  calls  doesn't  do  something  that
explicitly  breaks  distributed  functionality  later.

>  I  definitely  don't  want  to  give  the  IESG  (or  anyone  else,
really)  the  impression  that  there  is  a  big  group  of  us  looking
to  do  a  distributed  tracker  up  front.  As  far  as  I  know,  there
isn't.

> >  Right  -  for  example,  I  see  no  need  for  forking  in  one  uses
SIP  which  greatly  the  use  of  SIP.  If  the  the  plan  it  to
simplify  SIP  in  this  way,  we  probably  need  to  express  that  in
the  charter.  燤y  view  on  using  SIP  is  this  work  would  only  need
a  subset  of  it.  However  if  we  use  RTSP,  we  need  to  add  a  bunch
in  RTSP.  Typically  cutting  away  stuff  is  faster  than  growing  new
stuff  but  that  is  not  always  true.  Either  could  be  made  to  work.
So  could  something  new.

>  One  wrinkle  I  see  is  that  while  these  look  good  for  real-time,
it  isn't  quite  clear  to  me  that  SIP  (or  actually  even  RTP  on
the  transport  side)  is  right  in  the  time-shifted  context.  If  I  am
retrieving  the  file  then  playing  locally  ala  Bit-Torrent,  it  seems
possible  that  you  would  use  a  bulk  transfer  block-by-block  in  that
scenario  and  assemble  and  play  locally,  rather  than  stream  from
the  peer  that  has  it  as  would  be  the  case  in  real-time.  The
more  I've  dug  into  this  in  the  last  few  months,  the  more  the
real-time  and  time-shifted  cases  differ  for  the  actions  after  you
contact  the  tracker.

> >  Fair  enough  -  what  you  are  saying  there  does  seem  very
reasonable  to  me  -  but  if  we  go  down  the  plan  then  I  think  we
should  probably  爏pin  up  an  Exploratory  Group  to  go  make  some
choices  like  that.

> >  Well  I  understand  how  something  like  RELAOD  might  get  used
for  the  peer  to  tracker  protocol,  but  once  you  know  a  peer  you
are  going  to  try  and  set  up  an  RTP  session  with  and,  assuming
the  use  of  RTP,  爄t  seems  you  need  a  protocol  were  host  燗  can
tell  host  B  to  start  sending  the  following  data  in  an  RTP  steam.
燚o  I  have  this  about  right?

>  Yep,  I  think  you  do  have  it  right,  and  like  I  said,  given
that  description,  SIP  (in  the  old  original  session  establishment
sense)  may  really  be  right,  I'm  just  not  quite  convinced  yet.  I'm
sure  you  know  this  since  you  have  too,  but  as  someone  who  has
hacked  a  bunch  of  SIP  stuff  together  over  the  years,  I  know  how
much  there  is  in  SIP,  and  how  much  of  that  we  don't  need  in
this  context.  Certainly  don't  mean  to  imply  it  isn't  a  pretty
strong  candidate.

> > >   >  beginning,  we  run  the  risk  of  getting  very  bogged  down
in  arguing  about  them  as  the  protocol  starts  to  get  close  to
done.

> > >   >  streamed  content  and  the  dynamic  peer  set.  The  working
group  is  only  addressing  centralized  trackers  and  not  the
distributed  tracker.

> > >   >  ?爌roposed  P2P  streaming  system,  motivates  the  desire  for

> > >   >  standardized

> > >   >  ?爏treaming  architectures,  in  particular  tracker-based  P2P

> > >   >  ?燼lso  discuss  use  of  layered  media  encoding  and  related
media

> > >   >  chunk

ppsp  mailing  list

[email-masked]

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 18 Mar 2010 12:34:38 +0800

Hi Cullen,all,
   First of all thanks Cullen for the charter proposal. We are better knowing the IESG concerns. And thanks so much for the hot discussion on the charter.Please allow me to summarize some of our discussion points to make all easily understood.
1) bittorrent  protocol  as  basis  for  the  tracker  communication: After discussion, the conclusion seems that it would be better not to state explicitly PPSP model since we have different options like PPLive's and PPStream's, which are more alike of PPSP.But we may discuss more on Bittorent tracker protocol to find the difference.
2)tracker protocol,centralized or distributed:This is an implemenatation problem.As for the function itself,it is a "centralized"model per se.
3)peer protocol:The function is chunk information exchange.Currently it's not for negotiating the session setup.Need we add this new point into our peer protocol?If it were the case,RTP/SIP/RTSP,even UDP are discussion stuffs and we may launch an Exploratory Group (provided not to delay current PPSP) to look further.
Please let me know if I misunderstand your points and see you all in Anaheim.~I am sure that this PPSP session will be a wonderful meeting under all of your participation.Thanks.

BR
Yunfei

zhangyunfei
2010-03-18

发件人： Martin Stiemerling
发送时间： 2010-03-17 04:17:33
收件人： Cullen Jennings; [email-masked]
抄送： 
主题： Re: [ppsp] Charter Proposal

Hi  Cullen,  all,

   Martin

[email-masked]