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

["Xiao, Lin (NSN - CN/Beijing)" <[e-mail]>]

Thanks Lars for such a close review on the draft. It's really helpful for us to re-consider some issues and to refine the draft for the next version.  
As the comments are very long, I just list my opinions simply as followed:

1. for the peerlist fetching, I think we have got the agreement that Peer can fetch the peer list of a swarm from either tracker or other peers, and the initial peerlist should be fetched from tracker.

2. Agree to add a new requirement to declare that the protocol design should keep same style for both Peer protocol and tracker protocol, in terms of message formats and flows,

3. It is agreed that the Peer ID is unique within a swarm. But considering the special situation that a peer may take part in multiple swarms, is it better to simply keep one ID for the peer among different swarms?

4.  For some issues from mobility consideration, I agree with Lars as I suggested in IETF 79 that, it's not necessary to make such a specific requirement to handle IP address changing. Any peer status change can be reflected in the periodically status report, including the battery status. The detailed items which status should be involved in the report should not be fully listed in the requirement draft.

5. for ALTO support, I agree with Ning that tracker can work as an ALTO client to refine the peer selection responding.


BR
Lin


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of ext Y.J. GU
Sent: Friday, February 11, 2011 3:10 PM
To: 'Ning Zong'; 'Lars Eggert'
Cc: [e-mail]
Subject: [ppsp] RE: 答复: 答复: review: draft-ietf-ppsp-reqs-01

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

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