Hi Roni, sure, please go ahead work within the WG on this change and let me know when the draft is ready.
Cheers, Gonzalo On 12/07/2013 10:36 AM, Roni Even wrote: > Hi, > After further review we will also add to the configuration document a new > element that will specify the usage of DRR or RPR. > I assume this is a bigger change and may require the WG to look at it > Roni > >> -----Original Message----- >> From: Roni Even [mailto:[email protected]] >> Sent: 09 July, 2013 2:06 PM >> To: 'Gonzalo Camarillo' >> Cc: 'P2PSIP Mailing List' >> Subject: RE: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr >> >> Hi Gonzalo, >> I will try to summarize what is the current recommendation in the document >> and try to make it clearer. >> >> 1. DRR is always available with a fall back to SRR. >> 2. Section 6.2 of the base draft says " An overlay MAY be configured to > use >> alternative routing algorithms, and alternative routing algorithms >> MAY be selected on a per-message basis. I.e., a node in an overlay > which >> supports SRR and some other routing algorithm called XXX might >> use SRR some of the time and XXX some of the time." This is the > preferred >> way when trying to use DRR based on the overlay configuration and having >> DRR as preferred mode. >> 3. The administrator when defining the configuration and not having enough >> knowledge (this is not a managed / private network) about the usage of DRR >> but still likes to try it may configure DRR. The sender may try using DRR > but >> fall back to SRR if fails as explained in section 6.4 of DRR draft. >> >> 4. section 4.2 provides guidance about how to decide of to continue using >> DRR or just use SRR for all cases. Still the decision to try DRR in the > first place >> will be based on configuration. >> >> 5. We can add text that say that we discourage using DRR in the open >> Internet or if the administrator does not feel he have enough information >> about the overlay network topology. >> >> 6. The application should use the configuration to decide if to try DRR > before >> SRR and fall back to SRR if fails >> >> 7. using DRR by a node is not recommended per specific connection. The >> application should use DRR based on success rate and should give up DRR if >> the success rate falls for all it connections. >> >> 8. The document will emphasis that the decision to continue with DRR is > not >> per a specific case but based on the node total success rate. >> >> Roni >> >> >> >>> -----Original Message----- >>> From: Gonzalo Camarillo [mailto:[email protected]] >>> Sent: 24 June, 2013 1:08 PM >>> To: Roni Even >>> Cc: 'P2PSIP Mailing List' >>> Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr >>> >>> Hi Roni, >>> >>> sure, the purpose of this document is not to create a new ICE type of >>> mechanism, I agree. Nevertheless, the document needs to be clear about >>> the options implementers and administrators have. That is, what is >>> likely to work, what is not likely to work, special cases (e.g., when >>> two nodes are in the same private address space), etc. That is the >>> type of (brief) discussion I would like to see in the draft. When it >>> comes to the definition of the mechanisms themselves, I am OK with them >> as they are. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> On 24/06/2013 11:58 AM, Roni Even wrote: >>>> Hi Gonzalo, >>>> During the WG discussion we were asked to have in the main body just >>>> the case of manage networks and leave in the informational appendix >>>> A some informational text about finding routable addresses since it >>>> was clear that there is no guarantee that it will work. I do not >>>> think that it is the purpose of this document to discuss the whole >>>> topic of finding routable addresses, we are just pointing at available >> options. >>>> The idea is that there is always a fall back to SRR Roni >>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo [mailto:[email protected]] >>>>> Sent: 24 June, 2013 11:11 AM >>>>> To: Roni Even >>>>> Cc: 'P2PSIP Mailing List' >>>>> Subject: Re: [P2PSIP] UNSAF considerations and >>>>> draft-ietf-p2psip-drr >>>>> >>>>> Hi Roni, >>>>> >>>>> I think the draft should discuss in more detail how a node makes >>>>> the >>>> decision >>>>> of attempting to use DRR and what are the trade-offs. The case of >>>>> closed >>>> or >>>>> managed networks is clear. The draft can mention that an >>>>> administrator simply configures nodes to use DRR because the >>>>> administrator knows, somehow, that it will work fine. >>>>> >>>>> In open networks, the draft should discuss the trial and error >>>>> system >>>> being >>>>> proposed. For example, a node without a public IP address may be >>>>> able to communicate directly with a node in the same non-public >>>>> address >>> space. >>>>> That case is not covered by the discussions about UNSAF mechanisms. >>>>> The whole point about developing ICE was that UNSAF mechanisms do >>> not >>>>> work in many situations. >>>>> >>>>> In short, this is an important interoperability issue because it >>>>> relates >>>> to when >>>>> a node should use one mechanism or another. Therefore, the draft >>>>> should discuss all the implications of the proposed mechanism > carefully. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> >>>>> >>>>> On 23/06/2013 6:28 PM, Roni Even wrote: >>>>>> Hi Gonzalo, >>>>>> Thanks for point out to RFC3424. >>>>>> How about adding to the following sentence an informative >>>>>> reference to RFC3424. Note that appendix A is not creating an >>>>>> UNSAF proposal but just mentions some methods for informational >> purpose. >>>>>> >>>>>> Suggest adding to "Note that there is no foolproof way to >>>>>> determine if a peer is publically reachable, other than via >>>>>> out-of-band mechanisms." to >>>>>> >>>>>> "Note that there is no foolproof way to determine if a peer is >>>>>> publically reachable, other than via out-of-band mechanisms. For >>>>>> discussion about issues with address evaluation also see UNSAF >>>> [RFC3424]" >>>>>> >>>>>> I am not sure if it adds much information but it may be good to >>>>>> have this reference >>>>>> >>>>>> Roni Even >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: [email protected] [mailto:[email protected]] >> On >>>>>>> Behalf Of Gonzalo Camarillo >>>>>>> Sent: 17 June, 2013 3:02 PM >>>>>>> To: P2PSIP Mailing List >>>>>>> Subject: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> Appendix A of the following draft describes how a node can obtain >>>>>>> IP addresses on which it may be reached: >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-ietf-p2psip-drr-07#appendix-A >>>>>>> >>>>>>> Have you taken into account the UNSAF considerations? >>>>>>> >>>>>>> http://tools.ietf.org/html/rfc3424 >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Gonzalo >>>>>>> _______________________________________________ >>>>>>> P2PSIP mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>> >>>> > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
