From melodysong@huawei.com Wed Aug 5 02:24:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA78128C55C for ; Wed, 5 Aug 2009 02:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.162 X-Spam-Level: X-Spam-Status: No, score=0.162 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHX3uOSP4TU6 for ; Wed, 5 Aug 2009 02:24:56 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 715BA28C46A for ; Wed, 5 Aug 2009 02:24:22 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNW00KOYCIX12@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 05 Aug 2009 17:18:33 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNW00D0ZCIWGE@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 05 Aug 2009 17:18:32 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNW007G9CIWZY@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 05 Aug 2009 17:18:32 +0800 (CST) Date: Wed, 05 Aug 2009 17:18:32 +0800 From: Song Haibin In-reply-to: To: 'Bruce Lowekamp' , p2psip@ietf.org Message-id: <00c001ca15ad$b3fd2e00$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoPYSiM8do61+GpRr2gYvlYR1FCpwGSya6g Subject: Re: [P2PSIP] comments on draft-matuszewski-p2psip-security-requirements-05 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 09:24:56 -0000 Hi Bruce, Thanks for your comments. See inline. >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >On Behalf Of Bruce Lowekamp >Sent: Tuesday, July 28, 2009 4:55 PM >To: p2psip@ietf.org >Subject: [P2PSIP] comments on >draft-matuszewski-p2psip-security-requirements-05 > >I thought this revision of the document was a significant >improvement and thank the authors for spending so much time >reorganizing and rewriting pieces of it. > >I liked the general discussion of issues. When it got into >the RELOAD-specific part I was less certain how to apply it. >It might be helpful if the draft uses RELOAD to refer to the >specific protocol and P2PSIP or even another term to discuss >general p2p communications system issues to avoid confusion. > Good suggestion. It will be done in the next revision. >This draft appears to have the wrong IPR declaration at the beginning. > Since it incorporates material that was contributed prior to >11/2008, it can't use this declaration. > We will correct it. >I still find the term "overlay base" confusing. > Bruce, here is the definition for P2P Overlay Base in this document. Could you please tell me what make you confused? P2P Overlay Base: A P2P Overlay Base includes all the Peers that participate in the p2p overlay. The P2P Overlay Base provides distributed storage and routing services to both peers and clients. >Again, depending on whether parts of the discussion are >intended to be general about p2p telecom or specific to RELOAD >and work in the p2psip working group, some of the discussion >and terms need to be updated. >For example, there is no separate protocol for peer vs client >communication (even though there is discussion of whether >additional methods are needed for client operation, I don't >believe anyone is arguing for separate protocols at this point). > I just noticed that. Sorry for our negligence when updating this document. We will correct it for the next version. Thanks, Haibin >Bruce >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > From Even.roni@huawei.com Thu Aug 13 00:25:05 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291523A6A3F for ; Thu, 13 Aug 2009 00:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQo0t66TRMHe for ; Thu, 13 Aug 2009 00:25:04 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id EA3AA3A69C0 for ; Thu, 13 Aug 2009 00:25:03 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOA00JDNZL2JC@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 13 Aug 2009 15:03:03 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOA00IQJZL21N@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 13 Aug 2009 15:03:02 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-140-221.red.bezeqint.net [79.177.140.221]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOA009U3ZKSG3@szxml01-in.huawei.com>; Thu, 13 Aug 2009 15:03:02 +0800 (CST) Date: Thu, 13 Aug 2009 10:00:23 +0300 From: Roni Even To: p2psip@ietf.org Message-id: <001201ca1be3$c2486150$46d923f0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_o1b5iX7FtucylT839Hpq3g)" Content-language: en-us Thread-index: Acob47qeFEA4v6sFRJaQWDAN7EWpUg== Subject: [P2PSIP] Add route log option to diagnostic draft for collecting diagnostic information X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 07:25:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_o1b5iX7FtucylT839Hpq3g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Route logging was removed entirely from the 03 base draft, due to the problems it causes with fragmentation and message length. There was a discussion on the mailing list to use it for the diagnostics. Currently the diagnostic draft suggests using the Path Track method to retrieve diagnostic information. In order to collect diagnostic information from all peers in a route the requesting peer must send a separate request to each peer in the route. In past versions there was an option for the requesting peer to send one request and each peer in the route would respond with his diagnostic information, this option was removed due to security considerations (message explosions attack) and we were looking for another method to optimize the diagnostic information reporting. I suggest adding a route log option to the Inspect method. This will enable a requesting peer to send one request and collect diagnostic information from the peers in the route. In order to limit the message length and prevent fragmentation we can specify a fixed subset of diagnostic information that will be reported when route log is requested. The full diagnostics will still be collected using the Path Track method. Does this looks like a reasonable optimization for collecting the diagnostic information Thanks Roni Even --Boundary_(ID_o1b5iX7FtucylT839Hpq3g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

Route logging was removed entirely from the 03 base draft, due to the problems it causes with fragmentation and message length. There was a discussion  on the mailing list to use it for the diagnostics.

 

Currently the diagnostic draft suggests using the Path Track method to retrieve diagnostic information. In order to collect diagnostic information from all peers in a route the requesting peer must send a separate request to each peer in the route.  

 

In past versions there was an option for the requesting peer to send one request and each peer in the route would respond with his diagnostic information, this option was removed due to security considerations (message explosions attack) and we were looking for another method to optimize the diagnostic information reporting.

 

I suggest adding a route log option to the Inspect method. This will enable a requesting peer to send one request and collect diagnostic information from the peers in the route. In order to limit the message length and prevent fragmentation we can specify a fixed subset of diagnostic information that will be reported when route log is requested. The full diagnostics will still be collected using the Path Track method.

 

Does this looks  like a reasonable optimization for collecting the diagnostic information

 

Thanks

Roni Even

--Boundary_(ID_o1b5iX7FtucylT839Hpq3g)-- From bbl@lowekamp.net Sun Aug 16 21:26:39 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671FF3A6CBE for ; Sun, 16 Aug 2009 21:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd4Jpq-a1zff for ; Sun, 16 Aug 2009 21:26:38 -0700 (PDT) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by core3.amsl.com (Postfix) with ESMTP id 5DEFC3A6B8D for ; Sun, 16 Aug 2009 21:26:38 -0700 (PDT) Received: by bwz2 with SMTP id 2so1982238bwz.43 for ; Sun, 16 Aug 2009 21:26:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.36 with SMTP id d36mr1127336mun.104.1250483198895; Sun, 16 Aug 2009 21:26:38 -0700 (PDT) In-Reply-To: <001201ca1be3$c2486150$46d923f0$%roni@huawei.com> References: <001201ca1be3$c2486150$46d923f0$%roni@huawei.com> Date: Mon, 17 Aug 2009 00:26:38 -0400 Message-ID: From: Bruce Lowekamp To: Roni Even Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip Subject: Re: [P2PSIP] Add route log option to diagnostic draft for collecting diagnostic information X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 04:26:39 -0000 Roni, I think the two things that really caused route log to be dropped were the fragmentation problem and the lack of a real motivating scenario to use it. Could you describe some scenarios that motivate the route logging, in particular over iterative queries? The biggest argument that I can see is that it captures a single path that might otherwise change between queries. There's possibly an efficiency advantage if the fragmentation can be solved. I'm not currently convinced either of those motivate route logs being added, but I am open to the possibility. As far as fragmentation, could you be a bit more specific about what information you want to store, and how much space it will take? Your thought would be to store the route log following the forwarding header and split the first fragment as needed? Bruce 2009/8/13 Roni Even : > Hi, > > Route logging was removed entirely from the 03 base draft, due to the pro= blems it causes with fragmentation and message length. There was a discussi= on =C2=A0on the mailing list to use it for the diagnostics. > > > > Currently the diagnostic draft suggests using the Path Track method to re= trieve diagnostic information. In order to collect diagnostic information f= rom all peers in a route the requesting peer must send a separate request t= o each peer in the route. > > > > In past versions there was an option for the requesting peer to send one = request and each peer in the route would respond with his diagnostic inform= ation, this option was removed due to security considerations (message expl= osions attack) and we were looking for another method to optimize the diagn= ostic information reporting. > > > > I suggest adding a route log option to the Inspect method. This will enab= le a requesting peer to send one request and collect diagnostic information= from the peers in the route. In order to limit the message length and prev= ent fragmentation we can specify a fixed subset of diagnostic information t= hat will be reported when route log is requested. The full diagnostics will= still be collected using the Path Track method. > > > > Does this looks =C2=A0like a reasonable optimization for collecting the d= iagnostic information > > > > Thanks > > Roni Even > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From bbl@lowekamp.net Sun Aug 16 21:26:40 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245763A6D4E for ; Sun, 16 Aug 2009 21:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsJ5XftMpjFW for ; Sun, 16 Aug 2009 21:26:39 -0700 (PDT) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by core3.amsl.com (Postfix) with ESMTP id C6F4D3A6B9D for ; Sun, 16 Aug 2009 21:26:38 -0700 (PDT) Received: by fxm22 with SMTP id 22so2414070fxm.9 for ; Sun, 16 Aug 2009 21:26:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.80.23 with SMTP id h23mr1136201mul.88.1250483202561; Sun, 16 Aug 2009 21:26:42 -0700 (PDT) Date: Mon, 17 Aug 2009 00:26:42 -0400 Message-ID: From: Bruce Lowekamp To: p2psip , draft-maenpaa-p2psip-topologyplugin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] comments on draft-maenpaa-p2psip-topologyplugin-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 04:26:40 -0000 I think drafts that discuss alternative/extension overlay algorithms are a great contribution and appreciate the authors writing this draft. Would be really nice to get WG effort behind making some of these concepts WG items. Bruce --------------------- The draft refers to "real world" environments a lot. This term is relatively meaningless (or, more precisely, means different things to each reader). Define use cases where the draft is necessary or offers performance improvements and make concrete claims. Obviously many/most large-scale overlays with moderate churn perform better with some of the techniques. State that or something similar and the overlay algorithm features that are needed for that/those use case(s). Similarly, state the use case that requires load balancing. The basic sip usage is probably not one of them given the small size of registrations. But an eventual voicemail usage is likely to be a supporting use case, for example. Remember that there are real world use cases where this algorithm behaves more poorly than the default RELOAD algorithm. For example, a small-office phone system is a real world use case. It's one that is typically ignored by much of the P2P community, but it is one of the motivating use cases in P2PSIP. I'm not immediately convinced of the usefulness of the load balancing concept. In particular, the load balancing aims to balance out the uneven load that is the natural result of hashing and uneven peer spacing. However, for many use cases load imbalance seems to be more a function of resource size distribution rather than uneven mapping. For example, a file sharing usage might have several orders of magnitude variation in resource size, whereas uneven mapping is a factor of O(log(N)). To me, it's much more important to solve the large file problem by dividing large files among multiple locations. Once that is done, using virtual servers to balance mapping and account for device capacity becomes more pressing. While I can see that an optimal chunking might be usage-specific, I can also see a lot of use of it as a general service. The security mechanisms remain a challenge there. How does one run UpdateAlphaDelta when using an enrollment server/CA for certificates? I don't see this addressed anywhere. There are obvious important benefits to using periodic stabilization in certain circumstances. However, the way the virtual server load balancing is specified appears to me to be produce at least an order of magnitude more traffic in response to peer changes than a reactive stabilization algorithm. For example, in the event of a finger table entry failure, the peer Leaves all of its virtual server locations (with associated resource transfers), identifies a new set of virtual server IDs, then reJoins at the new addresses and transfers resources. By comparison, reactive stabilization sends a few Updates when a neighbor fails. In the UpdateReq and a few other places, the sender asserts their ids in a message structure. Those need to be obtained from a certificate, not from the message body. There are some reactive elements to the periodic stabilization algorithm. For example, on successor failure, the peer walks its successor list pulling from each. A reactive pull rather than a reactive push is still a reactive algorithm. Section 6 uses almost entirely SHOULD rather than MUST. I am fairly sure that an implementation that did not implement any of the SHOULDs would fail to work entirely. I suspect that almost all SHOULDs should be MUST. It's helpful to indicate what a reason might be for not implementing a SHOULD when SHOULD is appropriate. (Henning can make this argument with a lot more passion, if necessary.) I really like the effort on adaptive stabilization. One factor to consider, though, is whether keepalives of some sort (possibly NAT binding keepalives) need to be sent more often than necessary based on peer failure, and those keepalives might as well be a basic Update. Sort of a complex question based on the cost of a STUN keepalive vs p2p layer, but I think it's an interesting question. The next two comments are aimed at making the text clearer. First, I should be clear that I'm not going to claim I've never done these in writing text (and I think there are still parts of the base draft that need to have these applied). A lot of the text merges analysis/justification with normative text. Implementers don't care about the analysis, and even for those who do it makes it harder to find the normative text. Separate these where possible, ideally into separate sections, but at least separate paragraphs. A number of aspects of the algorithm are of the form (this is not a real extract): - when y fails, send a probe to ID t for a new entry - when receiving response for ID t from peer q, send an Attach to q - once the Attach completes, send an Update to q While this is great in descriptive text, the implementation is entirely different since the implementation has to be asynchronous. And while IETF isn't about implementation, there are a lot of protocol correctness issues left exposed here (what happens if a better peer than q is identified in between sending the Attach and it completing?). Better to write normative text that specifies a single reaction when an event happens. For example, you might write that when a better finger table entry is identified, an Attach is sent to it. Specified entirely separately (and possibly somewhere else), finger table and neighborhood entries are updated when an Attach completes for a better match than the current entry. This also avoids missing stating obvious things everywhere, like in 6.4 where it isn't entirely clear that an Attach needs to be completed before updating the neighbor list. From Even.roni@huawei.com Sun Aug 16 23:11:46 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6C7A3A6962 for ; Sun, 16 Aug 2009 23:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.594 X-Spam-Level: * X-Spam-Status: No, score=1.594 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+jZfgeKmn-s for ; Sun, 16 Aug 2009 23:11:46 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id AEF753A685F for ; Sun, 16 Aug 2009 23:11:45 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOI009TEBS7DB@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 17 Aug 2009 14:09:43 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOI009T6BS7SL@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 17 Aug 2009 14:09:43 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-129-102.red.bezeqint.net [79.181.129.102]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOI005XCBS3OX@szxml01-in.huawei.com>; Mon, 17 Aug 2009 14:09:43 +0800 (CST) Date: Mon, 17 Aug 2009 09:06:59 +0300 From: Roni Even In-reply-to: To: 'Bruce Lowekamp' Message-id: <016001ca1f00$f2a28a40$d7e79ec0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acoe8wj6f6n2YG6sQzqtgoJVeAaNCgACxLSQ References: <001201ca1be3$c2486150$46d923f0$%roni@huawei.com> Cc: 'p2psip' Subject: Re: [P2PSIP] Add route log option to diagnostic draft for collecting diagnostic information X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 06:11:47 -0000 Bruce, The major motivation is having a simple way to collect data along the path. In the first versions of the diagnostic draft there was a method that caused each peer in the route to send a respond to the requesting peer with the diagnostic information. This was removed because of security reason since this method could serve as a tool for message explosion attack. Currently using iterative mode you will need to send a message to each peer in the path to collect diagnostic information. I think that getting information like processing power, BW, status and uptime (this is less than 30 bytes per node) from each node in the route (this can be on the forward or return path) can help the requesting peer with estimating the quality of the link. It is true that it applies to the current path which may change but this is also true for the case of iterative request. Yet this is a more efficient way. As for the information to collect, I gave an example since the first question is if this looks like a viable solution in general since it optimizes the current flow. If we think it is than we can discuss the information that may be collected using this method. It would have been more precise to get this route log information in the requests but this option was removed from the base draft. Roni > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of Bruce Lowekamp > Sent: Monday, August 17, 2009 7:27 AM > To: Roni Even > Cc: p2psip > Subject: Re: [P2PSIP] Add route log option to diagnostic draft for > collecting diagnostic information > > Roni, > > I think the two things that really caused route log to be dropped were > the fragmentation problem and the lack of a real motivating scenario > to use it. > > Could you describe some scenarios that motivate the route logging, in > particular over iterative queries? The biggest argument that I can > see is that it captures a single path that might otherwise change > between queries. There's possibly an efficiency advantage if the > fragmentation can be solved. I'm not currently convinced either of > those motivate route logs being added, but I am open to the > possibility. > > As far as fragmentation, could you be a bit more specific about what > information you want to store, and how much space it will take? Your > thought would be to store the route log following the forwarding > header and split the first fragment as needed? > > Bruce > > > > 2009/8/13 Roni Even : > > Hi, > > > > Route logging was removed entirely from the 03 base draft, due to the > problems it causes with fragmentation and message length. There was a > discussion on the mailing list to use it for the diagnostics. > > > > > > > > Currently the diagnostic draft suggests using the Path Track method > to retrieve diagnostic information. In order to collect diagnostic > information from all peers in a route the requesting peer must send a > separate request to each peer in the route. > > > > > > > > In past versions there was an option for the requesting peer to send > one request and each peer in the route would respond with his > diagnostic information, this option was removed due to security > considerations (message explosions attack) and we were looking for > another method to optimize the diagnostic information reporting. > > > > > > > > I suggest adding a route log option to the Inspect method. This will > enable a requesting peer to send one request and collect diagnostic > information from the peers in the route. In order to limit the message > length and prevent fragmentation we can specify a fixed subset of > diagnostic information that will be reported when route log is > requested. The full diagnostics will still be collected using the Path > Track method. > > > > > > > > Does this looks like a reasonable optimization for collecting the > diagnostic information > > > > > > > > Thanks > > > > Roni Even > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Aug 18 08:37:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91EC23A6999 for ; Tue, 18 Aug 2009 08:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAX4aYlpJu8z for ; Tue, 18 Aug 2009 08:37:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AF8633A698C for ; Tue, 18 Aug 2009 08:37:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHxnikqrR7PE/2dsb2JhbAC/f4gtkEEFhBk X-IronPort-AV: E=Sophos;i="4.43,402,1246838400"; d="scan'208";a="229453790" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 18 Aug 2009 15:37:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7IFbuAx013191 for ; Tue, 18 Aug 2009 08:37:56 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7IFbuVe016326 for ; Tue, 18 Aug 2009 15:37:56 GMT Message-Id: From: Cullen Jennings To: P2PSIP WG Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 09:37:55 -0600 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=443; t=1250609877; x=1251473877; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20reload=20issues=20update |Sender:=20; bh=Pyfs2Cs1IpfTWJBgs9ZEJGkZ62Tf2d5nNkZtd4hyOI0=; b=C5T9RPE19DsPCZaq3Bfhr0aawEvFozanlGH4fa02nj/cQaPuvf2kEAf1jB bz79vinzuaVlgzgVQu+LiZTrukpSlt6mqgbg3FQ45s9MaPGaRZN57ktlCNbX Ly6rpFOw2f; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [P2PSIP] reload issues update X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 15:37:52 -0000 I'm still collecting up issues on the reload and sip usage draft but the initial list is in a spreadsheet at http://svn.resiprocate.org/rep/ietf-drafts/p2psip/issues.csv I realize there are better tools for tracking bugs than a spreadsheet in a source code control system but this is something everyone can use, works across a wide range of operating systems, and allowed multiple people to work offline and make changes. From michaelc@idssoftware.com Tue Aug 18 21:09:25 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D99D3A6840 for ; Tue, 18 Aug 2009 21:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2udocbRNg4h for ; Tue, 18 Aug 2009 21:09:24 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 42E923A680E for ; Tue, 18 Aug 2009 21:09:22 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mdbgu-0008Ce-5V; Tue, 18 Aug 2009 23:18:24 -0400 Message-ID: <4A8B7025.1030903@idssoftware.com> Date: Tue, 18 Aug 2009 20:23:17 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da94011e5b84aeaff359c9d1a59b76d19f3ef350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: P2PSIP WG Subject: Re: [P2PSIP] reload issues update X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 04:09:25 -0000 Cullen, I posted several issues regarding the -03 draft late July. I want to make sure the authors consider them in future next revision: http://www.ietf.org/mail-archive/web/p2psip/current/msg05019.html Thanks --Michael Cullen Jennings wrote: > > I'm still collecting up issues on the reload and sip usage draft but > the initial list is in a spreadsheet at > > http://svn.resiprocate.org/rep/ietf-drafts/p2psip/issues.csv > > I realize there are better tools for tracking bugs than a spreadsheet > in a source code control system but this is something everyone can > use, works across a wide range of operating systems, and allowed > multiple people to work offline and make changes. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From julian@orchidseed.org Tue Aug 18 23:10:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1BB83A6900 for ; Tue, 18 Aug 2009 23:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmjCIYD569jG for ; Tue, 18 Aug 2009 23:10:40 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 99C1B3A68F4 for ; Tue, 18 Aug 2009 23:10:40 -0700 (PDT) Received: by ywh26 with SMTP id 26so5503695ywh.5 for ; Tue, 18 Aug 2009 23:09:05 -0700 (PDT) Received: by 10.91.142.8 with SMTP id u8mr4531709agn.102.1250662145697; Tue, 18 Aug 2009 23:09:05 -0700 (PDT) Received: from ?10.0.1.8? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 6sm1053337agd.72.2009.08.18.23.09.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Aug 2009 23:09:04 -0700 (PDT) Message-Id: From: jc To: Cullen Jennings In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 23:09:02 -0700 References: X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] reload issues update X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 06:10:42 -0000 Cullen, csv is fine, thx. While I am here: Section 9 states "at least three" predecessor's and successor's while section 9.1 states "3". IMHO, section 9.1. needs a bit of rewording because you may or may not have three peers clockwise or counterclockwise at any given time. So technically in section 9.1 the neighbor table SHOULD contain at least 3 peers before this peer and at least 3 peers after it in the DHT ring. Are we clearly stating that the neighbor table is indeed at most 6 node id's with 3 in each direction around the ring? Are we stating that you should not add to the back or front list if they contain already three entries? 9. Chord Algorithm The original Chord algorithm specified a single predecessor and a successor list be stored. chord-reload specifies at least three of each. 9.1. Overview The neighbor table contains the 3 peers before this peer and the 3 peers after it in the DHT ring. Julian Cain On Aug 18, 2009, at 8:37 AM, Cullen Jennings wrote: > > I'm still collecting up issues on the reload and sip usage draft but > the initial list is in a spreadsheet at > > http://svn.resiprocate.org/rep/ietf-drafts/p2psip/issues.csv > > I realize there are better tools for tracking bugs than a > spreadsheet in a source code control system but this is something > everyone can use, works across a wide range of operating systems, > and allowed multiple people to work offline and make changes. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Wed Aug 19 19:29:48 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D0228C416 for ; Wed, 19 Aug 2009 19:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z72Ib54bVSIz for ; Wed, 19 Aug 2009 19:29:48 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 219C73A6C21 for ; Wed, 19 Aug 2009 19:29:25 -0700 (PDT) Received: by gxk17 with SMTP id 17so6408102gxk.19 for ; Wed, 19 Aug 2009 19:29:28 -0700 (PDT) Received: by 10.91.135.13 with SMTP id m13mr5420426agn.25.1250735368208; Wed, 19 Aug 2009 19:29:28 -0700 (PDT) Received: from ?10.0.1.8? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 4sm1539154aga.53.2009.08.19.19.29.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Aug 2009 19:29:26 -0700 (PDT) Message-Id: From: jc To: P2PSIP WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 19:29:23 -0700 X-Mailer: Apple Mail (2.936) Subject: [P2PSIP] Exponential Back-off and Retry Algorithms for Managed Systems X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 02:29:49 -0000 Hi, It is IMHO there should be added an exponential back-off and retry algorithm for all sections indicative of a "managed system". I can envision the enrollment service getting DDOS'd under certain conditions by it's own peers. Regards, Julian From julian@orchidseed.org Sat Aug 22 21:26:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628DF3A6C34 for ; Sat, 22 Aug 2009 21:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2DvKQxdcSHO for ; Sat, 22 Aug 2009 21:26:26 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id 791A43A6A3E for ; Sat, 22 Aug 2009 21:26:26 -0700 (PDT) Received: by ywh4 with SMTP id 4so2120529ywh.17 for ; Sat, 22 Aug 2009 21:26:27 -0700 (PDT) Received: by 10.90.18.35 with SMTP id 35mr2626534agr.3.1251001587571; Sat, 22 Aug 2009 21:26:27 -0700 (PDT) Received: from ?10.0.1.8? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 40sm3755985aga.78.2009.08.22.21.26.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 22 Aug 2009 21:26:26 -0700 (PDT) Message-Id: From: jc To: P2PSIP WG Content-Type: multipart/alternative; boundary=Apple-Mail-2--36039446 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 22 Aug 2009 21:26:23 -0700 X-Mailer: Apple Mail (2.936) Subject: [P2PSIP] reload configuration non-plural xml elements X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 04:26:27 -0000 --Apple-Mail-2--36039446 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cullen, I didn't catch these until I implemented the configuration parser. The descriptions of two of the elements are plural in the draft while the xml elements themselves are not. The two mismatched description element pairs: kinds-signature : kinds-signer : Julian --Apple-Mail-2--36039446 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cullen,

I didn't = catch these until I implemented the configuration = parser. 

The descriptions of two of the = elements are plural in the draft while the xml elements themselves are = not.

The two mismatched description element = pairs:

   kinds-signature : = <kind-signature>
   kinds-signer : = <kind-signer>

List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 14:37:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_g4bczY2KunRkIB2K68Xzdg) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi, I looked at the client procedures in RELOAD and I am not sure I understand how the client provides its responsible peer his client-id. I assume that ATTACH is being used to form the direct connection from the client to the responsible peer. BTW: In section E.1 the text says - " A node acting as a client that has a full implementation of RELOAD and the appropriate overlay algorithm is capable of locating its responsible peer in the overlay and using CONNECT to establish a direct connection to that peer." I think that CONNECT is an old message from the individual draft and it should have said ATTACH. Thanks Roni Even --Boundary_(ID_g4bczY2KunRkIB2K68Xzdg) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

Hi,

I looked at the client procedures in RELOAD and I am not sure I understand how the client provides its responsible peer his client-id. I assume that ATTACH is being used to form the direct connection from the client to the responsible peer.

BTW: In section E.1  the text says -  " A node acting as a  client that has a full implementation of RELOAD and the appropriate  overlay algorithm is capable of locating its responsible peer in the  overlay and using CONNECT to establish a direct connection to that  peer." I think that CONNECT is an old message from the individual draft and it should have said ATTACH.
 
Thanks
Roni Even
--Boundary_(ID_g4bczY2KunRkIB2K68Xzdg)-- From julian@orchidseed.org Sun Aug 23 09:20:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF14E3A6BDE for ; Sun, 23 Aug 2009 09:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VH+ZCpIFK2s for ; Sun, 23 Aug 2009 09:20:08 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) by core3.amsl.com (Postfix) with ESMTP id C3CCF3A68E9 for ; Sun, 23 Aug 2009 09:20:07 -0700 (PDT) Received: by yxe3 with SMTP id 3so1358150yxe.29 for ; Sun, 23 Aug 2009 09:20:08 -0700 (PDT) Received: by 10.90.41.4 with SMTP id o4mr776990ago.66.1251044408537; Sun, 23 Aug 2009 09:20:08 -0700 (PDT) Received: from ?10.0.1.8? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 39sm4778020agb.4.2009.08.23.09.20.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 Aug 2009 09:20:07 -0700 (PDT) Message-Id: <45313BCC-3AC1-4522-9FD0-0E7C88643CE8@orchidseed.org> From: jc To: Roni Even In-Reply-To: <004501ca23ff$2fbe6540$8f3b2fc0$%roni@huawei.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-6783307 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 23 Aug 2009 09:20:06 -0700 References: <004501ca23ff$2fbe6540$8f3b2fc0$%roni@huawei.com> X-Mailer: Apple Mail (2.936) Cc: 'p2psip' Subject: Re: [P2PSIP] Clients node-id in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 16:20:08 -0000 --Apple-Mail-1-6783307 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Roni, Clients have two options described in section 3.2.1 to use the overlay. The client-id is stored in it's certificate so it's responsible peer or any other node already has this if a TLS/DTLS connection handshake has completed. See section 3.1 for more information. As far as section E.1 CONNECT is now an AppAttach message. Julian On Aug 23, 2009, at 7:36 AM, Roni Even wrote: > Hi, > I looked at the client procedures in RELOAD and I am not sure I > understand how the client provides its responsible peer his client- > id. I assume that ATTACH is being used to form the direct connection > from the client to the responsible peer. > BTW: In section E.1 the text says - " A node acting as a client > that has a full implementation of RELOAD and the appropriate > overlay algorithm is capable of locating its responsible peer in > the overlay and using CONNECT to establish a direct connection to > that peer." I think that CONNECT is an old message from the > individual draft and it should have said ATTACH. > > Thanks > Roni Even > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1-6783307 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Roni,
Clients have two = options described in section 3.2.1 to use the overlay. The client-id is = stored in it's certificate so it's responsible peer or any other node = already has this if a TLS/DTLS connection handshake has completed. See = section 3.1 for more information.

As far as = section E.1 CONNECT is now an AppAttach = message.

Julian

On = Aug 23, 2009, at 7:36 AM, Roni Even wrote:

Hi,
I = looked at the client procedures in RELOAD and I am not sure I understand = how the client provides its responsible peer his client-id. I assume = that ATTACH is being used to form the direct connection from the client = to the responsible peer.
BTW: In =
section E.1  the text says -  " A node =
acting as a  client that has a full implementation of RELOAD and =
the appropriate  overlay algorithm is capable of locating its =
responsible peer in the  overlay and using CONNECT to establish a =
direct connection to that  =
peer." I think that CONNECT is an old message from the individual draft =
and it should have said ATTACH.
 
Thanks
Roni Even relatively meaningless (or, more precisely, means different things to
> each reader).  

The term "real world" was a poor choice. We will replace that.

> Define use cases where the draft is necessary or offers
> performance improvements and make concrete claims.  Obviously
> many/most large-scale overlays with moderate churn perform better with
> some of the techniques.  State that or something similar and the
> overlay algorithm features that are needed for that/those use case(s).
>  Similarly, state the use case that requires load balancing.  The
> basic sip usage is probably not one of them given the small size of
> registrations.   But an eventual voicemail usage is likely to be a
> supporting use case, for example.   Remember that there are real world
> use cases where this algorithm behaves more poorly than the default
> RELOAD algorithm.  For example, a small-office phone system is a real
> world use case.  It's one that is typically ignored by much of the P2P
> community, but it is one of the motivating use cases in P2PSIP.

I agree that adding use cases would improve the draft. We'll define them
in the next version.

> I'm not immediately convinced of the usefulness of the load balancing
> concept.  In particular, the load balancing aims to balance out the
> uneven load that is the natural result of hashing and uneven peer
> spacing.  However, for many use cases load imbalance seems to be more
> a function of resource size distribution rather than uneven mapping.
> For example, a file sharing usage might have several orders of
> magnitude variation in resource size, whereas uneven mapping is a
> factor of O(log(N)).  To me, it's much more important to solve the
> large file problem by dividing large files among multiple locations.
> Once that is done, using virtual servers to balance mapping and
> account for device capacity becomes more pressing.  While I can see
> that an optimal chunking might be usage-specific, I can also see a lot
> of use of it as a general service.  The security mechanisms remain a
> challenge there.
> 
> How does one run UpdateAlphaDelta when using an enrollment server/CA
> for certificates?  I don't see this addressed anywhere.
> 
> There are obvious important benefits to using periodic stabilization
> in certain circumstances.  However, the way the virtual server load
> balancing is specified appears to me to be produce at least an order
> of magnitude more traffic in response to peer changes than a reactive
> stabilization algorithm.  For example, in the event of a finger table
> entry failure, the peer Leaves all of its virtual server locations
> (with associated resource transfers), identifies a new set of virtual
> server IDs, then reJoins at the new addresses and transfers resources.
>  By comparison, reactive stabilization sends a few Updates when a
> neighbor fails.

Perhaps Ashwin or Saumitra can answer the load balancing related
questions better than I can, since they wrote those parts of the draft.
If people think that load balancing is needed only in a subset of use
cases, then one possible way forward would be to make load balancing
optional and specify it separately from the rest of the mechanisms.

> In the UpdateReq and a few other places, the sender asserts their ids
> in a message structure.  Those need to be obtained from a certificate,
> not from the message body.

If you are referring to the sender_id parameter, our intention was to
remove it from the current version of the draft (it turned out that it
is not actually needed), but somehow we forgot to do that.

> There are some reactive elements to the periodic stabilization
> algorithm.  For example, on successor failure, the peer walks its
> successor list pulling from each.  A reactive pull rather than a
> reactive push is still a reactive algorithm.

The current draft is the result of a merge of two earlier drafts,
draft-saumitra-p2psip-loadbalance-00 and
draft-maenpaa-p2psip-self-tuning-00. The former used reactive
stabilization (as it was an extension to the Chord algorithm of RELOAD
base), whereas the latter one used periodic stabilization. Our intention
was to make the algorithm in the current draft completely periodic.
However, it seems that we didn't manage to remove all the reactive
elements from the algorithm. We will look into that in the next version
of the draft.

> Section 6 uses almost entirely SHOULD rather than MUST.  I am fairly
> sure that an implementation that did not implement any of the SHOULDs
> would fail to work entirely.  I suspect that almost all SHOULDs should
> be MUST.  It's helpful to indicate what a reason might be for not
> implementing a SHOULD when SHOULD is appropriate.  (Henning can make
> this argument with a lot more passion, if necessary.)

Ok, thanks for pointing this out.

> I really like the effort on adaptive stabilization.   One factor to
> consider, though, is whether keepalives of some sort (possibly NAT
> binding keepalives) need to be sent more often than necessary based on
> peer failure, and those keepalives might as well be a basic Update.
> Sort of a complex question based on the cost of a STUN keepalive vs
> p2p layer, but I think it's an interesting question.

Keepalives or basic Updates would definitely help in detecting peer
failure faster. We will look into this.

> The next two comments are aimed at making the text clearer.  First, I
> should be clear that I'm not going to claim I've never done these in
> writing text (and I think there are still parts of the base draft that
> need to have these applied).
> 
> A lot of the text merges analysis/justification with normative text.
> Implementers don't care about the analysis, and even for those who do
> it makes it harder to find the normative text.  Separate these where
> possible, ideally into separate sections, but at least separate
> paragraphs.
> 
> A number of aspects of the algorithm are of the form (this is not a
> real extract):
> - when y fails, send a probe to ID t for a new entry
> - when receiving response for ID t from peer q, send an Attach to q
> - once the Attach completes, send an Update to q
> While this is great in descriptive text, the implementation is
> entirely different since the implementation has to be asynchronous.
> And while IETF isn't about implementation, there are a lot of protocol
> correctness issues left exposed here (what happens if a better peer
> than q is identified in between sending the Attach and it
> completing?).  Better to write normative text that specifies a single
> reaction when an event happens.  For example, you might write that
> when a better finger table entry is identified, an Attach is sent to
> it.  Specified entirely separately (and possibly somewhere else),
> finger table and neighborhood entries are updated when an Attach
> completes for a better match than the current entry.  This also avoids
> missing stating obvious things everywhere, like in 6.4 where it isn't
> entirely clear that an Attach needs to be completed before updating
> the neighbor list.

We will try to separate analysis and normative text in the next version.

Thanks,
Jouni


From davidbryan@gmail.com  Wed Aug 26 12:54:10 2009
Return-Path: 
X-Original-To: p2psip@core3.amsl.com
Delivered-To: p2psip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3443A6853 for ; Wed, 26 Aug 2009 12:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.492
X-Spam-Level: 
X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[AWL=0.485,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO8bh1t5EcmK for ; Wed, 26 Aug 2009 12:54:09 -0700 (PDT)
Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by core3.amsl.com (Postfix) with ESMTP id C2DD73A699F for ; Wed, 26 Aug 2009 12:54:09 -0700 (PDT)
Received: by qyk39 with SMTP id 39so140803qyk.31 for ; Wed, 26 Aug 2009 12:54:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=SOgp5Z6xMJ5VGKnBcjk9BtQOYcq7Dabw7eXrjBotXlY=; b=rx9GC03BQ4mpji43i0G+tuUsHRfefFBMqTI/llx/MS5yDrPoNC28QxPxQzawsvdbtC 6sM4k1/dDGVa/dr8fr3+by0V3lPGNP5H90X1BRwhspl8mXVRhdW56EY0pdkV26c/zigt y7P/JuX9E6dWp4mE/9sJD4E/Ybqv6ZwX4BeAg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NT+b1Y9/2BJqEybdnmsAhhcxESRnfMdVpGhRtwybkGc6QAKlvQac4IWBvlzs65aMpa ZXhFhknGvnb3DS3mwF1sjpM1akiN1L+prK3OtyM0N5Bl7U3x0To+D/yg5G/cburNZN0N xMivMsNmI7EYGd7FMNWdElYxkOyrVn1JuF9T4=
MIME-Version: 1.0
Sender: davidbryan@gmail.com
Received: by 10.229.11.147 with SMTP id t19mr2391485qct.28.1251316443323; Wed,  26 Aug 2009 12:54:03 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 26 Aug 2009 15:54:03 -0400
X-Google-Sender-Auth: 55a1176fb62c1b00
Message-ID: <8b2769930908261254y7506089bn2c8e38459dd74779@mail.gmail.com>
From: "David A. Bryan" 
To: Cullen Jennings 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: P2PSIP WG 
Subject: Re: [P2PSIP] reload issues update
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Aug 2009 19:54:10 -0000

Thanks for getting this up and running, Cullen, and thanks to the
folks who have chimed in with suggestions to add. I think this will
help move the document along.

David

On Tue, Aug 18, 2009 at 11:37 AM, Cullen Jennings wrote:
>
> I'm still collecting up issues on the reload and sip usage draft but the
> initial list is in a spreadsheet at
>
> http://svn.resiprocate.org/rep/ietf-drafts/p2psip/issues.csv
>
> I realize there are better tools for tracking bugs than a spreadsheet in a
> source code control system but this is something everyone can use, works
> across a wide range of operating systems, and allowed multiple people to
> work offline and make changes.
>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip
>

From julian@orchidseed.org  Thu Aug 27 03:18:34 2009
Return-Path: 
X-Original-To: p2psip@core3.amsl.com
Delivered-To: p2psip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0CB528C37B for ; Thu, 27 Aug 2009 03:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level: 
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AUfjVO7FgCy for ; Thu, 27 Aug 2009 03:18:34 -0700 (PDT)
Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id BE18928C369 for ; Thu, 27 Aug 2009 03:17:47 -0700 (PDT)
Received: by gxk17 with SMTP id 17so1171235gxk.19 for ; Thu, 27 Aug 2009 03:17:51 -0700 (PDT)
Received: by 10.91.188.8 with SMTP id q8mr6947262agp.67.1251368271451; Thu, 27 Aug 2009 03:17:51 -0700 (PDT)
Received: from ?10.0.1.8? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 40sm160353aga.78.2009.08.27.03.17.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Aug 2009 03:17:50 -0700 (PDT)
Message-Id: <2D45D934-4F39-41F9-9160-38618628DE8E@orchidseed.org>
From: jc 
To: p2psip WG 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 27 Aug 2009 03:17:48 -0700
X-Mailer: Apple Mail (2.936)
Subject: [P2PSIP] Exponential Back-off and Retry Algorithms for Managed Systems
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Aug 2009 10:18:35 -0000

Now that I thought about this more, the base draft should recommend  
using a back-off and retry algorithm, not define one.

Julian