[ppsp] RE: 答复: 答复: review: draft-ietf-ppsp-reqs-01

["Y.J. GU" <[e-mail]>]

Sorry for chiming in. Here is some of my opinions on the comments and proposals.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Ning
> Zong
> Sent: Friday, February 11, 2011 11:40 AM
> To: 'Lars Eggert'
> Cc: [e-mail]
> Subject: [ppsp] 答复: 答复: review: draft-ietf-ppsp-reqs-01
> 
> Hi, Lars,
> 
> Thank you for comments. See inline.
> 
> -----邮件原件-----
> 发件人: Lars Eggert [mailto:[e-mail]]
> 发送时间: 2011年2月10日 21:52
> 收件人: Ning Zong
> 抄送: [e-mail]
> 主题: Re: 答复: [ppsp] review: draft-ietf-ppsp-reqs-01
> 
> Hi,
> 
> thanks for responding. I have a few more comments below; I'm cutting all the
> text that I think we have a way forward on.
> 
> On 2011-2-10, at 11:11, Ning Zong wrote:
> > Section 2., paragraph 5:
> >>   Peer list: A list of peer ID which are in a same swarm maintained by
> >>   the PPSP tracker.  A peer must fetch the peer list of a swarm from
> >>   the tracker to know which peers have the required content.
> >
> >  "Must it", really? I agree that this is one way of getting a peer
> >  list, but in some deployments it is also possible to get a peer list
> >  from other peers or through some non-tracker third party.
> >
> > [ZN] In current charter we don't focus on specific tracker entity, but
> > general tracker function provided with various forms such as centralized,
> > distributed, or third-party provided.
> > We can explicitly state in next revision that here the tracker refer to
> > tracker function, rather than tracker server.
> 
> What I meant is that the current definition is too narrow. Yes, the tracker
> has a peer list. But so do the peers themselves (although it is likely much
> less complete than that of the tracker.) But in a system where peers
> exchange peer information directly, or there are multiple trackers, or there
> is some other way to get peer information, *nobody* may actually have the
> definitive list of peers in a swarm - and no one needs to, since the system
> still works OK.
> 
> [ZN] I agree that the tracker is not the only part to provide peer list. In
> PPSP.PP.REQ-4, it says that peer can also get an extra list of peers other
> than those in the list from tracker.
> And you are right that the statement here is not precise. I propose to
> change "fetch the peer list of a swarm from the tracker" to "fetch an
> initial peer list from the tracker or other entity in bootstrapping stage".

[Gyj] I agree that peer can get peerlist from Tracker and other peers. But I am not very sure whether 'getting peerlist from other entity in bootstrapping stage' or 'non-tracker third party'is in the scope of PPSP. According to Section 4 in draft-ietf-ppsp-problem-statement, there are only two entities in PPSP architecture : Tracker and Peer. I agree that a peerlist can be gotten from non-tracker and non-peer entity, but that is not PPSP consideration. So, getting peerlist from either Tracker or peer is okay, other than those, I think, are out of the scope of PPSP. 
I propose to revise the requirement as ' A peer can fetch the peer list of a swarm from
either tracker or other peers to know which peers have the required content '

> > Section 4.1.1., paragraph 0:
> >> 4.1.1.  Basic Requirements to PPSP Node
> >
> >  I think we're missing a high-level requirement that the tracker and
> >  peer protocols should be as similar as possible, in terms of design,
> >  message formats and flows, etc. Ideally, the peer protocol would be an
> >  extension to the tracker protocol that adds a few message types. We do
> >  NOT want two completely different protocols here.
> >
> > [ZN] You are right, and in the current design, the tracker and peer
> > protocols are similar. But do we need to make this as a formal
> requirement?
> 
> Why not?
> 
> [ZN] I am OK to make this a formal requirement. How about other
> contributors?

[Gyj] What Lars suggest is an ideal situation. And we should follow the requirement. But for now, I am not sure whether there are some messages in Peer Protocol that can not be extend by Tracker Protocol. I suggest we define this requirement as a 'SHOULD' item. Lars also suggest 'SHOULD'.

> > Section 4.1.1., paragraph 3:
> >>     The peer ID may be generated from IP address or SIP URI which
> >>   can distinguish this peer with the others.  But if IP address is used
> >>   as peer ID, the ID may be unstable as IP address may change while
> >>   peer moving.
> >
> >  Not sure if we need to discuss here what the options are for choosing
> >  peer IDs. If we want to do this, we need to really discuss all the
> >  options, some obvious ones are missing (e.g., large random value,
> >  etc.)
> >
> > [ZN] Option for choosing peer ID is still a open issue. IMO, consider the
> > case that IP address may change, unique peer IDs such as those used in
> > RELOAD are preferred in peer/swarm management level, while IP address is
> for
> > peer connection.
> > Other thoughts?
> 
> I'd simply cut the text above then.
> 
> [ZN]: I agree.

[Gyj] What the Requirement draft needs to decide is whether the Peer ID need to be unique in global or just in a swarm. I didn't go through the requirement draft words by words, but my memory is that we don't decide yet. 


> > Section 4.1.3., paragraph 2:
> >>   PPSP.REQ-8: The Tracker Protocol and Peer Protocol are Recommended to
> >>   be carried over TCP (or UDP, when delivery requirements cannot be met
> >>   by TCP).
> >
> >  I really think we should be simply requiring TCP here and not even
> >  talk about UDP.
> >
> > [ZN] I don’t quite understand why must TCP?
> 
> Because building something on top of UDP is difficult; see RFC5405.
> 
> In which case do you think TCP will not be appropriate?
> 
> [ZN] Consider the cases:
> 1) a large number of connections between peers are only for temporary
> information exchange (e.g. chunk availability exchange) and won’t persist
> for data transfer (if the requested peers don’t have the requested chunks).
> 2) a peer may communicate with a small subset of peers only for a short term
> and then frequently change to another small subset of peers (like PPLive).
> TCP may introduce more (and possibly unnecessary) overhead.

> > Section 4.2., paragraph 0:
> >>  PPSP.REQ-9: The Tracker Protocol is Recommended to support the IP
> >>  address change report sent from the peer.  The Peer Protocol may
> >>  support the IP address change report sent from the peer.
> >
> >  I have no idea what this means. If this is about supporting mobile
> >  peers, why do we need anything specific to that in the protocol? A
> >  peer whose IP address changes simply looks like a leave-and-join to
> >  the swarm.
> >
> > [ZN] Yes, this is merged from another draft for mobile P2P case:
> > http://tools.ietf.org/id/draft-lu-ppsp-mobile-04.txt
> > IMO, this is helpful to re-connect between peers in a timely manner since
> > peer may not re-send join message to the tracker even after IP change.
> Other
> > thoughts?
> 
> What I'm saying is that a mobility events to the tracker and to other peers
> looks exactly like a leave followed by a join. In other words, we don't need
> any extra support in the protocol for it.
> 
> [ZN] I agree that we don’t need extra message for this. But it seems that
> we then need new requirement about when the peer should send join message -
> bootstrap, IP address change, etc...?
>
>
> > Section 4.2., paragraph 8:
> >>   PPSP.TP.REQ-7: The PPSP tracker MAY generate the peer list with the
> >>   help of traffic optimization services, e.g.  Alto.
> >
> >  Not sure if we need this, since a "MAY"-level statement isn't really a
> >  requirement. This would make more sense as a non-requirement in
> >  explanatory text. Also, cite ALTO.
> >
> > [ZN] How about change "MAY" to "SHOULD support" - which means "optionally
> > implement"?
> 
> ALTO is a mechanism for *peers* to perform better then random *initial* peer
> selection. It's completely unclear if the tracker can even do something
> useful with the ALTO information, at least without a lot more context about
> the peer.
> 
> [ZN] I think in tracker based P2P system, the tracker can act as the ALTO
> client, which receives ALTO information and performs peer selection (Section
> 3.1 in draft-ietf-alto-reqs-07.txt).
> But anyway, I agree that this MAY-level statement should move to
> non-requirement text. I propose to revise the requirement as "PPSP system
> SHOULD support traffic optimization service, e.g. ALTO [cite]". Other
> thoughts?
> 
> > Section 4.3., paragraph 0:
> >>   PPSP.TP.REQ-9: Battery status of the peer SHOULD be reported to the
> >>   tracker in the case where the peers are constrained by their limited
> >>   battery (e.g. cellphone),
> >
> > Why? What is the tracker supposed to do with this information? Also,  what
> > metric do you envision to be applied here, mW?  4.3.  PPSP Peer  Protocol
> > Requirements
> >
> > [ZN] I think the main scenario is mobile P2P where peers have very limited
> > power and are not suitable for long-term streaming and the tracker may
> only
> > put those peers in limited number of swarms.
> 
> The tracker has *no* influence over what swarms peers join or not join, and
> it can't prevent anything. And peers can obviously simply lie about their
> battery information.
> 
> [ZN] If tracker doesn't reply with an initial peer list, it would be
> difficult (not impossible) for the requesting peer to start - just like
> being lack of bootstrap information, right?
> I am also thinking that lower battery status of a peer *may* lead tracker to
> NOT to put this peer in the peer list for other peers, since lower battery
> peer may unstable (e.g. offline soon).
> 
> > Section 4.3., paragraph 10:
> >>   Streaming status information should be related to the content
> >>   delivery, including online time, link status including available
> >>   uplink and downlink bandwidth, peer capability and other streaming
> >>   parameters of the peer.  With this information, a peer can select
> >>   more appropriate peers for content sharing based on some content
> >>   sharing strategies and/or application requirements.
> >
> >  <Insert my standard rant about how difficult it is to provide and use
> >  bandwidth information here.> Also, s/streaming//g (not all swarms are
> >  for streaming)
> >
> > [ZN] Understand. How about "...link status including available bandwidth
> if
> > possible..." or just "...link status including DSL/wifi/etc..."? Other
> > suggestions?
> 
> Remove it?
> 
> [ZN] I am OK, how about other contributors?
> 
> Lars
> 
> 
> 
> _______________________________________________
> ppsp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp