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

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Jul 2013 14:05:46 +0300

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-masked]]
> 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-masked]]
> >> 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-masked] [mailto:[email-masked]] 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-masked]
> >>>> https://www.ietf.org/mailman/listinfo/p2psip
> >>>
> >

---

From: "Roni Even" <[email-masked]>
Date: Fri, 12 Jul 2013 10:36:13 +0300

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

> From: Roni Even [mailto:[email-masked]]
> Sent: 09 July, 2013 2:06 PM
> To: 'Gonzalo Camarillo'
> Subject: RE: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr
> 
> Hi Gonzalo,
which
> supports SRR and some other routing algorithm called XXX might
preferred
> way when trying to use DRR based on the overlay configuration and having
> DRR as preferred mode.
but
> fall back to SRR if fails as explained in section 6.4 of DRR draft.
> 
first place
> will be based on configuration.
> 
before
> SRR and fall back to SRR if fails
> 
> > 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
> >
> > > 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.
> > >> 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.
carefully.
> > >>> 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
> > >>>
> > >>> I am not sure if it adds much information but it may be good to
> > >>> have this reference
> > >>>
> > >>> Roni Even
> > >>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 12 Jul 2013 14:29:37 +0300

Hi Roni,

sure, please go ahead work within the WG on this change and let me know
when the draft is ready.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 19 Jul 2013 14:36:17 +0300

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

---

From: "Roni Even" <[email-masked]>
Date: Fri, 19 Jul 2013 15:39:40 +0300

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

> Sent: 19 July, 2013 2:36 PM
> To: 'P2PSIP Mailing List'
> Cc: Roni Even
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 :-)
> 
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.
> > sure, please go ahead work within the WG on this change and let me
> > know when the draft is ready.
> >
> > Cheers,
> >
> > Gonzalo
> >
> >> After further review we will also add to the configuration document a
> >> new element that will specify the usage of DRR or RPR.
> >>> I will try to summarize what is the current recommendation in the
> >>> document and try to make  it clearer.
> >>>
> >>> 2. Section 6.2  of the base draft says " An overlay MAY be
> >>> configured to
> >> use
> >>> way when trying to use DRR based on the overlay configuration and
> >>> 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
> >>> 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
> >>> Internet or if the administrator does not feel he have enough
> >>> information about the overlay network topology.
> >>>
> >>> 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
> >>>> 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
> >>>>
> >>>>> 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.
> >>>>>>>> From: [email-masked] [mailto:p2psip-
> [email-masked]]
> >>> On
> >>>>>>>> Appendix A of the following draft describes how a node can
> >>>>>>>> obtain IP addresses on which it may be reached:
> >>>>>>>>