Subject: Re: [ppsp] Charter Proposal - Centralized and distributed tracker(Tao Ma, BUPT)

From: Tao Ma <[email-masked]>
Date: Wed, 17 Mar 2010 14:50:51 +0800

Hi,
   +1
   I think what Cullen means here is the way in which the trackers are
organized should be transparent to peers in PPSP. The examples of Youtube
and Skype are clear enough to clarify the problem to everyone. PPSP would
not show the internal nature of trackers to peers.
Tao Ma
Beijing University of Posts and Telecommunications, Mobile lIfe and New
mEdia(MINE) Lab
2010/3/16 <[email-masked]>

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/ppsp
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send ppsp mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/ppsp
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ppsp digest..."
>
>
> Today's Topics:
>
>   1. Re: Charter Proposal - Centralized and distributed tracker
>      (Xiao, Lin (NSN - CN/Beijing))
>   2. (no subject)
>   3. Re: Charter Proposal -  real-time and time-shifted
>      (Xiao, Lin (NSN - CN/Beijing))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 16 Mar 2010 15:39:02 +0800
> From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
> Subject: Re: [ppsp] Charter Proposal - Centralized and distributed
>        tracker
> To: "ext Ning Zong" <[email-masked]>,      "David A. Bryan"
>        <[email-masked]>,  "Cullen Jennings" <[email-masked]>
> Cc: [email-masked]
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain;       charset="iso-8859-1"
>
> Hi All,
>
>
> Just trying to split the discussions in separated threads.
>
>
> ------------------------------
>
> Message: 2
> Message-ID: <[email-masked]>
>
> 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.=20
>
> 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.=20
>
>
> 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:
> >
> > On Mar 13, 2010, at 8:22 AM, David A. Bryan wrote:
> >
> >> So in general I think there are a lot of good comments here, and=20
> >> thanks for sending things to the list. A few things I had comments on =
>
> >> inline...
> >>
> >> On Sat, Mar 13, 2010 at 9:33 AM, Cullen Jennings <[email-masked]>
> wrote:
> >> >
> >> >
> >> > The PPSP could easily be one of these groups were we spend the=20
> >> > first
> few
> >> > years trying to chooses which protocol to start with in various=20
> >> > places. That would just remove the will to do anything in the=20
> >> > group. I have been lurking and watching this work from the=20
> >> > beginning and it
> seems
> >> > like there are probably many things that most the participants=20
> >> > agree to that we could just nail down in the charter. =A0Doing so=20
> >> > 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=20
> >> > folks want to do a centralized tracker. On a side note, I think=20
> >> > they would be hard to do a distributed one before a centralized as=20
> >> > 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=20
> >> > tracker protocol. If they want to do a distributed one, RELOAD=20
> >> > would meet the 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=20
> >> chunks etc -- are going to be the same between the two. I am still=20
> >> trying to get my head around where the "edge" is here, but from=20
> >> hacking at ideas a bit, it seems to me that the tracker protocol=20
> >> might have two parts: query/place information from the peers to the=20
> >> tracker, and information between trackers. If the separation is=20
> >> clean, it might be possible to only focus on the part between=20
> >> peers/trackers and not consider distributed trackers, but otherwise I =
>
> >> think in protocol design we should at least consider it...seems like=20
> >> a bad idea to design a P2P protocol that neglects P2P at a different=20
> >> level (i.e., between trackers)
> >
> > 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.
>
> >
> >>
> >> > Similarly for the media transfer, I suspect that many people would=20
> >> > 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=20
> >> > protocol that transferred data tunneled in the peer signaling =
> protocol.
> >>
> >> Absolutely agree. Devising new mechanisms for media transport seems=20
> >> way out of scope to me.
> >>
> >> > The peer signing protocol needs to be able to set up the RTP=20
> >> > sessions and work thought NATs. I think the NAT traversal scheme=20
> >> > 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=20
> >> > are candidates here. In some ways at first glance, RTSP might seem=20
> >> > simpler. But a
> bunch
> >> > of that simplicity comes from the model of it being deployed on=20
> >> > server all clients can easily reach without nat nightmares and less =
>
> >> > negotiation. Much of SIP complexity comes form too many=20
> >> > intermediaries and forking which would not apply in this case. =
> =A0We=20
> >> > 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=20
> >> > 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=20
> >> > signaling
> and
> >> > SDP with a capabilities something more like the Advertisement /
> Proposal
> >> > architecture the Jon and I have been discussion (See=20
> >> > 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=20
> >> fighter plane to kill a fly here, but may very well turn out that=20
> >> 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=20
> >> have the full SIP capabilities. We seem to need a SIP-Lite...(and=20
> >> yes, I know that has been discussed oh, once or twice before, but=20
> >> here it 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. =A0My 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.
>
> >> My first take on the proposed charter below is that I like seeing=20
> >> 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=20
> >> 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=20
> >> problems, which is actually my biggest concern with the charter --=20
> >> still not clear that the live and time-shifted content really call=20
> >> 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=20
> >> Bit-Torrent is the right choice. (although I can see using a tracker=20
> >> to find candidate peers and establishing live sessions between=20
> >> them...so it's possible) =A0I'd rather wait just a little bit for the =
>
> >> survey document to evolve to make that call, and get more visibility=20
> >> into if one protocol can be used for both streaming and time-shifted=20
> >> content. That's part of the motivation for hacking together some=20
> >> strawman work on the tracker as well -- let's see what hard problems=20
> >> 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.
> >
> > Fair enough - what you are saying there does seem very reasonable to=20
> > me -
> but if we go down the plan then I think we should probably =A0spin 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.
>
> >> My biggest objection is with the proposal below is saying SIP is the=20
> >> right choice for the Peer Protocol. That seems not-quite-right (even=20
> >> if SIP is used to establish the connections). The peer protocol here.
> >> again, is doing several things -- possibly maintaining an overlay=20
> >> (possible RELOAD usage, although we have to make sure a full DHT is=20
> >> needed, which with a central tracker it may not be) and in the live=20
> >> stream case, establishing connections. Unless we resurrect dSIP=20
> >> (which I'd love ;) ), SIP can't do the former, and I still think it=20
> >> is way overkill for the later unless we come up with a lighter=20
> >> version. I'll take a look at the advprop draft you mention -- that=20
> >> might be exactly what I am thinking of but I have to admit I haven't=20
> >> read it. I guess my worry here is that your version of the draft=20
> >> seems to be taking the "I have a SIP hammer so this is a SIP nail"=20
> >> 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).
> >
> > Well I understand how something like RELAOD might get used for the=20
> > 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, =A0it seems you =
> need a protocol were host =A0A can tell host B to start sending the =
> following data in an RTP steam. =A0Do 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
>
> >>
> >> Reuse of SDP and RTP seem like no-brainers and I definitely agree.
> >>
> >> Anyway, interesting thoughts,and my 2 cents...
> >>
> >> David
> >>
> >> > There are a few other topics which are not addressed in this=20
> >> > charter that worry me a lot. The currently protocols being proposed =
>
> >> > and related discussion does not seem to address what is the=20
> >> > incentive for anyone to serve content. It's clear why you would=20
> >> > receive but not clear why you would bother to transmit. Bittorrent=20
> >> > put a lot of effort into this and IMHO got it "right enough" that=20
> >> > the system is very successful. I worry about it in this work. A=20
> >> > second topic is that the desired privacy properties of the system=20
> >> > are also pretty vague. If we are not clear about these in the=20
> >> > 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=20
> >> > bellow that is very conservative . =A0As an individual, I would=20
> >> > probably have a slight preference for a more risky approach than=20
> >> > the proposal below but .
> >> >
> >> >
> >> > ------------------------------------------------
> >> >
> >> >
> >> >
> >> >
> >> > The Peer-to-Peer Streaming Protocol (PPSP) working group develops=20
> >> > two signaling and control protocols for a peer-to-peer (P2P)=20
> >> > streaming system for transmitting live and time shifted media=20
> >> > content with near real-time delivery requirements.
> >> >
> >> > Two kinds of nodes exist in the targeted P2P streaming system,=20
> >> > i.e., "peers" and "trackers". Peers are nodes that are actively=20
> >> > sending and receiving streamed media content, and include both=20
> >> > statically connected hosts as well as mobile devices with=20
> >> > connectivity and IP addresses that change over time. The set of=20
> >> > 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=20
> >> > streamed content and the dynamic peer set. The working group is=20
> >> > only addressing centralized trackers and not the distributed =
> tracker.
> >> >
> >> > The PPSP WG designs a protocol for signaling and control between=20
> >> > trackers and peers (the PPSP "tracker protocol") and a signaling=20
> >> > and control protocol for communication among the peers (the PPSP=20
> >> > "peer protocol"). The two protocols enable peers to receive=20
> >> > streaming data within the time constraints required by specific=20
> >> > content items. =A0The tracker protocol handles the initial and=20
> >> > periodic exchange of meta information between trackers and peers,=20
> >> > such as peer lists and content information. The peer protocol=20
> >> > controls the advertising and exchange of media data availability =
> between the peers.
> >> >
> >> > The tracker protocol will be modeled as much as possible to match=20
> >> > the exiting bittorrent protocol with appropriate extensions for to=20
> >> > cary information that is needed for selection of a peer suitable=20
> >> > 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=20
> >> > NAT traversal.
> >> >
> >> > RTP will be used for the encoding and transmission of the media=20
> >> > content between peers. PPSP is not chartered to work on media=20
> >> > transmission protocols, media encoding techniques or other=20
> >> > 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
> >> > =A0 =A0proposed P2P streaming system, motivates the desire for=20
> >> > standardized
> >> > =A0 =A0protocols, defines the envisioned scope of those =
> standardized
> >> > =A0 =A0components and discusses common terminologies and concepts.
> >> >
> >> > (2) A "requirements" document that details the specific functional,
> >> > =A0 =A0operational and performance requirements of the two PPSP =
> protocols.
> >> >
> >> > (3) An "architectural survey" document that summarizes current P2P
> >> > =A0 =A0streaming architectures, in particular tracker-based P2P=20
> >> > streaming
> >> > =A0 =A0systems, 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
> >> > =A0 =A0existing IETF protocols, such ALTO, can be combined to =
> create a
> >> > =A0 =A0deployable operational P2P streaming system. =A0This =
> document will
> >> > =A0 =A0also discuss use of layered media encoding and related media =
>
> >> > chunk
> >> > =A0 =A0descriptions 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=20
> >> > are deemed necessary, PPSP shall communicate and discuss the=20
> >> > requirements for such extensions with the relevant WGs but is not=20
> >> > charted to make such changes.
> >> >
> >> > Goals and Milestones:
> >> >
> >> > Sep 2010 =A0 Submit problem statement to IESG as Informational Dec=20
> >> > 2010 =A0 Submit architectural survey to IESG as Informational Dec=20
> >> > 2010 =A0 Submit requirements document to IESG as Informational Aug=20
> >> > 2011 =A0 Submit PPSP peer protocol to IESG as Proposed Standard Aug =
>
> >> > 2011 =A0 Submit PPSP tracker protocol to IESG as Proposed Standard=20
> >> > Dec 2011 =A0 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
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > ppsp mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/ppsp
> >> >
> >>
> >
> >
> > Cullen Jennings
> > For corporate legal information go to:
> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> >
> >
> >
> >
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 16 Mar 2010 16:06:09 +0800
> From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
> Subject: Re: [ppsp] Charter Proposal -  real-time and time-shifted
> To: "ext David A. Bryan" <[email-masked]>, "Cullen Jennings"
>        <[email-masked]>
> Cc: [email-masked]
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain;       charset="iso-8859-1"
>
>
> 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
>
> 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:
> >
> > On Mar 13, 2010, at 8:22 AM, David A. Bryan wrote:
> >
> >> 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...
> >>
> >> On Sat, Mar 13, 2010 at 9:33 AM, Cullen Jennings <[email-masked]>
> wrote:
> >> >
> >> >
> >> > 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.
> >>
> >> 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)
> >
> > 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.
>
> >
> >>
> >> > 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.
> >>
> >> Absolutely agree. Devising new mechanisms for media transport seems
> >> way out of scope to me.
> >>
> >> > 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 ).
> >>
> >> 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)
> >
> > 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.
>
> 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.
>
> >> 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.
> >
> > 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.
>
> >> 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).
> >
> > 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?
>
> 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
>
> >>
> >> Reuse of SDP and RTP seem like no-brainers and I definitely agree.
> >>
> >> Anyway, interesting thoughts,and my 2 cents...
> >>
> >> 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 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
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > ppsp mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/ppsp
> >> >
> >>
> >
> >
> > Cullen Jennings
> > For corporate legal information go to:
> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> >
> >
> >
> >
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>
>
> ------------------------------
>
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>
>
> End of ppsp Digest, Vol 18, Issue 17
> ************************************
>