Hi: I don't know what happened to the list. I posted comments but have not been put on the list, despite Cullen received it and gave the response. So I repost them again.
Regards! -- Jiang XingFeng ----Original Message----- From: JiangXingFeng [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2008 4:22 PM To: 'Cullen Jennings'; 'P2PSIP WG' Cc: 'Salman Abdul Abdul Baset' Subject: RE: [P2PSIP] New version of draft-bryan-p2psip-reload Hi, Some comments on the new RELOAD-4. Hope it is helpful. 1.connect: IMHO, the peer sending the connect request SHOULD check whether the destination peer ID equals the peer ID it wants to connect or not when receiving the response. But in some case, the peer may find a peer who is reponsible for the requested Node ID, not the peer whose ID equals the request Node ID. For example, if a peer receives a UPDATE request and start to connect with the peer in the routing table in the UPDATE reqeust. Maybe some peer is not alive or offline, in this case, the connect request will be directed to the peer being responsbile for the Node ID. So suggestion is to check whether mismatch happens. (Open Issue: do we need extend connect to distinguish connect for a resource or for a peer? For example, if the resource value is so large that not be appropriate delivered through the overlay, a direct connection may be needed for the future transfer.) 2.In section 1.2.4 When connections are made or broken, the Forwarding Layer notifies the Topology Plugin, which adjusts the routing table as appropriate. To me, I am not clear how the RELOAD detects the connection has been broken down? Just relying on the STUN keepalive message or conclusion from failure to deliver the packets to the next hop if the transport protocol is not reliable, such as UDP? Why not use a keepalive mechansim at the peer layer to detect the connection failure? 3.In section 6.1.1, the value for retransimisson time is set to 3 seconds? I want to know based on what kinds of experimental data, the authors choose the value? Is 3 seconds chosen as the maximum end-to-end latency? IMHO, the latency of the transaction depends greatly on the number of hops requests will traverse. So it will vary among overlays whose scale are different. 4. In section 3.3.1, some routing alternatives are listed. As for direct response and relay peer, I think they could be well used together with the symmetric routing proposed in RELOAD-04 although there are some limits with their use. For example, the original peer could convey its contact address and/or the chosen relay peer information to the destination in the request, it's up to the destination peer to choose whether send the response in all ways or only in a subset of ways. In this way, they could bring enhancement to the symmetric routing. As for routing in the overlay, my major concern is still the stablity of the reverse connection due to the churn. In my mind, symmetric routing works better where the hops for the request is not big and direct response and relay peer could provide much help when the hops is big. I've done a few work on comparing different routing modes listed in RELOAD-4 which has not finished yet. If some data comes out, I will share them with the community. 5. Data models in current RELOAD-4 are single value, array, dictionary. My suggestion is to use scalar, array and map which are borrowed from literatures in data structure. 6. In section 4.2, it says the RELAOD has not defined a generic service discovery mechanism, but in section 9, a mechanism to discover TURN server is defined. Does the RELOAD consider the TURN server as a special service? Why not define a generic service discovery mechanism which also address the TURN server discovery? 7. struct { ResourceId resource; uint8 replica_number; StoreKindData kind_data<0..2^32-1>; a IP packet could not hold it. jiangxingfeng } StoreReq; >From the above definition, the StoreReq consists of up to 2^32-1 StoreKindData, the scale of the array kind_data is too large to be possible put into a single IP packet. Regards! -- Jiang XingFeng > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Cullen Jennings > Sent: Wednesday, June 11, 2008 2:47 AM > To: P2PSIP WG > Cc: Salman Abdul Abdul Baset > Subject: [P2PSIP] New version of draft-bryan-p2psip-reload > > > We've just uploaded an update to the reload draft. Until it shows up > in the drafts directory, you can find it at > > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-bryan-p2psip-reload- 04.txt > or > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-bryan-p2psip-reload- 04.html > > reload-04 represents a total rewrite of the presentation of the > protocol. There were a number of goals: > > - add several descriptive sections at the beginning that detail how > the protocol works and the design choices we made (and some of the > options we chose not to incorporate at this point) > - Simplify the presentation (and protocol) wherever possible by > removing extraneous features from this draft. Some of these may come > back in future drafts, but we felt simplifying wherever possible was > good. > - remove the bit-field diagrams from the protocol descriptions in > favor of c-like message structure presentations. > > We are very interested in comments on this draft. We expect to have > time for another revision in about 2 weeks. We have tried to address > as many of the comments and questions that have been raised as we > can. In some areas we have made deliberate choices to avoid adding > features that have been requested. Where possible we discuss the > tradeoffs that adding additional features will require. We think it's > important for the working group to decide as a whole where additional > features are worth the added complexity. > > Please send your comments to the working group list - it would make it > easier for us if people tried to keep separate issues in separate > threads and start new threads where it appropriate. I think we would > all like to hash out as many protocol issues as possible before we get > to Dublin. > > Cullen > Bruce > Eric > Salman > Henning > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
