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

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

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:[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
> > >>>
> > >