Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr

["Roni Even" <[e-mail]>]

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:[e-mail]]
> 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:[e-mail]]
> >>> 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:[e-mail]]
> >>>> 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:[e-mail]]
> >>>>>> 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: [e-mail] [mailto:p2psip-
> [e-mail]]
> >>> 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
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/p2psip
> >>>>>>>
> >>>>>
> >>
> >
> > _______________________________________________
> > P2PSIP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/p2psip
> >
> >