Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr
"Roni Even" <ron.even.tlv@gmail.com> Fri, 12 July 2013 07:38 UTC
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6876421F9AC5 for <p2psip@ietfa.amsl.com>; Fri, 12 Jul 2013 00:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.048
X-Spam-Level:
X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blMr15sQwA1E for <p2psip@ietfa.amsl.com>; Fri, 12 Jul 2013 00:38:00 -0700 (PDT)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 143AE21F9A51 for <p2psip@ietf.org>; Fri, 12 Jul 2013 00:37:59 -0700 (PDT)
Received: by mail-wg0-f53.google.com with SMTP id y10so7998018wgg.32 for <p2psip@ietf.org>; Fri, 12 Jul 2013 00:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=CfttSnNwZA5y76X5ydwDyrU23aVrgAgThLoV4qdWDpw=; b=oYgzDfe5v0f1KHvG0VFvB3IOrsyUgqj2U+YsQKyovNyAJtP+4zynByApv64ZPRcLV9 nOLfJlrYFOXC5S4D/cwQBAnb8cxMZL2Vjgb2Pfcd3RLnBiTEedo7pg2WLICq4bhjCoHf 5heoQ0v3I2tfw42G/51jboP7CVegrI6/aaCQRjbhZ0URzyfo1/LiC+nyE3zAhKVh6D24 z/sIGVn2Fogro0gsMjIyTOCP3rHIuRzL1gvBobuOIpt6xgDxm3civlI4Vn4LKzjv5wGs L0H3o61hIVee+KZGis0ImjWIQg0XIdIpbaBj4TiZ45FZT94Nxw5qJgRCmxpQsgqDHbDI hvng==
X-Received: by 10.180.82.196 with SMTP id k4mr946193wiy.0.1373614676720; Fri, 12 Jul 2013 00:37:56 -0700 (PDT)
Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id p1sm1485158wix.9.2013.07.12.00.37.54 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jul 2013 00:37:56 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Gonzalo Camarillo' <Gonzalo.Camarillo@ericsson.com>
References: <51BEFAC4.3050302@ericsson.com> <004b01ce7026$55930650$00b912f0$@gmail.com> <51C7FF29.9070901@ericsson.com> <008401ce70b8$fd5ff220$f81fd660$@gmail.com> <51C81A7C.7030404@ericsson.com>
In-Reply-To:
Date: Fri, 12 Jul 2013 10:36:13 +0300
Message-ID: <00c201ce7ed2$7da2b450$78e81cf0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIYXbTplAIujxtiKDGzj7ujRdtuuAJhEpsoAcEy7MQBRFehIwIiOaF7mIwfgZCABILwkA==
Content-Language: en-us
Cc: 'P2PSIP Mailing List' <p2psip@ietf.org>
Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2013 07:38:01 -0000
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:ron.even.tlv@gmail.com] > 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:Gonzalo.Camarillo@ericsson.com] > > 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:Gonzalo.Camarillo@ericsson.com] > > >> 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: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] > 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 > > >>>> P2PSIP@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/p2psip > > >>> > > >
- [P2PSIP] UNSAF considerations and draft-ietf-p2ps… Gonzalo Camarillo
- Re: [P2PSIP] UNSAF considerations and draft-ietf-… Roni Even
- Re: [P2PSIP] UNSAF considerations and draft-ietf-… Gonzalo Camarillo
- Re: [P2PSIP] UNSAF considerations and draft-ietf-… Roni Even
- Re: [P2PSIP] UNSAF considerations and draft-ietf-… Gonzalo Camarillo
- Re: [P2PSIP] UNSAF considerations and draft-ietf-… Roni Even
- Re: [P2PSIP] UNSAF considerations and draft-ietf-… Roni Even
- Re: [P2PSIP] UNSAF considerations and draft-ietf-… Gonzalo Camarillo
- Re: [P2PSIP] UNSAF considerations and draft-ietf-… Gonzalo Camarillo
- Re: [P2PSIP] UNSAF considerations and draft-ietf-… Roni Even