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
