Hi Gonzalo, I will add the text you suggested, I just think that the main body talks about falling back to SRR and says that using the DRR in open Internet is not recommended Roni
> -----Original Message----- > From: Gonzalo Camarillo [mailto:[email protected]] > Sent: 19 July, 2013 2:36 PM > To: 'P2PSIP Mailing List' > Cc: Roni Even > Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr > > Hi, > > I have just read version 08 of this draft. I had asked for a brief discussion > about the UNSAF considerations. This version contains a single sentence > referring to the to the UNSAF RFC without any other discussion. I am afraid > that it too brief a discussion :-) > > Note that the UNSAF RFC states that it is not acceptable to define UNSAF > mechanisms unless certain conditions are met. Please, add a brief discussion > explaining why it is OK to use an UNSAF mechanism like the one described in > this draft in open networks. > > The discussion should explain how this mechanism is similar to ICE in the > sense that addresses that are obtained via the INSAF mechanism are simply > tried to see if they work, and if they don't, we always have a fall back > mechanism that will work. In essence, we are just probing to see what works > and what doesn't. > > Thanks, > > Gonzalo > > > > On 12/07/2013 2:29 PM, Gonzalo Camarillo wrote: > > 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:p2psip- > [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 > > > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
