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

[Gonzalo Camarillo <[e-mail]>]

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