Update Acknowledgements with many folsk that provided comments in WGLC. CJ - DOne Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work seems issues resolved on list Begin forwarded message: From: Roni Even Date: December 10, 2009 2:30:54 PM MST To: p2psip@ietf.org Subject: [P2PSIP] comments on draft-ietf-p2psip-base-06 in WGLC According to section 1 Reload is based on the concepts introduced in ietf-p2psip-concepts. The concept draft is currently expired and I noticed some contradictions between the two drafts. I think that the reload draft should progress with the concept draft. According to the concepts draft "The P2PSIP WG will not standardize how the peer-ID and the credentials are obtained, but merely standardize at least one acceptable format for each. To ensure interoperability, it is expected that at least one of these formats will be specified as "mandatory-to-implement"." According to RELOAD the node-id is mandated as a 128 bit value. According to the concept draft it can be as mandatory to implement format but others should be allowed. I also think that section 5.4.1 allows for different node-id length (see "o The length of the Resource-IDs and Node-IDs. For DHTs, the hash algorithm to compute the hash of an identifier." CJ - sent email on this one In section 5.2 on symmetric recursive routing says that "An overlay may be configured to use alternative routing algorithms, and alternative routing algorithms may be selected on a per-message basis." Yet I noted that in some of the text the assumption is that symmetric recursive is the only routing algorithm. For example in section 5.2.2 it says "When a peer sends a response to a request, it MUST construct the destination list by reversing the order of the entries on the via list.". This is true only for recursive routing. Another example is that the text allows an intermediary peer to decide to keep a per transaction state (see section 5.1.2) which will work for recursive routing but may break other routing algorithms. If the text in section 5.2 is the objective I suggest that in 5.2.2 it will say that in the case of recursive routing this procedure must be used. I also suggest that since 5.2.2 allows alternative algorithms on per-message basis than the requesting peer should be allowed to prevent state keeping by intermediary peers in order to support other routing mechanisms. The intermediary peers do not know what routing is used and may choose wrong behavior. CJ - Fixed the parts where this implies it is ontly only routing algorithm but extentions to tell intermendaries not to keep states breaks other pats of the protocl and previso discussed so I think that needs to be in the extention that defines the new routing algorithm. As you point out, if the itnermediarees don't udnerstan the algorhtim in use, things break. I noticed that the overlay link layer MUST use TLS/DTLS. I am not sure where the requirement to mandate TLS and DTLS is coming from, more specifically the requirement to encrypt the signaling. One of the objectives of RELOAD is to minimize the burden of becoming a peer and TLS with encryption does not help that. I think that TLS or DTLS can be specified as mandatory to implement security but optional to use based on the security level required by the implementation which may chose different security that may be available in other layers of the network. If there are specific security requirements based on a specific usage than the requirements to use TLS/DTLS should be in the usage. I looked at draft-irtf-p2prg-rtc-security and did not see that TLS/DTLS must be used. I see cases like when using routing mechanisms which are not recursive that some of the paths will not need TLS. Section 3.3 mentions that client promoting to peers may be used for routing, in the case of passive promotion the establishment of trust relation may bring different requirements. So I think that mandating using one solution does not fit all. CJ - there will be a seprate thread on to sort out resolution around this. Section 3.6.1 details the initial configuration establishment, from the text it this paragraph and in section 3.6 above it looks like this is the only allowed procedure, was that the meaning or is that an example. Looking at section 10 I am not sure what a new configuration file means, is this new values to the elements, in this case how can the configuration document defined in section 10 be extended with new elements that may be needed for new features. CJ - Tried to clarify that 3.6.1 was optional to use. The confic_update methond from section 5.5.4 can also be used to discribtue a cahnge or update to the configuration. It is a new configuraiton document. It can new or changed values as well as new or changed elements. Have a read of 5.3.2.1. too. Section 8 discusses TURN server usage. I was wondering if a peer can be a TURN server it can also be a "supernode" or a relay peer, so why not publish the general capability that this node is publicly reachable. CJ - It does not know that it is publicly reachable. It only knows, that it does not know that it is not publicly reachable. I know that is a lot of negatives but it was the most persise way I could find to say it. Roni Even _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: Jouni Mäenpää Date: November 27, 2009 3:49:16 AM MST To: "David A. Bryan" , Brian Rosen Cc: "p2psip@ietf.org" Subject: [P2PSIP] Review of RELOAD base draft Hi, I volunteered to review the RELOAD base draft in the P2PSIP session in IETF 76. My collegue Ari Keranen also volunteered after the IETF meeting. Since it's a long draft, we decided to do the review together. Our comments are listed below. Cheers, Jouni Maenpaa Ari Keranen Page 13, Section “1.2.1. Usage Layer” The text talks about the abstract Message Transport API. Could the functionality that the API provides be described somewhere in more detail? Page 17, Section “2. Terminology” (1) There are some terms marked with a (*) that are new and “perhaps should be added to the concepts document”. I suppose a decision needs to be made whether to have the terms permanently in the base draft or whether to move them to the concepts draft. CJ - Think the genral strategyis to define what you need to know in this draft and keep the ref to base. Fixed up . (2) Should the terms Kind and Kind-ID be defined here? CJ - Added. Page 22, Section “3.2.1. Client Routing” (1) “Note that clients that choose this option MUST process Update messages from the peer. Those updates can indicate that the peer no longer owns the Client's Node-ID.” Should the content of these Update requests be defined somewhere in the draft or are the regular Updates enough for doing this? BBL: The regular updates sent by peers to all connection table entries when their responsible IDs change. (2) If I have understood correctly, a peer does not know whether a particular node in its connection table is a peer or a client. Therefore, it has to send stabilization messages (i.e., Updates) to all nodes in its connection table. The cost of this can be very high in overlays experiencing churn. I have more comments on this topic later (in the comments I have for section 9). If a peer could know which nodes in the connection table are clients and which are peers, Updates could be sent only to those nodes (i.e., clients) that need to be informed immediately (peers are informed through the periodic stabilization process so there is no need to send a reactive Update). BBL: tough choice. I changed the wording to allow a more efficient implementation, but didn't mandate that an overlay algorithm track the information required to minimize that transfer. (3) The description of the second routing option by which a client may be located in an overlay contains the following text: “The Destination List required to reach it [the client] must be learnable via other mechanisms, such as being stored in the overlay by a usage...” Since this alternative is given in the base draft, should the base draft also describe the usage for storing Destination Lists? Without such a usage, the second routing option is not really usable. BBL: It seems like such a list would be part of a structure with other usage-specific information. I don't see the general benefit of defining a usage for how to store a destination list by itself. (4) Should the overlay configuration document contain information about which client routing mode is used in the overlay? BBL: I could maybe see an operator prefering one over the other, or maybe a usage, but there's no incompatibility with using both on the same overlay. Page 22, Section “3.2.2. Minimum Functionality Requirements for Clients” “Implement RELOAD's connection-management connections” What are connection-management connections? BBL: fixed Page 23, Section “3.3. Routing” “Client promotion: RELOAD must support clients that become peers at a later point as determined by the overlay algorithm and deployment.” Should client promotion be described somewhere in the base draft? BBL: no, up to the overlay algorithm Page 27, step (4) of the second operation required to join the overlay “AP does Updates to JP and to other peers...” Doing this is probably ok in a small and low-churn network (i.e., in cases when it is ok to use reactive stablization). However, in a larger, higher-churn overlay (in which periodic stabilization would be used instead of reactive stabilization), sending Updates to all peers in the AP's connection (or routing/neighbor) table might be too expensive. Such Updates may not be needed since the other peers will learn about the JP through the periodic stablization process. BBL: normative text in an overlay algorithm would describe what is actually done here Page 32, Section “4.3. Application Connectivity” “Each usage specifies which types of connections can be initiated using AppAttach.” Should this requirement be listed also in Section “4.1.2. Usages”? BBL: fixed Page 36, third paragraph (1) “When an originating node transmits a requests it MUST set a 3 second timer” Should the value of the timer be configurable? (2) Should there be a back-off mechanism for the retransmissions? (3) “If a response has not been received when the timer fires, the request is retransmitted...” How is this related to the procedures in Section “5.6.2. Reliability for Unreliable Links”? Is it intentional that both the originator of the request and the intermediate peers retransmit the messages? (4) “The request MAY be retransmitted up to 4 times...” Should the maximum number of retransmissions be configurable? When should one use less than four retransmissions? (5) The P2PP protocol had a pretty nice way of describing the transaction state machines, including the various timers and retransmissions (see http://tools.ietf.org/id/draft-baset-p2psip-p2pp-01.txt, figures 8-11). I would like to see similar diagrams in the RELOAD base draft as well. This would be very helpful when implementing RELOAD. P2PP also specified different state machines for reliable and unreliable transports. This could be done in the RELOAD base draft as well. Page 36, fourth paragraph “the maximum request lifetime (15s)” Should the maximum request lifetime be configurable? CJ - Note I agee on changes on configurable times and such but did not make any changes. If Salman wants to do figures, I don't care one way or other but it's hard to get these right. Page 38, first paragraph There is an open question: “We consider it an open question what the final protocol definition method and encodings use.” I suppose this open question can be removed. BBL: fixed Page 38 (1) “Note: the use of "typedef" here is an extension to the TLS language, but its meaning should be relatively obvious” Perhaps it would be a good idea to explain the meaning anyway. (2) Is an opaque string of bytes always preceded by one or more length bytes like in case of ResourceID? Could you clarify this in the draft (it is currently not very clear)? CJ - Fixed Page 41, “version” field in the forwarding header Just wanted to verify that it is intentional to still use version 0.1. CJ - added note to have this changed to 1.0 when document is approved Page 42, Section “5.3.2.1. Processing Configuration Sequence Numbers” (1) Is the Config_Update request sent on a direct connection or across the overlay? If it is sent across the overlay via multiple hops, then it can cause additional load at intermediate peers. The Config_Update request may also be considerably larger than other requests sent in the overlay, because the configuration document can be rather large.. I would like to see some additional discussion on the traffic load the proposed mechanism can cause. If the configuration documents propagate very quickly throughout the system, then there might be a considerable short-term traffic peak. Perhaps there is a need for a mechanism that can limit the additional traffic caused by Config_Update requests. (2) As an optimization, intermediate peers could potentially inspect the configuration documents in the Config_Update messages they forward and update their own configuration settings if they see a newer document. However, I am not sure whether this would reduce the load enough. CJ - agree but did not do this CJ - this is OK - we have the text "The sequence number in the document is greater than the current configuration sequence number. " Page 46 Where is the format of the MessageCode defined? fixed - it's a uint16 Page 48, definition of error_info What is the format of the text string? UTF-8? CJ - uh, sure, changed to UTF-8 but it is not meant for end suers so it's not really localizable in the typical ways Page 52, Section “5.4.1. Topology Plugin Requirements” (1) “All overlay algorithms MUST specify maintenance procedures that send Updates to all members of the Connection Table whenever the range of Ids for which the peer is responsible changes” Doesn't this mean that all overlay algorithms are mandated to use reactive stablization? I would rephrase this to something like “All overlay algorithms MUST specify maintenance procedures.”, that is, not mandate reactive Updates. BBL: fixed (2) Further, sending to all members of the Connection Table might be an overkill. Wouldn't it be enough to send only to the peers in the Neighbor set (provided that the overlay algorithm that is used maintains such a set)? BBL: no, there are other reasons to connect based on ID Page 54, Section “5.4.2.3. Update” (1) “In general, peers MUST send Update messages to all their adjacencies whenever they detect a topology shift” Again, the draft is mandating the use of reactive stablization. So I guess this sentence should be removed. Alternatively, the MUST could be changed to MAY. BBL: fixed (2) “The UpdateAns response is expected to be either success or an error” I think that in some cases, it might be beneficial to have some content in the UpdateAns response (e.g., routing table entries). Therefore, I think the draft should make it possible for UpdateAns responses to contain overlay-specific data (in the same way it allows this for UpdateReq requests). Page 59, AttachReqAns struct Is the “role” encoded as a string? Wouldn't an enum be sufficient? Page 60, definition of “rel_addr_port” “corresponds to the rel-addr and rel-port productions. Only present for type "relay".” Should this be present also for srflx and prflx types as in the struct on the previous page? Page 61, Section “5.5.1.3. Using ICE With RELOAD” “Because RELOAD always tries to use TCP and then UDP as a fallback [...]” Is this normative? Can't a peer prefer UDP? BBL: removed ICE-TCP usage altogether. added RECOMMENDED preference order, which does prefer TCP over current simple reliability congestion control, but recommends SCTP/DCCP preference over TCP. Page 70, Section “5.5.6.2. Response Definition” “If the Config_UpdateReq is of type “kind” it MUST only be processed if it is correctly digitally signed by an acceptable kind signer.” Could you define what an “acceptable kind signer” is here? Perhaps I missed something, but this was unclear to me. CJ - added text Page 73, Section “5.6.2.2. Retransmission and Flow Control” This section mentions multiple alternatives for the retransmission and congestion control scheme. Should all the peers in the overlay use the same retransmission and congestion control scheme? In that case, the scheme to use should probably be specified in the overlay configuration document. BBL: ICE allows that to be negotiated on a per-connection basis. Currently the only configuration element specifies whether the "no ICE" protocols may be used. Not sure a list of allowed overlay link protocols helps that much. Page 82, text about replica numbers “If the replica number is zero, then the peer MUST check that it is responsible for the resource and, if not, reject the request. If the replica number is nonzero, then the peer MUST check that it expects to be a replica for the resource and that the request sender is consistent with being the responsible node (i.e., that the receiving peer does not know of a better node) and, if not, reject the request.” This text may assume too much about the replication strategy that is being used. As far as I know, in some replication strategies (e.g., multi publication key replication), a peer storing a replica may not be able to check whether it is supposed to store a replica (in the successor replication strategy that RELOAD uses, this can be done by checking the predecessor list). Therefore, I think this text should be made more generic so that it allows the use of other replication strategies. Page 96, Section “8. TURN Server Usage” Perhaps there could be some additional text in this section stating that the overlay MAY use an alternative, more advanced service discovery mechanism for locating TURN servers if such a mechanism is available. BBL: maybe turn server usage is important enough that there should be an overlay configuration element specifying the usage being used for locating them? Pages 97-98, Section “9. Chord Algorithm” (1) One additional major difference to the original Chord algorithm that should be mentioned here is that chord-reload can optionally use reactive stabilization. The original Chord algorithm does not use reactive stablization but only periodic stabilization. One could also explain why reactive stabilization is allowed in chord-reload (i.e., that it has been shown to work well in small, low-churn overlays). One should also add some information about previous results, which have shown that reactive recovery can result in degraded performance or even congestion collapse in large-scale (1000 peers or more) overlays experiencing moderate or high levels of churn. Results proving that reactive recovery is not optimal in such networks are available in [1]. (2) It should also be mentioned in here that reactive stabilization MAY be disabled in chord-reload (the “if using reactive recovery” statements in the text actually allow this). In this case, only periodic stabilization is used. Use of periodic stabilization is more appropriate in large-scale (1000 peers or more) overlays experiencing churn. BBL: when I removed the mandatory reactive recovery text, I didn't put any explanatory text in its place. fixed Page 98, Section “9.1. Overview” (1) “The neighbor table typically contains the three peers before this peer and the three peers after it in the DHT ring” The draft should state here that the successor list and the predecessor list can contain more entries if necessary. The Chord paper [2] states that O(log2(N)) successors should be maintained to increase robustness. Maintaining three successors is sufficient in very small overlays. However, in a Chord ring with for instance 1000 peers, on the order of 10 successors should be maintained to make the system more robust. Perhaps the number of predecessors and successors to maintain should be made configurable? (2) “There may not be three entreis...” => “There may not be three *entries*...” BBL: the actual normative text had MUST at least 3, but I revised the text in a few places to recommend log(n) and clarify this Page 99, Section “9.3. Redundancy” (1) “When a peer receives a Store request for Resource-ID k, and it is responsible for Resource-ID k, it stores the data and returns a success response. It then sends a Store request to its successor in the neighbor table and to that peer's successor.” I would expect that in large-scale overlays experiencing churn, it may be necessary to store more than 2 replica copies. Perhaps the number of replicas to store should be configurable (of course the size of the neighbor table limits the number of replicas that can be stored). BBL: This isn't really a large-scale issue. I'm hesitant to make this change, since it has the potential to increase the storage requirements of the overlay significantly without much benefit. Under churn, it's frequently difficult to get to any of the replicas, since the routing may be broken further away. I believe random replicas are more likely a better solution. I'm not aware of any results or simulations published on the topic, though. (2) This section is missing details on when replicas can be removed and when the replicating peer needs to store further replicas. Those details are specified in the end of Section “9.6.3. Receiving Updates”. Could those details be moved to Section 9.3? BBL: I think the text in 9.6.3 is more useful to implementers there, since it's a reminder when to do it, but I added a reference to it in 9.3 Page 99, Section “9.4. Joining” (1) “3. JP SHOULD send Attach requests to initiate connections to each of the peers in the neighbor table as well as to the desired 16 finger table entries.” Should it be mentioned here that also finger tables having more than 16 entries are allowed? Perhaps the number of fingers to maintain should be made configurable. BBL: I removed 16. # fte is already adaptive (2) “8. AP MUST send an Update to all its neighbors with the new values of its neighbor set (including JP).” Informing all the neighbors of the AP may be unnecessary if periodic recovery is being used. Could this sentence be modified as follows: “8. If using reactive recovery, the AP MUST send an Update...” If periodic recovery is used, then peridic stabilization will take care of informing the neighbors of the AP that a new peer has joined. BBL: This is the type of problem that I think is actually better solved by more careful client promotion to peer than by reactive/periodic (i.e. it only matters if you believe new peers are likely to go away within 30s), though we don't have election/promotion in this algorithm at all, However, this doesn't really match any of the problems with reactive recovery, anyway. The problem with reactive recovery is primarily one of creating a cascade failure by generating more traffic when congestion causes lost connectivity. This isn't really related to that scenario. Rhea actually recommended reactive recovery for small neighbor sets, and we aren't even that aggressive. Sending updates immediately really isn't an issue. Again, remember that just the process of sending the attaches has sent a lot of traffic. BBL: on the Update issue, I did relax the requirement in reactive mode to send Updates to all connection table entries whenever a neighbor fails, that should have been send Update to all neighbor table entries. I also made it explicit that Updates are sent to all connection table entries when the responsible id range changes. (3) “In order to set up its neighbor table entry for peer i...” I guess this should be “In order to set up its finger table entry for peer i...” BBL: fixed Page 102, Section “9.6.1. Handling Neighbor Failures” (1) This section and many other subsections contain statements like this: “If using reactive recovery...” I think it should be stated explicitly somewhere (in the beginning of Section 9, as I am suggesting above) that reactive recovery can be disabled, in which case only periodic recovery is used. (2) Should the overlay configuration document indicate whether reactive recovery is used or not in the overlay? BBL: added configuration parameter Page 104, second paragraph “If peer N which is responsible for a Resource-ID R discovers that the replica set for R (the next two nodes in its successor set)...” Same comment as before: perhaps replica sets consisting of more than two nodes shoud be allowed. BBL: same response Page 104, Section “9.6.4.1. Updating Neighbor Table” (1) “A peer MUST periodically send an Update request to every peer in its Connection Table” Should “Connection Table” be rather “Neighbor Table”? Sending to every peer in the Connection Table means that an Update is sent also to the fingers (i.e., at the very minimum to 3+3+16=22 peers, to all the clients attached to the peer, and also to all of the peers that are in the connection table but not in the routing table; such as peers that are using this peer as a finger). This may cause too much traffic. Note that the original Chord algorithm sends only an Update to the first predecessor and to the first successor. I would rephrase this to something like: “A peer MUST periodically send an Update request to all or a subset of the peers in its neighbor table” BBL: no, clients need the updates too. (2) “The default time is about every ten minutes.” This is not sufficient in large-scale networks experiencing churn. However, it may be sufficient in small-scale, low-churn overlays in which reactive recovery is used. Therefore, I would modify this as follows: “If reactive recovery is used, the default time is about every ten minutes.” BBL: I have absolutely no idea what type of network would be able to successfully run this protocol at all that would be overloaded by one update every 10 minutes. Worry about STUN keepalive traffic first. Page 104-105, Section “9.6.4.2. Refreshing finger table” (1) “A peer SHOULD NOT send Ping requests looking for new finger table entries more often than the configuration element “chord-reload-ping-interval”, which defaults to 3600 seconds (one per hour)”. This is not sufficient in large-scale networks experiencing churn. However, it may be sufficient in small-scale, low-churn overlays in which reactive recovery is used. Therefore, I would modify this as follows: “A peer SHOULD NOT send Ping requests looking for new finger table entries more often than the configuration element “chord-reload-ping-interval”. If reactive recovery is used, this defaults to 3600 seconds (one per hour).” BBL: I'm sorry, but if one ping an hour can take down a network, the network is already down. This is silly, and it's already configurable. (2) Paragraph 4 on page 105 describing Alternative 2: I would add a warning here stating that Alternative 2 should only be used in small-scale, low-churn overlays because it can cause much more traffic than Alternative 1. Alternative 1 is more appropriate for large-scale overlays experiencing churn. BBL: I entirely rewrote alternative 2 to do approximately the same thing using received updates without any active probing. Page 112, last paragraph of Section 10.1. “When a node receives a new configuration file, it MUST change its configuration to meet the new requirements. This may require the node to exit the DHT and re-join.” Exiting and re-joining as a result of receiving a new configuration file is potentially a huge problem. If the configuration file spreads rapidly in the overlay, there is a short period of time during which all the peers will exit and re-join. The resulting churn will most probably be so high that the network will collapse. BBL: I added some warning text. For some events it's impossible to avoid. It's out of scope for this draft to specify how to do a gradual restart (and not even clear what that would mean/how to do it without a service interuption). Page 138, Section “15.2. Informative References” [I-D.maenpaa-p2psip-self-tuning]: there is a newer version of the draft available: [I-D.maenpaa-p2psip-self-tuning] Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self- tuning Distributed Hash Table (DHT) for REsource Location And Discovery (RELOAD)", draft-maenpaa-p2psip-self-tuning-01 (work in progress), October 2009. ==== Nits ==== Node-ID is sometimes spelled as “Node-Id” and sometimes as “Node-ID”. Further, sometimes "Peer-ID" or "peer ID" is used. CJ - Fixed, I hope Page 10, Section “1.2. Architecture” “RELOAD is fundamentally an overlay network” I guess it would be better to say “The RELOAD network is fundamentally an overlay network” to be consistent with the text in the previous subsection. Page 12, last paragraph “the roles of various layer” => “the roles of various *layers*” CJ - fixed Page 13, the figure There seem to be some indentation issues in the figure. cj - fixed Page 25 “RELOAD does not support an intermediate peer returning a response that it will not recursively route a normal request” Is something missing from this sentence? CJ - fixed Page 35, Section “5.2.1 Request Origination” “The simplest such destination list is a single entry containing the peer or Resource-ID.” => “The simplest such destination list is a single entry containing the *Node*-ID or Resource-ID.” cj -fixed Page 43, Section 5.3.2.2 enum DestinationType uses term “node”, whereas the definition of “type” on the following page uses “peer”. cj - fixed Page 44, definition of “type” Could you open the acronym PDU? cj - fixed Page 58, Section “5.5.1. Attach”, first paragraph “A node sends an Attach request when it wishes to establish a direct TCP or UDP connection...” Should this be “a direct TLS or DTLS connection...”? cj - letf as is Page 66, row 6 “Check the certificate receive in...” => “Check the certificate *received* in...” cj - fixed Page 74, first paragraph “...if it is known that all nodes are are...” => “...if it is known that all nodes *are*...” cj -fixed Page 102, the description of the “fingers” field: “The finger table if the Updating peer...” => “The finger table *of* the updating peer...” cj-fixed Page 111, definition of “multicast-bootstrap” “This element represents the address of a multicast, boradcast...” => “This element represents the address of a multicast, *broadcast*...” cj -fixed Page 116, second last paragraph of Section 10.3. “...and have appropriate HTTP stats codes.” => “...and have appropriate HTTP *status* codes.” cj - fixed Page 124, Section “12.4. Certificate-based Security” (1) “The user is also assigned one or more Node-IDs by the central enrollment authority. Both the name and the peer ID are placed in the certificate,...” => “The user is also assigned one or more Node-IDs by the central enrollment authority. Both the name and the *Node-ID* are placed in the certificate,...” (2) “o As a overlay peer with the peer ID(s)...” => “o As a overlay peer with the *Node-ID(s)*...” cj - fixed Page 137, Section “14. Acknowledgments” “Hautakorp” => “Hautakorpi” cj - fixed Page 143, “Appendix B. AIMD Retransmission Scheme” “...and is based on the theAIMD...” => “...and is based on *the AIMD*...” cj - fixed [1] Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, "Handling churn in a DHT", In Proc. of the USENIX Annual Techincal Conference June 2004. [2] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications", IEEE/ACM Transactions on Networking Volume 11, Issue 1, 17-32, Feb 2003. cj-fixed _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Hi, We had another closer look at especially sections 5 and 9 of the draft; comments follow. Page 59, Section "5.5.1.1. Request Definition" Is there a need to send foundations if there is only single stream and component ID? BBL: yes, foundations are used to differentiate candidates with different sources (transport protocol, IP address, etc) Page 62, Section "5.5.1.5. Gathering Candidates" "An agent MUST implement ICE-tcp [I-D.ietf-mmusic-ice], and MUST gather at least one UDP and one TCP host candidate for RELOAD and for SIP." (1) Why ICE-tcp is a MUST? Wouldn't UDP be enough for many cases and ICE-tcp could be a "SHOULD"? (2) Why base draft defines that one must gather candidates for SIP? Should this be in the SIP usage draft instead and this section could talk about candidates for applications/usages in general? There seem to be quite a few references to SIP usage elsewhere in the draft too. BBL: ICE-TCP has been removed. I've tried to remove references to SIP that don't seem appropriate. Page 62, Section "5.5.1.6. Encoding the Attach Message" "Instead of actually encoding an SDP, the candidate information (IP address and port and transport protocol, priority, foundation, component ID, type and related address) is carried within the attributes of the Attach request or its response" Component ID is not in the attributes, and probably foundation shouldn't be either. BBL: fixed component Page 62, Section "5.5.1.8. Role Determination" "The connectivity checks MUST still contain the ICE-CONTROLLED and ICE-CONTROLLING attributes, however, even though the role reversal capability for which they are defined will never be needed with RELOAD. This is to allow for a common codebase between ICE for RELOAD and ICE for SDP." Should you rather just generate the value for the ICE-CONTROLL{ED,ING} attribute locally instead of sending it in the messages? This would allow for using common code base and still make the message simpler/save bandwidth. BBL: not sure what you mean. sending it with ICE for SIP media and not sending it with RELOAD would mean a change in the code Page 64, Section "5.5.2. AttachLite" As the ICE-TCP draft says, "Unlike UDP, there [is] no lite implementation defined for TCP", so this section may need some additional text about TCP lite candidates. BBL: rewrote a lot of this. Also change the name to No-ICE to make sure it's clear it's not ice lite. Page 66, Section "5.5.3. AppAttach" "The AppAttach request and its response contain an application attribute, with a value of SIP or RELOAD, which indicates what protocol is to be run over the connection." (1) Isn't normal Attach used for RELOAD instead of AppAttach? And you seem to have SIP usage specific text also here. (2) The text talks about AppAttachReq and AppAttachAns whereas the struct is called AppAttachReqAns. There are similar issues with the other req/ans structures too. BBL: fixed Page 67, Section "5.5.3.1. Request Definition" "application A 16-bit port number. This port number represents the IANA registered port of the protocol that is going to be sent on this connection." What about applications without an IANA registered port number? cj - need to check this was fixed Page 68, Section "5.5.5.2 Response Definition" "response_id: A randomly generated 64-bit response ID. This is used to distinguish Ping responses." Why aren't transaction ID and sender peer-ID enough for distinguishing responses? OPEN Page 71, Section "5.6.2. Reliability for Unreliable Links" This whole section, especially with retransmission, flow control and fragmentation support, adds quite a bit complexity to the link layer implementation. This, and all the NAT traversal complexity, could be avoided by running RELOAD over TCP over NAT traversing connection (such as one created by Teredo or HIP). Page 86, Section "6.4.1.2. Response Definition" "If any type of request tries to access a data kind that the node does not know about, an Error_Unknown_Kind MUST be generated." While the previous section, page 82 says: "Implementations SHOULD reject requests corresponding to unknown kinds unless specifically configured otherwise." cj - fixed to. There know way to do access controll for unkown kinds These two seem to conflict. I would keep the ability to configure an overlay to accept unknown Kinds. Later (e.g., page 89) this seems to be the wording that is used. cj - I think the configuration in kinds allows this type of behavior now Page 99, Section "9.4 Joining" "In order to populate its neighbor table, JP sends a Ping via the bootstrap node directed at Resource-ID n+1 (directly after its own Resource-ID). This allows it to discover its own successor. Call that node p0. It then sends a ping to p0+1 to discover its successor (p1). This process can be repeated to discover as many successors as desired." Could the AP send a copy of its neighbor table (e.g., in an Update message) to the JP? The JP could then initialize its neighbor table using the received entries and there would be no need to send Ping requests. BBL: Possibly could replace the ping to AP with a RouteQueryReq with send_update set to true. Want to survey about this. Page 100, Section "9.5. Routing Attaches" "If a peer is unable to successfully Attach with a peer that should be in its neighborhood, it MUST locate either a TURN server or another peer in the overlay, but not in its neighborhood, through which it can exchange messages with its neighbor peer." (1) The Attach, if ICE was used, should have already included TURN candidates (if any were available), so using TURN here again is likely to fail. What if a peer is still unable to exchange messages with it's should-be-neighbor? (2) What is the method for using "another peer" (but not TURN server) for exchanging messages with the neighbor peer? BBL: I think that paragraph outlived its usefulness Page 103, Section "9.6.3. Receiving Updates" "The UpdateReq defines peers that indicate a neighbor table further away from N than some of its neighbor table. Note that merely receiving peers further away does not demonstrate this, since the update could be from a node far away from N. Rather, the peers would need to bracket N." What is meant by "need to bracket N"? Also, the other sentences of this bullet point seem a bit confusing. BBL: that paragraph was trying to say that if an update was missing a neighbor that N believed was still alive, N should immediately ping the possible missing neighbor. I actually think that's way too reactive and removed it entirely. There are enough other mechanisms for detecting failure and removing a failing peer from the routing table. Page 106, Section "9.7. Route Query" The struct uses "next_id" and the following text "next_peer". BBL: fixed Finally, one more nit: The word "extension" seems to be misspelled as "extention" couple of times in the draft. Cheers, Ari Keranen Jouni Maenpaa _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Begin forwarded message: From: "Bruce Lowekamp" Date: December 10, 2009 2:56:35 PM MST To: Cc: "Cullen Jennings (fluffy)" , "Eric Rescorla" Subject: WGLC comment on routing in draft-ietf-p2psip-base-06 On the issue of the WGLC for the RELOAD base draft, I am concerned that the issue of how routing is done has not been adequately addressed by this draft. I had hoped that draft-jiang-p2psip-relay would make more progress in addressing these issues together with work on the base draft, but that progress has been slow. I don't think we can move forward on the base draft until we address how to resolve these issues and are sure we have an appropriate way forward from the combination of the base draft and that (or any other) extension drafts that emerge to address these issues. Looking at the problem space, there are three types of deployments we need to address 1) overlays where the majority of peers are behind NATs 2) overlays where no peers are behind NAT/firewalls (provider provisioned) 3) overlays where there is an effort to select peers that are not behind NATs, but connectivity is not assured Currently the draft uses SRR, which addresses all of these cases. However, it imposes a significant penalty on cases where SRR isn't needed because there are no NATs in the way, i.e. raw IP addresses could be used. The analysis of these problems presented so far has tended to look at the query-response pattern, but there are actually many applications in a P2P overlay that are not search---where a node's location is known in advance. In that case, there is a clearer argument for having an IP address to directly contact the target node, and being able to use the Node-ID as a backup. Even in a "classic" p2psip-style lookup followed by an AppAttach, SRR-only routing results in at least 4 log(N) traversals through the overlay, whereas if DRR/RP is available, only one is required. With that said, I stand by my earlier comments on the importance of not introducing additional complexity into the base protocol. But we can't stick our heads in the sand, either. I propose we should ensure that the base draft address scenarios (1) and (2) above in efficient ways. In other words, retain SRR, but specify a way of encoding IP & Node ID together in a Destination so that messages can be sent that way. Import flags so that direct routing can be used and address the state issue on intermediate peers. Scenario (3), where it may not be possible to know in advance whether direct or overlay routing is needed, is more complicated and needs to be outside the scope of the base draft. However, we do need to make sure that there is nothing fundamentally flawed in the base protocol that prevents adaptive or variable routing being done as an extension. As has often been discussed in this group, SRR has the advantage that it always works. That means RELOAD needs to support it, but if we expect RELOAD to be adopted in the real world, we need to make sure it allows the optimizations that can (and should) be done across the full range of deployment possibilities. Bruce CJ - TODO Cullen to write up proposal ..... not done yet Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: John Buford Date: December 17, 2009 8:43:42 PM MST To: P2PSIP WG Subject: [P2PSIP] review of draft-ietf-p2psip-base-06.txt Reply-To: buford@samrg.org Here is my review of draft-ietf-p2psip-base-06 that I agreed to provide at IETF76 WG meeting. John TODO - this whole email General ======= 1.4 Structure of the Document Adding a new usage - it would be useful to have a section on this Adding a new overlay algorithm - it would be useful to have a section on this 3.2 Clients How does a peer transition to a client? CJ - Disconnet and reconnect. It has to lose it's data to do this. Did not update the doc to put this - not sure where to put it. 3.3 Routing "Client promotion" - is there client demotion? 4.1.1 Storage Permissions This limits the storage load which another peer can impose, but doesn't address loading due to frequency of write/fetches another peer can impose. 6.3 Access Control Policies How is access control managed for replicated values? It might be helpful for implementers to have a table in an appendix listing the various config parameters and their default / max values, etc, such as: holdown_time 30 sec periodic Update requests 10 min Ping interval 3000 sec Partition detection Max Message size etc. Detailed Comments ================= 1.1 "partly connected graph" -- connected graph subsumes partly connected case cj - fixed 1.2.5 "a packet" => a message cj fixed 3.3 "In all cases, the response to a request needs ..." -- should this be written as a MUST? cj - bruce rewrite remvoed this 4 Application Support Overview "To form direct connections ..." -- why "direct"? cj - this is so you can have higer performance than routing thourgh the overlay 5.1.1 Responsible ID (2nd bullet) "If the message is a response ... the state is reinserted ... first" -- cj - fixed 5.3.2 Forward Header relo_token = 0xc2454c4f, i.e., 'RELO' with msb set in first byte. Shouldn't this be 0xd2454c4f ? (this was commented on the list already in July 2008) cj - changed - did not even think about if this was right transaction_id "unique" - globally unique in the overlay or unique respect to transaction ids generated by this peer? cj - OPEN 5.3.2.2 "This may be one of "peer", ..." -- should be node instead of peer cj - fixed "A DestinationData can be one of three types ... peer A Node-id" -- change "peer" to "node" for consistency with the select statement cj - fixed CJ TODO START HERE 5.3.2.2 bottom p. 44 to top of p. 45 "the encoding MUST include a generation counter designed ..." -- since this is opaque, I don't see how it is "MUST". there could be other ways for nodes to prevent misrouting due to dynamics of the connection table. 5.3.2.3 should the flags be defined as enums in the notation? 5.3.3 message_code 0x8000 .. 0xfffe seems to be omitted 5.3.3.1 Response Codes and Response Errors There seem to be a number of cases where "peer" is used in the text where it should be "node": Error_Forbidden: The requesting _peer_ does not have permission to make this request. Error_Not_Found: The resource or _peer_ cannot be found ... Error_Request_Timeout: ...The requesting _peer_ MAY resend the request at a later time. Also it is not clear whether clients can receive some requests, such as update_req, stat_req, or ping. If so, some of the other Response Error text may need to be changed to refer to "node" instead of "peer". Finally, these definitions appear here but are not in section 13.7: ERror_Response_Too_Large, Error_Config_Too_Old, Error_Config_Too_New. 5.4.1 Topology Plugin Requirements "The length of the Resource-IDs and Node-IDs". -- Doesn't RELOAD fix these to 128 bits? CJ - Fixed. Node-ID are fixed to 128 but Resoruce-IDs are variable length and defined by overlay. (an overlay could define them as varaible lenght too) 5.4.2.5.1 "The two currently defined..." -- strike "two". Also should "peer" be "node" in this section, at least for uptime? If so, this would effect usage of peer in sec. 5.4.2.5.2 as well. BBL: fixed 5.5.3.1 Request Definition should it be "requesting node" instead of "requesting peer"? (also in 5.5.4.1) 5.5.5 Ping what are the operational semantics of Ping to broadcast Node-ID? 5.5.6.2 Config_UpdateReq This could potentially be used to attack the overlay by disabling nodes with erroneous configurations. 5.6.2.1 if we replace N-M with N-M-1, then the bit numberings are 0..N-1 instead of 1..N in the mask, which is the usual convention. 5.6.2.2 "Another would be to implement the _AIMD_ scheme described in Appendix B". 6 Data Storage Protocol storage_time what about a store request whose time equals the time of the current value? lifetime can a usage define a max_lifetime for a kind? 6.3 Access Control Policies what about control of fetch access? 6.4.1.1 Request Definition resource: The _Resource-ID_ to store at. 6.4..4.2 Response Definition "... it SHOULD return a 404 error" -- replace 404 with a RELOAD error code cj - done 9.4 "joining party" -- "joining node" seems clearer and more consistent terminology A statement that the enrollment server assigns the Node-Id could be useful here. "numBitsInNodeId" - this is already fixed to 128, so should we drop the variable use here? CJ - fixed 9.6.3 Receiving Updates "The UpdateReq defines peers that indicate a neighbor table further away from N than some of its neighbor table" -- could be made clearer, e.g., => The UpdateReq contains peers that are further away from N than some of the peers in N's neighbor table. 11. Message Flow Example PPP, PP, NP, NNP acronyms should be defined Some other examples that could be useful: client-peer interaction bootstrap with enrollment server interactions between the node internal architecture elements 12.6.5 Residual Attacks enrollment server is a central point of failure (as implied by 3.6.2) 13.6 Message codes remove_req and remove_ans seem to be no longer used according to 6.4.1.3 14 Acknowledgements - "Michael Chen" is listed twice. CJ -Fixed Spelling/Grammar ================ 1.2 "To clarify the role of the various layer,..." => layers 4.1.3 "on the its" => "on its" cj - fixed 5.3 "introduce new potential" => introduces cj - fixed 5.3.1 "the ability to mechanically (compile)..." -- is a verb missing here, such as generate or translate? cj - fixed 5.5.2.4 "be done be doing" => be done by doing cj - fixed 5.6.2.1 "that the sender to figure" => "that the sender can figure" 5.6.2.2 "no more aggressive then" => "no more aggressive than" also add "(see Appendix C)" after [RFC5348] in this sentence. cj -fixed 9.1 "entreis" => entries cj - fixed 9.6.3 "These Update requests are what ends up" => end up cj - fixed 9.8 extentions => extensions (also several places in 10.1) cj -fixed 10.1 "boradcast" => broadcast cj - fixed 10.3 "[RFC5272])" => "[RFC5272]" cj - fixed 10.3 "HTTP stats codes" => HTTP status codes cj - fixed 12.3 "certificates are signed by _require_ a central enrollment...." -- ? cj - fixed 12.6.3 "Replay is typical prevented ..." => typically cj - fixed Will be resolved by RFC Editor, or before WGLC? ==================================== 1.2.1 "this draft" 2 "are marked with an asterisk" CJ - Fixed 5.3.1 "This presentation is to some extent a placeholder.... We expect this to be a question for the WG to decide." CJ - Fixed 5.6.1 Future Support for HIP "We leave this work as a topic for another draft". Is this to be addressed before WGLC? BBL: Reworded this to include several of the future protocols we would like to support. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: Bruce Lowekamp Date: December 21, 2009 11:06:08 AM MST To: Michael Chen Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Clarify the 2nd bullet of section 5.1.1 Responsible ID Michael, Thanks for the comment. There are some overlay algorithms where a single node/process might have more than one Node-ID, so section 5 should be written to allow that. You're entirely right that it's not consistent right now. Bruce On Sat, Dec 19, 2009 at 8:20 AM, Michael Chen wrote: Hi, In the current -06 draft, the second bullet of 5.1.1 states, "If the entry is a Node-ID which belongs to this node..." A peer may be responsible for a number of Resource-IDs but one and only one Node-ID, its own. The 3rd bullet talks about routing to clients, and 5.1.3 talks about private IDs. Therefore, this 2nd bullet should only be about the top Node-ID in the destination list equals peer's own Node-ID. I suggest change the work "belongs" to "is equal", which matches the wording of the 3rd bullet. o If the entry is a Node-ID which is equal to this node, then ... cj - fixed Also, the first sentence of section 5.1.2 seems to refer to the 3 bullets in section 5.1.1. It that is true, then: "If neither of the other two cases applies, then ..." should be "If neither of the three cases applies, then ..." cj -fixed --Michael _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: Frederic-Philippe Metz Date: December 23, 2009 3:52:21 AM MST To: 孙崇伟 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question on Roles of: Enrollment-, Credential- & Config-Server See comments inline. 2009/12/23 孙崇伟 : 2009/12/21 Frederic-Philippe Metz Hi all, within the context of a centralized enrollement, I have some questions abut rules and functionalities: Section 3.6.1. figures out that for first time setup, the user queries DNS on the overlay name and gets the address of a configuration server. The configuration server in then contacted and a configuration document is provided to the user, having the content of a bootstrap node and an enrollment server. The configuration document is described in section 10.1. Correct so far ? But the user needs a certificate first. So Section 3.6.2 says that the user performs a connection to the enrollment server (with username/pw) to obtain a certificate (with node-id, etc.). Correct so far ? In conflict to that, section 10.2. states that the adress of the enrollment server is found with a DNS query, not with the content of a configuration document and, furthermore, the configuration document is downloaded from enrollment server and the certificate, according to section 10.3, is assigned by an credential-server. Please help me clarifying this conflict. From my understanding by now, there is: 1. initially one server providing a configuration document, including the bootstrap-nodes (and some other things for joining the overlay). The address is resolved by querying the overlay name. in 10.1 （the second latest paragraph of page 110），the draft said："this element represents the address of one of the bootstrap nodes. It has an attribute called "address" that represents the IP address".so it is no need to resolve the address by querying the overlay name. Yes, I meant the server providing the config document. This name is resolved by DNS. 2. The user then queries the service name p2psip_enroll and get the address of an Enrollment server. The user performs a connection to get a certificate (with node-id etc.). This certificate is assigned by the enrollment server. Do you mean both the certification assignment and node-ID assignment are achieved by the enrollment server？right？ Yes. 3. The user then joins the overlay with the given certificate. But this lacks some understanding of a credential-server and/or Rules on the other elements/servers/functionalities. Regards, frederic _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip -- Sun Chongwei Mobile LIfe and New Media Lab Beijing University of Posts and Telecommunications _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: "JeffreyHo" Date: January 22, 2010 12:11:29 AM MST To: Cc: 沈婉婉shen Subject: [P2PSIP] [p2psip] asking about the lifetime of the stored data and refreshing mechanism Dear all, I would like to ask a question about the lifetime of the stored data and refresh behavior sequentially. The 'lifetime' field of RELOAD's StoredData structure specifies the validity period for the data, that is the expiration time in the overlay. So if the data owner wants to keep the data previously stored still validity, the refresh behavior is necessary, just like the registration refresh in SIP Concept. Based on the StoredData structure if we want to do refresh for the data, it seems that we can just send StoreReq with the content of data again to renew the 'lifetime' value. Am I right? If so, this seems in the wasted way. Can we have an efficient way to do the refresh behavior, for example just bringing the lifetime value to be renewed for the data, not going along with the data content? It could be like the refresh mechanism of SIP registration or presence publication. Should we go this way? Thanks a lot. BR, Jeffrey BBL: responded on list 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀 此信件。This email may conqtain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: jc Date: January 16, 2010 10:34:27 AM MST To: Michael Chen Cc: Cullen Jennings , P2PSIP WG Subject: Re: [P2PSIP] What is SipRegistrationData.contact_prefs? On Jan 16, 2010, at 11:51 AM, Michael Chen wrote: Cullen, There are some related problems for the sip-03 draft: 1. When multiple destinations are specified in the structure, the draft is not clear how the contact preference for each destination is specified in the single contac_prefs, e.g. comma separated or space separated? does it allow white spaces? 2. GRUUs can also contain a destination list, but there is no mechanism to specify contact preferences. 3. The draft allow a single SIP registration kind to carry multiple dictionary entries (multiple device for the same AOR). There is no mechanism to specify contact preference across dictionary entries. Perhaps the draft can simply mandate that the order of the multi-entry destination list implies their call preference, which means the owner of the registration must pre-sort the list before storing it. This can eliminate the contact preference field and have a unified way that also covers GRUU. Who would the "owner" of the registration be? For instance with my implementation my iphone registers as a peer, a few desktops as peers and nodes all under the same AOR and I Join a single other AOR as a Callee to test. All of my devices ring and receive chat messages however again who actually owns the registration? Nobody, the certificate belonging to the AOR owns the registration correct? Thanks --Michael Cullen Jennings wrote: Just wanted to say yep, this is what we meant. On Jan 6, 2010, at 8:53 PM, Michael Chen wrote: Found it. RFC3261 Section 10.2.1.2. Suggest quoting just that so it reads: SipRegistration.SipRegistrationData.contact_prefs o If the registration is of type "sip_registration_route", then the contents are an opaque string containing the callee's contact preferences (as defined in RFC3261 Section 10.2.1.2) and a destination list for the peer. I assume the actual value of the contact preference will be a string like "0.7" or "0.1", etc. Thanks --Michael -------- Original Message -------- Subject: What is SipRegistrationData.contact_prefs? From: "Michael Chen" Date: Tue, January 05, 2010 4:59 pm To: p2psip@ietf.org Hi, In the current draft-ietf-p2psip-sip-03, there is no definition for field: SipRegistration.SipRegistrationData.contact_prefs o If the registration is of type "sip_registration_route", then the contents are an opaque string containing the callee's contact preferences and a destination list for the peer. What is contact preferences? Thanks --Michael _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: "Michael Chen" Date: December 7, 2009 11:02:29 PM MST To: p2psip@ietf.org Subject: [P2PSIP] Interleaved two-phase admit Hi, Draft-06 section 9.4 describes how a peer (JP) join the overlay. From the admitting peer (AP) point of view, it is a two-phase process: Phase-1: AP receives the JOIN request from JP and replies. Then AP send a series of STORE to to JP to forward resources that will belong to JP. Phase-2: When the last STORE from AP to JP is acknowledged by JP, AP can now internally take JP as its predecessor and send a UPDATE indicates just that. The problem is what if two peers X and Y happen to join the overlay via AP at the same time, and their two-phase admit on the AP side interleaved like this: Phase-1-for-X Phase-1-for-Y Phase-2-for-Y Phase-2-for-X If their Chord ring positions are X < Y < AP, Y will join successfully, but AP might have incorrectly forwarded to X some of the resources that should have belong to Y. Also, at Phase-2-for-X, AP will discover that X is no longer AP's immediate predecessor (Y is), so AP should not admit X at all. What should AP do? If AP still send the UPDATE to X which shows Y is now X's immediate sucessor, then X should regard the JOIN failed. X will then try to attach to Y and JOIN via Y. Have I answer my own question? :) --Michael _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: "David A. Bryan" Date: December 7, 2009 10:57:54 AM MST To: P2PSIP WG Subject: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC (Just to be clear, everything here is being sent by me as an individual. I’ve asked Brian to make any decisions about discussions of these concerns that might arise on list or in meetings.) So, with a new baby and lots of work outside the IETF, I’ve been very busy, and haven’t had a chance to make a full, complete formal review of the newest (-06) revision, but I have identified some ongoing major (design/architectural) concerns, some minor concerns (questions, layout, etc.) and some nits I noticed in my quick read of -06 that I’d like to raise/share now. I may have more if/when I get time to do a full review. Overall, I think the document is moving along, and getting much better. I feel it still needs some more editorial work, some clarifications, and more group discussion on a few critical design decisions, and I’d like to see a few more full reviews such as the one Jouni did before I would be able to personally support moving it through WGLC, but I think it is getting closer. Major concerns: Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts I’ve raised this issue before, but I’m hoping that now that people have had a bit more time to think about all the use cases, see what it means in the real world, etc., there might be a bit more support for modifying the requirement for TLS/DTLS. TLS/DTLS makes sense in some cases, but if we are expecting RELOAD to be reusable, it is clear to me that it does not make sense in all cases. It was familiar to the editors, and well understood, so it made sense as a proposal, but I disagree with it being the mandatory/only solution. I am not advocating we allow unsecured system. There needs to be a way to do that for development/debugging, but you can do that with a null cipher, so that concern is addressed. Instead my concerns are two-fold: 1) TLS/DTLS is too heavy for query-response systems using direct-response routing. 2) There are applications that may want to secure at a different level or using a different technology. First, looking at DTLS for query-response systems using direct routing. A bit of background: Clearly, RELOAD should work for query-response systems, where the only use of the DHT is to obtain a small item of information (e.g. obtaining a registration or a certificate). Similarly, while there has been discussion about whether the current individual draft is the appropriate mechanism, the group hummed in Minneapolis to include direct routing in the protocol, and in SF the hum was repeated, with strong consensus to include it as an extension and ensure base draft doesn’t preclude it. Establishing a TLS/DTLS connection is a very heavy way to establish a connection between two peers for a simple response, particularly if using direct where the connection is used only to convey that response. (7 messages for DTLS [1]) With recursive response, it makes sense, since the connection is persistent, but a lighter mechanism (for example, including the requestors public cert in the request, and having the responder encrypt the reply) is far more appropriate for a direct routed response. The current draft mandates TLS/DTLS and only TLS/DTLS, leading to an artificially high cost for direct response routing. Based on my work with potential real-world users of P2PSIP going back almost 4 years, request-response is a very likely scenario. While the TLS-PSK/TLS-SRP stuff helps here, other mechanisms would still be more efficient. Similarly, we should allow alternate mechanisms: Even if one is using the recursive response approach for routing, there may be other architectures. A system of persistent peers (for example provisioned set-top boxes using reload to share information) may have ISP assigned IDs, and persistent peers connected to one another, and use hardware based encryption, VPNs, etc. between the peers. There are many ways to encrypt a connection, and mandating one and only one seems inappropriate. A better design is to provide a mechanism in the draft for an alternate encryption technique, recommend DTLS, provide information, and require some encryption be used. While someone could choose to build without encryption, the argument seems weak. They could also just ignore the requirement in the first place. In my opinion, we are more likely to have problems later (extensions that will have to modify the original draft to use a different security mechanism, deployments that are “almost” RELOAD but with different security etc.) if we proceed with the current draft’s approach. [1] Modadugu, N., Rescorla, E., "The Design and Implementation of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004. Concern 2: Alternate Mechanism Needed for Attach-Lite I indicated above why TLS/DTLS was overly expensive, particularly for direct response. Direct response is particularly likely to be used in closed environments (server farms using P2PSIP to distribute information, managed networks, ad-hoc, etc.), and these same deployments are among the most likely to use Attach-lite, as they may want to avoid full ICE. However, in section 5.5.2.3, TLS connectivity checks are required as the mechanism to check rechability. This is a great shortcut when TLS/DTLS is used, but an alternate mechanism needs to exist for systems opting not to use TLS/DTLS. BBL: We're going to update some text allowing other options beside (D)TLS. One of the requirements needs to be that it specifies how to do this. Concern 3: TURN server usage/location not proved “not harmful” Section 8 of the draft defines a TURN server usage, which relies on having an accurate turnDensity defined. As the draft itself notes, if the density is too high, the process of finding a server becomes very expensive. In the Hiroshima meeting, the editors asserted that they had run experiments that showed it was “ok and worked fine”, but declined to provide or share any results. While I understand why (it's a pain to document this kind of thing), this is a critical part of the deployment, and the suggested algorithm and approach is not, as far as know, deployed or documented/analyzed anywhere in the P2P literature. In the absence of some reference or an analysis or simulation shared with the group, I’m concerned about the potential impact this will have on deployments, and don't think we should bless something this unproven. I would recommend either some study or analysis is presented by the editors supporting that this works and isn't too bad when you get it wrong, or we move this to an extension (or merge it in with the ongoing work on service discovery) Haibin Song suggested something similar onlist: http://www.ietf.org/mail-archive/web/p2psip/current/msg05278.html Concern 4: Fixed Length (128 bit) Peer-ids Limit Reuse and are Unnecessary For some reason, the draft mandates 128 bit peer-ids. As far as I can see, there is no good reason for this (it doesn’t even appear resource IDs are limited to the same space), and I don't recall this ever being discussed by the WG. In fact, this seems like a bad idea from a reuse and extensibility perspective. Many other DHTs existing today use other spaces (for example original Chord's 160 bit), and reuse of existing code should be a priority. (for example being able to take an existing, debugged DHT code and plug it into RELOAD) I understand there is a routing efficiency argument to be made here for fixed length fields, so this is a good discussion for the list, but my opinion is that the small performance improvement isn't worth the cost in terms of flexibility and protocol reuse, and that peer-id’s should be variable length. Concern 5: The Private ID concept should not be in the base draft (breaks direct response routing and relay peer routing) While the idea of the Private ID concept (5.1.3) could break routing other than recursive response, if there are concerns about state being maintained. The current proposal is very minimal (a few lines), and doesn’t specify what happens if a message with a different response routing type. If the response will be routed directly or via a relay, what happens to that state? It would be better to place this optimization into an extension. That way, an overlay using a different routing technique can prohibit the optimization, or at least the extension can think through the proper way to handle expiring the state, etc. Including in the base draft causes problems with direct response support, which the group has mandated the draft support. Concern 6: Compressed destinations in via-list should not be in the base draft In section 5.3.2.2 there is discussion of via-list compression and adding an opaque field to represent the list only valid for that peer. The same concerns I have in Concern 5 apply here. This should also be an extension. Concern 7: Document shouldn't specify a particular bootstrap configuration mechanism 3.6.1 describes (in a very cursory way) a specific configuration mechanism for obtaining configuration. There are many ways to handle provisioning, and I don't recall the group ever discussing and blessing this particular mechanism. In fact, I recall there was discussion that this should be out of the scope of this document. Minor Concerns / Questions: Minor Concern 1: In 5.1.1, first bullet, why is this silently dropped? Might make sense, but not clear from the text. Can you explain? Minor Concern 2: In 5.2.1, where and why did 3 seconds and 4 times come from? Can we cite to provide a reason for this? Minor Concern 3: In 5.3.2.1 there is very little explanation about why a Config_Update needs to be accepted. Have we thought through the possible attack vectors of this? Can this text be clarified? Nits: Nit 1: The document needs to be spell-checked. While most from the last version are fixed, I saw a few just on a casual read that should be fixed before we move forward. (perfom at the end of 3.5, theAIMD in Appendix B, protcol in the IANA port registrations, imporvements in the acknowledgements, etc.) Nit 2: In 5.3.2.2 the structure field is destination_data, but the descriptive text is destination_value. They should agree. Similarly for node/peer as a destination type. cj - fixed Nit 3: In 1.2, the description of storage component says “It talks directly to the Topology Plugin to manage data replication” and topology plugin component description says “It uses the Message Transport component to send and receive overlay management messages, to the Storage component to manage data replication”. This seems a bit unclear and circular for the overall architecture description. Nit 4: In 1.2.5, second paragraph, it is described as “fairly generic”. That seems like kind of a meaningless term. cj - fixed Nit 5: In terminology, "host" is used to describe client and peer. Does that make sense? There is not a one-to-one host-peer relationship. Thanks, David (as individual) _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: Eric Rescorla Date: December 27, 2009 10:10:37 AM MST To: Michael Chen Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc. On Sun, Dec 27, 2009 at 8:48 AM, Michael Chen wrote: Eric, Thanks for pointing out the replica StoreReq paragraph in 6.4.1.1, but I still have 2 questions: 1. What is the via and destination list look like for a replica StoreReq? I believe StoreReq (replica or not) should not be routed, thus the via list should be empty and the destination list should contain a lone entry of the receiving peer (i.e. the successor of the responsible peer). If this is true, the draft should enforce it. I had assumed that this question was implementation and overlay dependent. Say for the sake of argument that a node can't establish direct connections with all the replica set, then it would have to route replica stores, no? What do you think would be the advantage of adding this restriction? 2. What are the use cases for the other 3 requests where the resource ID in the message differ from the destination list? FetchReq.resource StatReq.resource Both of these can be used by the storing node to explicitly address replica nodes; see 6.4.1.2: The list of other peers at which the data was/will be replicated. In overlays and applications where the responsible peer is intended to store redundant copies, this allows the storing peer to independently verify that the replicas have in fact been stored. It does this verification by using the Stat method. Note that the storing peer is not require to perform this verification. The text probably should say "Stat or Fetch" methods. FindReq.resource Replica is not involved in these cases. These messages are only meant to be answered by the responsible peer. If this is true, these resource IDs should be removed from the message. Well, the idea with Find is to allow you to ask a specific node a question, so it's expected to be addressed to a node directly, not a resourceid, thus requiring the resourceid in the request. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: "Michael Chen" Date: January 5, 2010 5:59:19 PM MST To: p2psip@ietf.org Subject: [P2PSIP] What is SipRegistrationData.contact_prefs? Hi, In the current draft-ietf-p2psip-sip-03, there is no definition for field: SipRegistration.SipRegistrationData.contact_prefs o If the registration is of type "sip_registration_route", then the contents are an opaque string containing the callee's contact preferences and a destination list for the peer. What is contact preferences? Thanks --Michael _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: Jouni Mäenpää Date: December 21, 2009 6:34:25 AM MST To: "p2psip@ietf.org" Subject: [P2PSIP] RELOAD overlay configuration document Hi, One question about the "bootstrap-node" element in the RELOAD overlay configuration document. In the example configuration document included in the RELOAD base draft, the bootstrap-node element has the following contents: 192.0.0.1:5678 My question is that should the element also specify whether the bootstrap node should be contacted using DTLS or TLS? In that case, the element could perhaps look as follows:
192.0.0.1
5678 TLS Or is the assumption that the bootstrap node uses the same port for both TLS and DTLS? The above format would also make the bootstrap-node element more extensible. Cheers, Jouni _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Begin forwarded message: From: Cullen Jennings Date: January 13, 2010 1:05:11 PM MST To: Sun Chongwei Cc: BeckW@telekom.de, p2psip@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-06; message flow examples, leaving NP = Next Peer NNP i= next next peer JP Joining peer AP admitting peer PP previos peer PPP previos previos peer BP bootstrap peer On Jan 7, 2010, at 5:29 AM, Sun Chongwei wrote: What is NP short for? I can not find its full name in the draft CJ - Fixed _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html