From bbl@lowekamp.net Fri Feb 4 08:02:00 2011 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 A56EB3A695F for ; Fri, 4 Feb 2011 08:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 qAQdo33i0BKk for ; Fri, 4 Feb 2011 08:01:59 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4F8443A6903 for ; Fri, 4 Feb 2011 08:01:59 -0800 (PST) Received: by iwc10 with SMTP id 10so2521252iwc.31 for ; Fri, 04 Feb 2011 08:05:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.179.135 with SMTP id bq7mr14603075icb.9.1296835524342; Fri, 04 Feb 2011 08:05:24 -0800 (PST) Received: by 10.42.240.3 with HTTP; Fri, 4 Feb 2011 08:05:24 -0800 (PST) In-Reply-To: <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> Date: Fri, 4 Feb 2011 11:05:24 -0500 Message-ID: From: Bruce Lowekamp To: Roni Even Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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: Fri, 04 Feb 2011 16:02:00 -0000 Roni, Since we made it an option for intermediate peers using SRR to keep state rather than modify the forwarding header, I think we should try to keep that option reasonably well supported. And while I agree with you that the timeout such an implementation provides is sufficient for supporting DRR without other modifications, I'd really rather provide an good way for such implementation to avoid keeping state for all DRR (potentially most/many messages) until timeout, thus my support for a flag. We can flag this as an open issue for more discussion, though (pun intended= ). Bruce On Mon, Jan 31, 2011 at 1:54 AM, Roni Even wrote: > Hi Bruce, > I do not think it is required for every message, just for the case when t= he intermediary node keeps state of the message (it is per such a message).= This may be needed due to failures on the route and not only for DRR suppo= rt > Roni > >> -----Original Message----- >> From: Bruce Lowekamp [mailto:bbl@lowekamp.net] >> Sent: Saturday, January 08, 2011 12:30 AM >> To: Roni Even >> Cc: David A. Bryan; P2PSIP WG >> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from >> meeting - DRR >> >> I think requiring the state timeout mechanism to be used for every >> message would be a bit much to put on the peers. =C2=A0I would rather >> provide the explicit flag. >> >> Bruce >> >> On Thu, Jan 6, 2011 at 9:07 AM, Roni Even wrote: >> > Hi Bruce, >> > I think that the flag for not keeping state may be useful but there >> is also another mechanism which is the time out that tells intermediate >> nodes to discard any state after a timeout. >> > Roni >> > >> >> -----Original Message----- >> >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >> >> Behalf Of Bruce Lowekamp >> >> Sent: Thursday, December 02, 2010 8:54 PM >> >> To: David A. Bryan >> >> Cc: P2PSIP WG; Roni Even >> >> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft >> from >> >> meeting - DRR >> >> >> >> The motivation for putting it into the base draft was that if it is >> >> part of the base spec, then in the future nodes that implement >> >> whatever is specified in the relay/DRR draft can make use of those >> >> techniques while on an overlay with nodes that only implement the >> base >> >> draft. =C2=A0For example: >> >> >> >> - any sort of relay/DRR requires intermediate nodes to not keep any >> >> state about routed messages. =C2=A0If support for the routing flag th= at >> >> allows this is not in the base draft, they will have to simply >> reject >> >> the message. >> >> - knowledge of how to set up a relay node isn't required to make use >> >> of the relay node. >> >> >> >> The intention of the current text was that it could currently only >> be >> >> used with no-ice. =C2=A0But it would provide support so that nodes th= at >> >> only implement the base draft would be able to forward messages >> using >> >> relay/DRR and would also be able to send messages to a relay node in >> >> the future without knowing the details of how that is set up. =C2=A0A= s >> >> currently specified, it definitely needs some text stating >> explicitly >> >> that it can currently only be used with no-ice. >> >> >> >> There's another option where we add a ForwardingOptions flag to the >> >> base draft that specifies not to keep state about the message, but >> >> isn't explicitly a DRR flag. =C2=A0There might even be a benefit to d= oing >> >> that, in that it wouldn't be explicitly tied to the DRR mechanism in >> >> there now. >> >> >> >> Or , of course, we can remove it completely, at the cost that base >> >> nodes won't be compatible with whatever is done in the relay/DRR >> >> draft. >> >> >> >> Bruce >> >> >> >> >> >> On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan >> >> >> wrote: >> >> > I also think the current text is too limiting. The best approach >> is >> >> to >> >> > make it clear in the draft that other routing techniques are >> allowed >> >> > and supported, leave in the flags but remove the very skeletal >> direct >> >> > response routing from this draft and we instead do that in the >> >> > relay/direct response draft. >> >> > >> >> > David (as individual) >> >> > >> >> > On Sun, Nov 21, 2010 at 3:04 AM, Roni Even >> >> wrote: >> >> >> >> >> >>> >> >> >>> Direct Response Routing and ICE >> >> >>> =E2=80=A2 Specified in =C2=A75.3.2.4 >> >> >>> This option can only be used if the direct-return-response- >> >> permitted >> >> >>> flag in the configuration for the overlay is set to TRUE. The >> >> >>> RESPONSE_COPY flag SHOULD be set to false while the >> >> FORWARD_CRITICAL >> >> >>> and DESTINATION_CRITICAL MUST be set to true. When a node that >> >> >>> supports this forwarding options receives a request with it, it >> >> acts >> >> >>> as if it had send an Attach request to the the requesting_node >> and >> >> it >> >> >>> had received the connection_information in the answer. This >> causes >> >> it >> >> >>> to form a new connection directly to that node. >> >> >>> =E2=80=A2 This doesn=E2=80=99t work with ICE because the sender o= f the request >> >> doesn=E2=80=99t >> >> >>> have your information >> >> >>> Proposed Resolution: DRR can only be used with No-ICE >> >> >>> ***NOTE: This slide generated significant discussion in the >> >> meeting. >> >> >>> There were some comments that this was incomplete, and >> discussion >> >> of >> >> >>> moving this out of the base draft and into the relay/direct >> >> response >> >> >>> draft. ADDITIONAL DISCUSSION REQUIRED. >> >> >> >> >> >> I see the problem and think that we should take this section out >> >> from RELOAD and continue with the individual relay draft (draft- >> jiang- >> >> p2psip-relay-04) for the use case where the node is not behind NAT >> or a >> >> relay can be used. >> >> >> In this case we will need to verify that RELOAD allows such >> >> extensions and that there are no issues with supporting it due to >> some >> >> routing assumptions. >> >> >> >> >> >> 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 Even.roni@huawei.com Fri Feb 4 15:05:58 2011 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 7708C3A69FA for ; Fri, 4 Feb 2011 15:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 ImbtipfSraP2 for ; Fri, 4 Feb 2011 15:05:56 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1B1693A69CD for ; Fri, 4 Feb 2011 15:05:56 -0800 (PST) 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 <0LG400E6D8BBGT@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 05 Feb 2011 07:09:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LG4009T08BBYY@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 05 Feb 2011 07:09:11 +0800 (CST) Received: from windows8d787f9 ([109.67.11.81]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LG4006VW8B3V8@szxml01-in.huawei.com>; Sat, 05 Feb 2011 07:09:11 +0800 (CST) Date: Sat, 05 Feb 2011 01:05:03 +0200 From: Roni Even In-reply-to: To: 'Bruce Lowekamp' Message-id: <022e01cbc4bf$fa6016b0$ef204410$%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: quoted-printable Thread-index: AcvEhWLz+PeQqfP5Q1W3OTPZSLxHygAOoCkQ References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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: Fri, 04 Feb 2011 23:05:58 -0000 Bruce, I am with you and think that having a flag is a good idea Roni > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of Bruce Lowekamp > Sent: Friday, February 04, 2011 6:05 PM > To: Roni Even > Cc: P2PSIP WG > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft = from > meeting - DRR >=20 > Roni, >=20 > Since we made it an option for intermediate peers using SRR to keep > state rather than modify the forwarding header, I think we should try > to keep that option reasonably well supported. And while I agree with > you that the timeout such an implementation provides is sufficient for > supporting DRR without other modifications, I'd really rather provide > an good way for such implementation to avoid keeping state for all DRR > (potentially most/many messages) until timeout, thus my support for a > flag. >=20 > We can flag this as an open issue for more discussion, though (pun > intended). >=20 > Bruce >=20 >=20 > On Mon, Jan 31, 2011 at 1:54 AM, Roni Even > wrote: > > Hi Bruce, > > I do not think it is required for every message, just for the case > when the intermediary node keeps state of the message (it is per such = a > message). This may be needed due to failures on the route and not only > for DRR support > > Roni > > > >> -----Original Message----- > >> From: Bruce Lowekamp [mailto:bbl@lowekamp.net] > >> Sent: Saturday, January 08, 2011 12:30 AM > >> To: Roni Even > >> Cc: David A. Bryan; P2PSIP WG > >> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft > from > >> meeting - DRR > >> > >> I think requiring the state timeout mechanism to be used for every > >> message would be a bit much to put on the peers. I would rather > >> provide the explicit flag. > >> > >> Bruce > >> > >> On Thu, Jan 6, 2011 at 9:07 AM, Roni Even > wrote: > >> > Hi Bruce, > >> > I think that the flag for not keeping state may be useful but > there > >> is also another mechanism which is the time out that tells > intermediate > >> nodes to discard any state after a timeout. > >> > Roni > >> > > >> >> -----Original Message----- > >> >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] = On > >> >> Behalf Of Bruce Lowekamp > >> >> Sent: Thursday, December 02, 2010 8:54 PM > >> >> To: David A. Bryan > >> >> Cc: P2PSIP WG; Roni Even > >> >> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base > draft > >> from > >> >> meeting - DRR > >> >> > >> >> The motivation for putting it into the base draft was that if it > is > >> >> part of the base spec, then in the future nodes that implement > >> >> whatever is specified in the relay/DRR draft can make use of > those > >> >> techniques while on an overlay with nodes that only implement = the > >> base > >> >> draft. For example: > >> >> > >> >> - any sort of relay/DRR requires intermediate nodes to not keep > any > >> >> state about routed messages. If support for the routing flag > that > >> >> allows this is not in the base draft, they will have to simply > >> reject > >> >> the message. > >> >> - knowledge of how to set up a relay node isn't required to make > use > >> >> of the relay node. > >> >> > >> >> The intention of the current text was that it could currently > only > >> be > >> >> used with no-ice. But it would provide support so that nodes > that > >> >> only implement the base draft would be able to forward messages > >> using > >> >> relay/DRR and would also be able to send messages to a relay = node > in > >> >> the future without knowing the details of how that is set up. = As > >> >> currently specified, it definitely needs some text stating > >> explicitly > >> >> that it can currently only be used with no-ice. > >> >> > >> >> There's another option where we add a ForwardingOptions flag to > the > >> >> base draft that specifies not to keep state about the message, > but > >> >> isn't explicitly a DRR flag. There might even be a benefit to > doing > >> >> that, in that it wouldn't be explicitly tied to the DRR = mechanism > in > >> >> there now. > >> >> > >> >> Or , of course, we can remove it completely, at the cost that > base > >> >> nodes won't be compatible with whatever is done in the relay/DRR > >> >> draft. > >> >> > >> >> Bruce > >> >> > >> >> > >> >> On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan > >> > >> >> wrote: > >> >> > I also think the current text is too limiting. The best > approach > >> is > >> >> to > >> >> > make it clear in the draft that other routing techniques are > >> allowed > >> >> > and supported, leave in the flags but remove the very skeletal > >> direct > >> >> > response routing from this draft and we instead do that in the > >> >> > relay/direct response draft. > >> >> > > >> >> > David (as individual) > >> >> > > >> >> > On Sun, Nov 21, 2010 at 3:04 AM, Roni Even > > >> >> wrote: > >> >> >> > >> >> >>> > >> >> >>> Direct Response Routing and ICE > >> >> >>> =E2=80=A2 Specified in =C2=A75.3.2.4 > >> >> >>> This option can only be used if the direct-return-response- > >> >> permitted > >> >> >>> flag in the configuration for the overlay is set to TRUE. = The > >> >> >>> RESPONSE_COPY flag SHOULD be set to false while the > >> >> FORWARD_CRITICAL > >> >> >>> and DESTINATION_CRITICAL MUST be set to true. When a node > that > >> >> >>> supports this forwarding options receives a request with it, > it > >> >> acts > >> >> >>> as if it had send an Attach request to the the > requesting_node > >> and > >> >> it > >> >> >>> had received the connection_information in the answer. This > >> causes > >> >> it > >> >> >>> to form a new connection directly to that node. > >> >> >>> =E2=80=A2 This doesn=E2=80=99t work with ICE because the = sender of the > request > >> >> doesn=E2=80=99t > >> >> >>> have your information > >> >> >>> Proposed Resolution: DRR can only be used with No-ICE > >> >> >>> ***NOTE: This slide generated significant discussion in the > >> >> meeting. > >> >> >>> There were some comments that this was incomplete, and > >> discussion > >> >> of > >> >> >>> moving this out of the base draft and into the relay/direct > >> >> response > >> >> >>> draft. ADDITIONAL DISCUSSION REQUIRED. > >> >> >> > >> >> >> I see the problem and think that we should take this section > out > >> >> from RELOAD and continue with the individual relay draft (draft- > >> jiang- > >> >> p2psip-relay-04) for the use case where the node is not behind > NAT > >> or a > >> >> relay can be used. > >> >> >> In this case we will need to verify that RELOAD allows such > >> >> extensions and that there are no issues with supporting it due = to > >> some > >> >> routing assumptions. > >> >> >> > >> >> >> 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 > >> > > >> > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Sat Feb 5 08:29:06 2011 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 6B6BC3A6903 for ; Sat, 5 Feb 2011 08:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.063 X-Spam-Level: X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 dF-gIdsxs+2h for ; Sat, 5 Feb 2011 08:29:05 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 255B43A6902 for ; Sat, 5 Feb 2011 08:29:04 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id B2FCFDBCC050; Sat, 5 Feb 2011 16:32:32 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 38C29DBCC04E; Sat, 5 Feb 2011 16:32:32 +0000 (UTC) Message-ID: <4D4D7B9F.4080208@acm.org> Date: Sat, 05 Feb 2011 08:32:31 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Eric Rescorla References: <4CFD5FCD.7060205@acm.org> <29353BE9-83FE-40C3-817F-6649AE09DF0C@skype.net> <4D35DA5D.7000804@acm.org> In-Reply-To: <4D35DA5D.7000804@acm.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (3) 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: Sat, 05 Feb 2011 16:29:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/18/2011 10:22 AM, Marc Petit-Huguenin wrote: > Inline. > > On 01/18/2011 05:21 AM, Eric Rescorla wrote: > >> On Dec 6, 2010, at 2:12 PM, Marc Petit-Huguenin wrote: >>> bytes, or 2032 bits. >>> >>> A.14. Section 5.3.2 "uint32 length;" >>> >>> I can assume that this length covers the Header, MessageContents and >>> Signature, >>> but I would guess that this was useful when Message was sent without >>> FramingHeader over TCP (same than for the relo_token used to >>> disambiguate STUN >>> packets). Now that this is useless, can't this length been only >>> Header and >>> MessageContents, so it is possible to find the boundary between >>> MessageContents >>> and Signature without having to parse MessageContents at all? >>> > >> I think it's a mistake to assume we'll never want messages to be >> self-contained/unframed. >> Is there a real advantage to this breaking change? > > A little easier to parse the message, but you are right that a message can be > unframed. The signature can be generated without parsing the message contents, as stated in section 5.3, but it cannot be verified without parsing them, as the length of "message_body" and "extensions" are needed to find the beginning of SignatureBlock. There is a similar issue in StoredData, where length is equally useless, as StoredDataValue had to be parsed to verify the signature (and this cannot be done without knowing the DataModel used). That's not really an issue because anyway MessageContents and StoredDataValue had to be parsed (with the knowledge of the DataModel) after the signature is verified, but that prevent a clear separation of layers in software. BTW I was not able to find text explaining what to do if the message level signature fails. Should the message be dropped (and so be retransmitted) or should an error be sent back? - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1Ne54ACgkQ9RoMZyVa61d9bACgiBWcYYk3KapDfXgXgn6keBQ4 egoAnRKTn6tB8AtmszhSZr1FVGUOBxDS =0zx7 -----END PGP SIGNATURE----- From petithug@acm.org Sun Feb 6 15:42:36 2011 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 991533A6A3C for ; Sun, 6 Feb 2011 15:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.665 X-Spam-Level: X-Spam-Status: No, score=-99.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 bR8OasZILR7o for ; Sun, 6 Feb 2011 15:42:35 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id BECBA3A6A2C for ; Sun, 6 Feb 2011 15:42:35 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id B2153DBCC050; Sun, 6 Feb 2011 23:42:37 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 1D28ADBCC04E for ; Sun, 6 Feb 2011 23:42:37 +0000 (UTC) Message-ID: <4D4F31EC.5020009@acm.org> Date: Sun, 06 Feb 2011 15:42:36 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] draft-ietf-p2psip-base-12 (5) 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, 06 Feb 2011 23:42:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 More questions and comments... A.36. Section 2 "Each Kind is identified with a unique IANA assigned integer called a Kind-ID." According to 13.6, Kind-IDs in the 0xf0000001 to 0xfffffffe are not IANA assigned. Same thing in the second paragraph of 4.1. A.37. Section 5.3.3.1 Error_In_Progress is missing. Also the definition for Error_Config_Too_New does not match 5.3.2.1. A.38. Section 5.5.1.1. 'rel_addr_port corresponds to the rel-addr and rel-port productions. Only present for type "relay".' In ICE, the rel address and port are also present for srflx and prflx candidates. A.39. Section 6.2.2 I am not really sure to understand how the "exists=False" are synthesized when doing a Fetch on an array. For example if a Store was made for an object with an index of 0xfffffffe, and the Fetch requests the whole array, will the answer contains 4294967294 "exists=False" objects? A.40. Section 6.4.3.2 If exist is False, should the hash_value be the hash value of an empty byte array (i.e. da39a3ee5e6b4b0d3255bfef95601890afd80709 for SHA-1) or be omitted? A.41. Section 10.1 expiration definition I think that it would be a good idea to say that a Node should wait a random time after the expiration time before retrieving the file again from the configuration server to not crash it and to let ConfigUpdate do its job. A.42. Section 10.1 client-permitted definition I have no idea how an overlay can enforce this. All nodes starts as clients, so how an overlay is supposed to know the difference between a real client and a client that yet had to do the steps required to become a peer? A.43. Section 10.1 Element signature What certificate should be used to compute (and verify) the signature for the whole configuration file? - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1PMeoACgkQ9RoMZyVa61e9jwCffYWuEsxiutkKPIf3PlZdiGpy mi0An1+8ztwuBfacvkUdZI1TJytrIJBX =cWgV -----END PGP SIGNATURE----- From petithug@acm.org Tue Feb 8 15:04:45 2011 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 7BA3E3A687C for ; Tue, 8 Feb 2011 15:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.965 X-Spam-Level: X-Spam-Status: No, score=-100.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 UdNNy8h0ko79 for ; Tue, 8 Feb 2011 15:04:44 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 934363A67D4 for ; Tue, 8 Feb 2011 15:04:44 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 52422DBCC050; Tue, 8 Feb 2011 23:04:52 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 64636DBCC04E for ; Tue, 8 Feb 2011 23:04:50 +0000 (UTC) Message-ID: <4D51CC11.9050800@acm.org> Date: Tue, 08 Feb 2011 15:04:49 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List References: <4D330C58.2020107@acm.org> In-Reply-To: <4D330C58.2020107@acm.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] RELOAD Interop tests 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, 08 Feb 2011 23:04:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/16/2011 07:18 AM, Marc Petit-Huguenin wrote: > I would be interested in doing interoperability testing with other RELOAD > implementations (-12 and higher) at IETF 80 (we can meet in the terminal room, > like we did for TURN few years ago). I am also interested to hear if there will > be RELOAD implementations in SIPit 28, so I can plan my travels accordingly. One person was interested to do interop testing at IETF 80, but that would be great to have more implementations, even partial, to test with. Will it motivate implementers if I say that that I will pay a round of beer to all the participants for each interoperability bug found in the version of p2psip-base available at the time of the testing? - and the first round is on me anyway. We can make it a Bar Bof (the right kind of Bar Bof). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1RzA8ACgkQ9RoMZyVa61ebxwCgkWYwbXlqvIAZN7ZzJTWza75a fMUAoJUPW9oLeOvkC+xm9bye5gW7vXdl =uUuX -----END PGP SIGNATURE----- From fluffy@cisco.com Tue Feb 8 15:39:44 2011 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 8D31B3A68A0 for ; Tue, 8 Feb 2011 15:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 lemWdXlyWbKJ for ; Tue, 8 Feb 2011 15:39:43 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 928BB3A6866 for ; Tue, 8 Feb 2011 15:39:43 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAONiUU2rR7Hu/2dsb2JhbAClQnOhU5s6hVoEhHuGb4Mv Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2011 23:39:51 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p18NdnQN014057; Tue, 8 Feb 2011 23:39:50 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D2BA199.5080105@acm.org> Date: Tue, 8 Feb 2011 16:41:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9B5EA159-D914-4BDC-94CE-B137EBA27AEE@cisco.com> References: <4D2BA199.5080105@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (4) 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, 08 Feb 2011 23:39:44 -0000 still working on these ... On Jan 10, 2011, at 5:17 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > More comments: >=20 > A.30. Section 5.5.4.1 "opaque config_data<0..2^24-1>" >=20 > If a configuration document contains multiple configuration elements = (and I > guess multiple matching signature elements), then should not = config_data been in > fact structured the same way than kinds?, i.e. an XML fragment = containing only > the configuration element and the signature element for this overlay, = extracted > from the multiple configuration elements document? >=20 > See also A.31 below. >=20 > A.31. Section 1.1 'The file can contain multiple "configuration" = elements..." >=20 > This contradicts the RELAX NG grammar in section 10.1.1. In addition, = should > not configuration elements be structured as kind elements are, i.e. = something > like this: >=20 > > > ... > ... > > > ... > ... > > >=20 > In this case, config_data would contain a XML configuration-block = production > (see A.31 above). >=20 > A.32. Section 10.1 "root-cert: [...] there can be more than one = root-cert element" >=20 > This contradicts the RELAX NG grammar in section 10.1.1. >=20 > A.33. Section 10.1 "enrollment-server: [...] there can be more than = one > enrollment-server element" >=20 > This contradicts the RELAX NG grammar in section 10.1.1. >=20 > A.34. Section 10.1 'multicast-bootstrap: [...] it has an attribute = called > "address" [...] and an attribute called "port"' >=20 > This contradicts the RELAX NG grammar in section 10.1.1 (hostPort). >=20 > A.35. Section 10.1.1 "parameter &=3D element required-kinds { = kind-block* }" >=20 > Because the text in section 10.1. says that "[i]nside each overlay = element, the > required-kinds element can also occur", I think it should be this = instead: >=20 > parameter &=3D element required-kinds { kind-block+ }? >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) >=20 > iEYEARECAAYFAk0roZgACgkQ9RoMZyVa61fN/wCcCZk9KcSDiVZz2u4E+KVfl2Es > w3oAoIYvjgqZv3Lwwt73VSRA03uSlFrg > =3D/1lC > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Feb 8 15:40:11 2011 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 DDD0E3A68BD for ; Tue, 8 Feb 2011 15:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 mkpwmXHBEz2G for ; Tue, 8 Feb 2011 15:40:08 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0BA6C3A6866 for ; Tue, 8 Feb 2011 15:40:08 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAONiUU2rR7Hu/2dsb2JhbAClQnOhU5s6hVoEhHuGb4Mv Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2011 23:40:16 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p18NdnQO014057; Tue, 8 Feb 2011 23:40:15 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4CE440A7.70308@ericsson.com> Date: Tue, 8 Feb 2011 16:42:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48E186A8-228C-4224-8EE7-B177DE525061@cisco.com> References: <4CE440A7.70308@ericsson.com> To: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= X-Mailer: Apple Mail (2.1082) Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Comments on RELOAD base 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, 08 Feb 2011 23:40:12 -0000 On Nov 17, 2010, at 1:52 PM, Jouni M=E4enp=E4=E4 wrote: > Hi, >=20 > Two comments on the RELOAD base draft (draft-ietf-p2psip-base-12): >=20 > Could this reference in the draft be updated to point to the latest = version of the self-tuning DHT draft: >=20 > [I-D.maenpaa-p2psip-self-tuning] >=20 > The latest version of the self-tuning draft is: > http://tools.ietf.org/html/draft-ietf-p2psip-self-tuning-02 I tried to fix this but the version at http://xml.resource.org/ is wrong = so it will get overwritten as it gets regenerated. The RFC Editor will = fix this to be correct before it becomes an RFC. If you feel strongly = about this, I will find a way to fix it.=20 >=20 > In addition, could Section "4.3. Service Discovery" contain a pointer = to draft-ietf-p2psip-service-discovery, which specifies how the ReDiR = service discovery mechanism can be used with RELOAD? The section already = refers to a paper describing ReDiR. The latest version of the service = discovery draft is: >=20 > http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-01 added >=20 > Cheers, > Jouni > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Feb 8 15:46:25 2011 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 0AB573A6866 for ; Tue, 8 Feb 2011 15:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, 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 nE-BZ237qRGB for ; Tue, 8 Feb 2011 15:46:24 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 595233A682C for ; Tue, 8 Feb 2011 15:46:24 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA9kUU2rRN+J/2dsb2JhbAClQnOhT5s6hVoEhHuGb4Mv Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2011 23:46:32 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p18NkVAF018642; Tue, 8 Feb 2011 23:46:32 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <29353BE9-83FE-40C3-817F-6649AE09DF0C@skype.net> Date: Tue, 8 Feb 2011 16:48:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CFD5FCD.7060205@acm.org> <29353BE9-83FE-40C3-817F-6649AE09DF0C@skype.net> To: "p2psip@ietf.org List" X-Mailer: Apple Mail (2.1082) Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (3) 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, 08 Feb 2011 23:46:25 -0000 >=20 >> A.24. Section 10.1.1. "| attribute id { xsd:int })," >>=20 >> Does not match 13.6, that is saying that this is an unsigned integer. = Should >> probably use xsd:unsignedInt instead. Changed=20 >>=20 >> Note that there is other places in the RELAX NG document where the = type can be >> improved (initial-ttl, etc...) >=20 > I'll leave this to Cullen. Glad to make any changes but I'm not sure there is much to be gained = from trying to fully enforce all the rules in the text in the RelaxNG.=20= >> A.26. Section 10.1.1. 'kind-names |=3D "sip-registration"' >>=20 >> the sip-registration kind is not defined in this document. OTOH, Fixed - good catch=20 >> certificate-by-node and certificate-by-name are defined, but not = listed here. >=20 > A cullen problem. >=20 added From fluffy@cisco.com Tue Feb 8 15:46:43 2011 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 B3A5E3A67ED for ; Tue, 8 Feb 2011 15:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 UwLFVYeihiqM for ; Tue, 8 Feb 2011 15:46:42 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 767203A68BD for ; Tue, 8 Feb 2011 15:46:42 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0AAA9kUU2rRN+J/2dsb2JhbACWZQGOXHOhT5s6hVoEhHuGb4Mv Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2011 23:46:50 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p18NkVAG018642; Tue, 8 Feb 2011 23:46:48 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: Date: Tue, 8 Feb 2011 16:48:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> To: Bruce Lowekamp X-Mailer: Apple Mail (2.1082) Cc: P2PSIP WG , Roni Even Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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, 08 Feb 2011 23:46:43 -0000 On the topic of a flag to not keep state... just having a flag won't = work. It has to be an overlay option because all the nodes in the = overlay need to support it. Once you have it as an overlay option, you = don't need it in the base spec. I just don't see any reason to put it in = the base spec - it can be done in extension just as well - and I see = lots of reasons not to but it in the base spec. We don't really know how = to make this work well yet. Ideally it would be an optimization you used = when you could so that a client could still connect to a peer that would = do state and do the DDR for it. Saying something like the flag indicates = don't keep state breaks clients among other things. You would need the = option to be a little more nuanced than that. I think we should define = all of this in the DDR draft - trying to guess what we need before we = know what we are doing is likely to result in getting it wrong.=20 On Feb 4, 2011, at 9:05 AM, Bruce Lowekamp wrote: > Roni, >=20 > Since we made it an option for intermediate peers using SRR to keep > state rather than modify the forwarding header, I think we should try > to keep that option reasonably well supported. And while I agree with > you that the timeout such an implementation provides is sufficient for > supporting DRR without other modifications, I'd really rather provide > an good way for such implementation to avoid keeping state for all DRR > (potentially most/many messages) until timeout, thus my support for a > flag. >=20 > We can flag this as an open issue for more discussion, though (pun = intended). >=20 > Bruce >=20 >=20 > On Mon, Jan 31, 2011 at 1:54 AM, Roni Even = wrote: >> Hi Bruce, >> I do not think it is required for every message, just for the case = when the intermediary node keeps state of the message (it is per such a = message). This may be needed due to failures on the route and not only = for DRR support >> Roni >>=20 >>> -----Original Message----- >>> From: Bruce Lowekamp [mailto:bbl@lowekamp.net] >>> Sent: Saturday, January 08, 2011 12:30 AM >>> To: Roni Even >>> Cc: David A. Bryan; P2PSIP WG >>> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft = from >>> meeting - DRR >>>=20 >>> I think requiring the state timeout mechanism to be used for every >>> message would be a bit much to put on the peers. I would rather >>> provide the explicit flag. >>>=20 >>> Bruce >>>=20 >>> On Thu, Jan 6, 2011 at 9:07 AM, Roni Even = wrote: >>>> Hi Bruce, >>>> I think that the flag for not keeping state may be useful but there >>> is also another mechanism which is the time out that tells = intermediate >>> nodes to discard any state after a timeout. >>>> Roni >>>>=20 >>>>> -----Original Message----- >>>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>>>> Behalf Of Bruce Lowekamp >>>>> Sent: Thursday, December 02, 2010 8:54 PM >>>>> To: David A. Bryan >>>>> Cc: P2PSIP WG; Roni Even >>>>> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft >>> from >>>>> meeting - DRR >>>>>=20 >>>>> The motivation for putting it into the base draft was that if it = is >>>>> part of the base spec, then in the future nodes that implement >>>>> whatever is specified in the relay/DRR draft can make use of those >>>>> techniques while on an overlay with nodes that only implement the >>> base >>>>> draft. For example: >>>>>=20 >>>>> - any sort of relay/DRR requires intermediate nodes to not keep = any >>>>> state about routed messages. If support for the routing flag that >>>>> allows this is not in the base draft, they will have to simply >>> reject >>>>> the message. >>>>> - knowledge of how to set up a relay node isn't required to make = use >>>>> of the relay node. >>>>>=20 >>>>> The intention of the current text was that it could currently only >>> be >>>>> used with no-ice. But it would provide support so that nodes that >>>>> only implement the base draft would be able to forward messages >>> using >>>>> relay/DRR and would also be able to send messages to a relay node = in >>>>> the future without knowing the details of how that is set up. As >>>>> currently specified, it definitely needs some text stating >>> explicitly >>>>> that it can currently only be used with no-ice. >>>>>=20 >>>>> There's another option where we add a ForwardingOptions flag to = the >>>>> base draft that specifies not to keep state about the message, but >>>>> isn't explicitly a DRR flag. There might even be a benefit to = doing >>>>> that, in that it wouldn't be explicitly tied to the DRR mechanism = in >>>>> there now. >>>>>=20 >>>>> Or , of course, we can remove it completely, at the cost that base >>>>> nodes won't be compatible with whatever is done in the relay/DRR >>>>> draft. >>>>>=20 >>>>> Bruce >>>>>=20 >>>>>=20 >>>>> On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan >>> >>>>> wrote: >>>>>> I also think the current text is too limiting. The best approach >>> is >>>>> to >>>>>> make it clear in the draft that other routing techniques are >>> allowed >>>>>> and supported, leave in the flags but remove the very skeletal >>> direct >>>>>> response routing from this draft and we instead do that in the >>>>>> relay/direct response draft. >>>>>>=20 >>>>>> David (as individual) >>>>>>=20 >>>>>> On Sun, Nov 21, 2010 at 3:04 AM, Roni Even >>>>> wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Direct Response Routing and ICE >>>>>>>> =95 Specified in =A75.3.2.4 >>>>>>>> This option can only be used if the direct-return-response- >>>>> permitted >>>>>>>> flag in the configuration for the overlay is set to TRUE. The >>>>>>>> RESPONSE_COPY flag SHOULD be set to false while the >>>>> FORWARD_CRITICAL >>>>>>>> and DESTINATION_CRITICAL MUST be set to true. When a node that >>>>>>>> supports this forwarding options receives a request with it, it >>>>> acts >>>>>>>> as if it had send an Attach request to the the requesting_node >>> and >>>>> it >>>>>>>> had received the connection_information in the answer. This >>> causes >>>>> it >>>>>>>> to form a new connection directly to that node. >>>>>>>> =95 This doesn=92t work with ICE because the sender of the = request >>>>> doesn=92t >>>>>>>> have your information >>>>>>>> Proposed Resolution: DRR can only be used with No-ICE >>>>>>>> ***NOTE: This slide generated significant discussion in the >>>>> meeting. >>>>>>>> There were some comments that this was incomplete, and >>> discussion >>>>> of >>>>>>>> moving this out of the base draft and into the relay/direct >>>>> response >>>>>>>> draft. ADDITIONAL DISCUSSION REQUIRED. >>>>>>>=20 >>>>>>> I see the problem and think that we should take this section out >>>>> from RELOAD and continue with the individual relay draft (draft- >>> jiang- >>>>> p2psip-relay-04) for the use case where the node is not behind NAT >>> or a >>>>> relay can be used. >>>>>>> In this case we will need to verify that RELOAD allows such >>>>> extensions and that there are no issues with supporting it due to >>> some >>>>> routing assumptions. >>>>>>>=20 >>>>>>> Roni Even >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>>=20 >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>=20 >>>>=20 >>=20 >>=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Feb 8 15:46:54 2011 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 71DAE3A68D7 for ; Tue, 8 Feb 2011 15:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 FleHtaFvrOdk for ; Tue, 8 Feb 2011 15:46:53 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7FAF63A67ED for ; Tue, 8 Feb 2011 15:46:53 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA9kUU2rRN+J/2dsb2JhbAClQnOhT5s6hVoEhHuGb4Mv Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2011 23:47:01 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p18NkVAH018642; Tue, 8 Feb 2011 23:47:01 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D35D37E.9040409@acm.org> Date: Tue, 8 Feb 2011 16:49:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8DFDD71B-4A55-4E18-9C3E-1B2DD555AFD0@cisco.com> References: <4D35D37E.9040409@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (4) 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, 08 Feb 2011 23:46:54 -0000 fixed On Jan 18, 2011, at 10:53 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Three nits that I hope will make it in -13: >=20 > - - Section 6.4.1.1: In the text description of StoreKindData: >=20 > s/generation/generation_counter/ >=20 > - - Section 6.4.1.2: In the text description of StoreKindData: >=20 > s/generation/generation_counter/ >=20 > Section 10.1: >=20 > s/It has an attributed called "address"/It has an attribute called = "address"/ >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) >=20 > iEYEARECAAYFAk0103wACgkQ9RoMZyVa61ccSQCgiU0ZosVYTb/AmCLyuKF6nhX7 > 8U8An0omFdpD60fUmBqc8/zcuG2QRyG7 > =3Dkfgg > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Feb 8 15:48:52 2011 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 1B7803A682C for ; Tue, 8 Feb 2011 15:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 eoiwlt0dKGg5 for ; Tue, 8 Feb 2011 15:48:51 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 556E83A67ED for ; Tue, 8 Feb 2011 15:48:51 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHdlUU2rRN+J/2dsb2JhbAClQnOhXJs5hVoEhHuGb4Mv Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2011 23:48:59 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p18NmwgE019762; Tue, 8 Feb 2011 23:48:58 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <1D7ECC00-15E7-4E46-9C3B-B942E0856815@skype.net> Date: Tue, 8 Feb 2011 16:51:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CEAC54A.2030503@acm.org> <1D7ECC00-15E7-4E46-9C3B-B942E0856815@skype.net> To: Eric Rescorla X-Mailer: Apple Mail (2.1082) Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2) 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, 08 Feb 2011 23:48:52 -0000 On Jan 18, 2011, at 6:42 AM, Eric Rescorla wrote: >>=20 >> - - A.12. Section 10.3 states that "[t]he SubjectAltName field in the = certificate >> contains the following values: One or more Node-IDs...", but nowhere = it is said >> how to request multiple Node-IDs. Is it an URL parameter of the POST = request? >> An attribute in the Certification Request object? >>=20 >=20 > Good question. This is an issue that's simply not addressed in the = draft., but presumably > we'll need to do something like this, yeah. My taste would be for it = to be a URL in the POSt. It's not really defined in this draft how to have Certificates with = multiple node-id. There are some arguments about if multiple node ids = are useful or not - The goal here is just to make sure that option is = left open if a future extension does this. A parameter on the post URL = sounds like a good approach.=20= From fluffy@cisco.com Tue Feb 8 15:49:02 2011 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 4A8DC3A68BD for ; Tue, 8 Feb 2011 15:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 9iBie+Jt2ZaJ for ; Tue, 8 Feb 2011 15:49:01 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AD4BA3A67ED for ; Tue, 8 Feb 2011 15:49:01 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHdlUU2rRN+J/2dsb2JhbAClQnOhXJs5hVoEhHuGb4Mv Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2011 23:49:09 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p18NmwgF019762; Tue, 8 Feb 2011 23:49:09 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D4D7B9F.4080208@acm.org> Date: Tue, 8 Feb 2011 16:51:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <13BF6433-D1D8-4534-8038-DBDE2723298C@cisco.com> References: <4CFD5FCD.7060205@acm.org> <29353BE9-83FE-40C3-817F-6649AE09DF0C@skype.net> <4D35DA5D.7000804@acm.org> <4D4D7B9F.4080208@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (3) 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, 08 Feb 2011 23:49:02 -0000 On Feb 5, 2011, at 9:32 AM, Marc Petit-Huguenin wrote: >=20 > BTW I was not able to find text explaining what to do if the message = level > signature fails. Should the message be dropped (and so be = retransmitted) or > should an error be sent back? The code I have seems like it just drops it but I don't really care = which way we decide to go on this.=20 From fluffy@cisco.com Tue Feb 8 15:49:09 2011 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 85ADA3A68B1 for ; Tue, 8 Feb 2011 15:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 X+c0VGpUz4N9 for ; Tue, 8 Feb 2011 15:49:08 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 539F43A68D2 for ; Tue, 8 Feb 2011 15:49:08 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHdlUU2rRN+J/2dsb2JhbAClQnOhXJs5hVoEhHuGb4Mv Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2011 23:49:16 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p18NmwgG019762; Tue, 8 Feb 2011 23:49:15 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D51CC11.9050800@acm.org> Date: Tue, 8 Feb 2011 16:51:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <489CE933-F5C7-4123-ACAB-1AF91498DD25@cisco.com> References: <4D330C58.2020107@acm.org> <4D51CC11.9050800@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] RELOAD Interop tests 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, 08 Feb 2011 23:49:09 -0000 Sounds like a great idea, and I'm happy to get the tab.=20 =20 On Feb 8, 2011, at 4:04 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 01/16/2011 07:18 AM, Marc Petit-Huguenin wrote: >> I would be interested in doing interoperability testing with other = RELOAD >> implementations (-12 and higher) at IETF 80 (we can meet in the = terminal room, >> like we did for TURN few years ago). I am also interested to hear if = there will >> be RELOAD implementations in SIPit 28, so I can plan my travels = accordingly. >=20 > One person was interested to do interop testing at IETF 80, but that = would be > great to have more implementations, even partial, to test with. Will = it > motivate implementers if I say that that I will pay a round of beer to = all the > participants for each interoperability bug found in the version of = p2psip-base > available at the time of the testing? - and the first round is on me = anyway. We > can make it a Bar Bof (the right kind of Bar Bof). >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) >=20 > iEYEARECAAYFAk1RzA8ACgkQ9RoMZyVa61ebxwCgkWYwbXlqvIAZN7ZzJTWza75a > fMUAoJUPW9oLeOvkC+xm9bye5gW7vXdl > =3DuUuX > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Feb 8 15:57:14 2011 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 260023A6864 for ; Tue, 8 Feb 2011 15:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 GUtSI0D5T1B9 for ; Tue, 8 Feb 2011 15:57:12 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7C1CD3A67ED for ; Tue, 8 Feb 2011 15:57:12 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGdmUU2rRN+J/2dsb2JhbAClQnOhZps5hVoEhHuGb4Mv Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2011 23:57:20 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p18NvJG7023400; Tue, 8 Feb 2011 23:57:20 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4D35DC24.6030808@acm.org> Date: Tue, 8 Feb 2011 16:59:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D094D1B-8323-4C2A-8993-DB2D67B2B22E@cisco.com> References: <4CE42CDF.4060804@acm.org> <4D35DC24.6030808@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 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, 08 Feb 2011 23:57:14 -0000 Up to version 11, we only had the KindID described in the IANA registry = section and it was defined as a 32 bit value. In version 12, we added = the typedef for it as well but messed up and put 16 where it should have = been 32. The IANA text in version 12 was still 32 bits.=20 I think the kinds should be a 32 bit space. At first glance 16 bits = might seem like enough but the more you think about it, we use these all = over the place. A given application could use many kinds. It would be = really bad to run out. The doc currently contradicts itself having them = partially 32 and partially 16 but I think we should go with 32 bits as = we had in version prior to version 12 of the draft.=20 On Jan 18, 2011, at 11:29 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 01/18/2011 05:32 AM, Eric Rescorla wrote: >>=20 >> On Nov 17, 2010, at 11:28 AM, Marc Petit-Huguenin wrote: >>=20 >> Few more nits: >>=20 >> - Section 5.5.4.1 "typedef uint16 KindId;" >>=20 >> This contradicts section 13.6 that states that KindId are 32-bit = integers. >>=20 >> (Reported by St=E9phane Bryant) >>=20 >>=20 >>> I'm tempted to change the bits on the wire here--bigger seems = better. Obviously >>> this is a breaking change. Comments? >=20 > I am personally all for breaking compatibility between different = versions of an > I-D. You can make it easy for implementers by incrementing the minor = version in > the Forwarding header (i.e. 0x01-->0x02, and it will still be changed = to 0x0a > when published as an RFC). >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org From petithug@acm.org Tue Feb 8 16:09:22 2011 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 B2D2D3A68B1 for ; Tue, 8 Feb 2011 16:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.615 X-Spam-Level: X-Spam-Status: No, score=-101.615 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 D4UQkplbRoKA for ; Tue, 8 Feb 2011 16:09:22 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id F22193A6837 for ; Tue, 8 Feb 2011 16:09:21 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 2CFFFDBCC050; Wed, 9 Feb 2011 00:09:30 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 832B2DBCC04E; Wed, 9 Feb 2011 00:09:29 +0000 (UTC) Message-ID: <4D51DB38.1030104@acm.org> Date: Tue, 08 Feb 2011 16:09:28 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Cullen Jennings References: <4CE42CDF.4060804@acm.org> <4D35DC24.6030808@acm.org> <6D094D1B-8323-4C2A-8993-DB2D67B2B22E@cisco.com> In-Reply-To: <6D094D1B-8323-4C2A-8993-DB2D67B2B22E@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 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, 09 Feb 2011 00:09:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/08/2011 03:59 PM, Cullen Jennings wrote: > > Up to version 11, we only had the KindID described in the IANA registry section and it was defined as a 32 bit value. In version 12, we added the typedef for it as well but messed up and put 16 where it should have been 32. The IANA text in version 12 was still 32 bits. > > I think the kinds should be a 32 bit space. At first glance 16 bits might seem like enough but the more you think about it, we use these all over the place. A given application could use many kinds. It would be really bad to run out. The doc currently contradicts itself having them partially 32 and partially 16 but I think we should go with 32 bits as we had in version prior to version 12 of the draft. Agreed. We kept the KindId definition at 32 bit in the Wireshark dissector. > > > On Jan 18, 2011, at 11:29 AM, Marc Petit-Huguenin wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 01/18/2011 05:32 AM, Eric Rescorla wrote: >>> >>> On Nov 17, 2010, at 11:28 AM, Marc Petit-Huguenin wrote: >>> >>> Few more nits: >>> >>> - Section 5.5.4.1 "typedef uint16 KindId;" >>> >>> This contradicts section 13.6 that states that KindId are 32-bit integers. >>> >>> (Reported by Stéphane Bryant) >>> >>> >>>> I'm tempted to change the bits on the wire here--bigger seems better. Obviously >>>> this is a breaking change. Comments? >> >> I am personally all for breaking compatibility between different versions of an >> I-D. You can make it easy for implementers by incrementing the minor version in >> the Forwarding header (i.e. 0x01-->0x02, and it will still be changed to 0x0a >> when published as an RFC). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1R2zcACgkQ9RoMZyVa61frAACfaiHR0ipCLD+hOvmYZ8uQgQeS Ds0AnjlvEarEFMcpBR6FwDKcgfB1ytn1 =beUh -----END PGP SIGNATURE----- From ekr@skype.net Tue Feb 8 16:29:12 2011 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 E45973A6857 for ; Tue, 8 Feb 2011 16:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 GWwgFkITXzgj for ; Tue, 8 Feb 2011 16:29:12 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id E2E1C3A6837 for ; Tue, 8 Feb 2011 16:29:11 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id D0FEF170C; Wed, 9 Feb 2011 01:29:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=3T lZ3EztzHeny986PsUJzYoj4mQ=; b=V/QJeBkkk47KmzJH6IPDFXsAwy//048eka dIQ3dXfA0hmKSl9eImr34sUUvNmkrOqTVo1vEkLg5TAr56d4U9QZjQScoCJne6VE ejb3SiBSMTTassRgQ2Q8m9NNZO8tLm3FmNfZKQtEPmjiL7AbQsQfR3auQ39O6IBx Urq3EIfKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=mUJ4GaIuJmG1f8pRHxJ9YL 9St0WMzyfuZAsVFbxQRou0NoaDEtThxZUwSjEb2h5TQHStEvXZ6gjuoHOW+RQrEf FfLdluooBs6t023Ii3qSfXItEiUDMz4kVOJa21rxLrKdC9EGjaCKgLRszRMsJ3MX wWydC7iivHlNvQ8ROsVJo= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id CF4BE1708; Wed, 9 Feb 2011 01:29:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id A9F1D35075A6; Wed, 9 Feb 2011 01:29:18 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgfx-YkbKbYW; Wed, 9 Feb 2011 01:29:18 +0100 (CET) Received: from [192.168.129.32] (romeo.rtfm.com [74.95.2.173]) by zimbra.skype.net (Postfix) with ESMTPSA id 15D2C3507487; Wed, 9 Feb 2011 01:29:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Eric Rescorla In-Reply-To: <13BF6433-D1D8-4534-8038-DBDE2723298C@cisco.com> Date: Tue, 8 Feb 2011 16:31:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <695B2A8B-A271-4EAC-B305-D4A6B7F30051@skype.net> References: <4CFD5FCD.7060205@acm.org> <29353BE9-83FE-40C3-817F-6649AE09DF0C@skype.net> <4D35DA5D.7000804@acm.org> <4D4D7B9F.4080208@acm.org> <13BF6433-D1D8-4534-8038-DBDE2723298C@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1082) Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (3) 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, 09 Feb 2011 00:29:13 -0000 My general feeling is not to be too prescriptive on it. Let's define a = code and then say that you can go either way. Basically, there are two reasons why signatures can be = broken: damage in transit or=20 a bogus signature at the sender. It's hard to tell which is more = likely... -Ekr On Feb 8, 2011, at 3:51 PM, Cullen Jennings wrote: >=20 > On Feb 5, 2011, at 9:32 AM, Marc Petit-Huguenin wrote: >=20 >>=20 >> BTW I was not able to find text explaining what to do if the message = level >> signature fails. Should the message be dropped (and so be = retransmitted) or >> should an error be sent back? >=20 >=20 > The code I have seems like it just drops it but I don't really care = which way we decide to go on this.=20 >=20 >=20 From ekr@skype.net Tue Feb 8 17:09:37 2011 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 DCCA23A68E0 for ; Tue, 8 Feb 2011 17:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 r01eDQhaauPx for ; Tue, 8 Feb 2011 17:09:37 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id BCFC63A68D5 for ; Tue, 8 Feb 2011 17:09:36 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id BBEFE170B; Wed, 9 Feb 2011 02:09:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=rd QXD3GvxocnJ8Yaf94Z3nXD2d4=; b=aCyX02vb5tlgjYnIwq62QKU5Q0baWZQTki wwdLhz0v4gL2nccr/x8BkRphQ4GRPCtU3SJnOaszT4odYSwWIDtv50aLlkkrtOLe 74JEosSjCX6DBpvMWyCOdEokEyNoD+X9nnKJQpu05sqa1FEu8ozcqGK5hrKTK74X cYzyoQSPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=PwIWYJP11rs2w3EcxbxwOm xl5AGpiEHmPpXudpGMo/voEXT9Qfe10D2mBxF+9DmqvKECm2UJg+0t6Qoc1cHMDY EKki+RuVP3RRsG9J03l/FYsfvUGxHChRO6A1rBztTJIP4XHFSkLzUlBs/Ws3DTU+ wH7Wpl0kG6sfbC/d98108= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id B5C6D7F3; Wed, 9 Feb 2011 02:09:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 855DD3506F82; Wed, 9 Feb 2011 02:09:43 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOX+J781PrYG; Wed, 9 Feb 2011 02:09:42 +0100 (CET) Received: from [192.168.129.32] (romeo.rtfm.com [74.95.2.173]) by zimbra.skype.net (Postfix) with ESMTPSA id 397823506E22; Wed, 9 Feb 2011 02:09:40 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Eric Rescorla In-Reply-To: <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> Date: Tue, 8 Feb 2011 17:11:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1082) Cc: P2PSIP WG , Roni Even Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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, 09 Feb 2011 01:09:38 -0000 On Feb 8, 2011, at 3:48 PM, Cullen Jennings wrote: >=20 > On the topic of a flag to not keep state... just having a flag won't = work. It has to be an overlay option because all the nodes in the = overlay need to support it. Once you have it as an overlay option, you = don't need it in the base spec. I just don't see any reason to put it in = the base spec - it can be done in extension just as well - and I see = lots of reasons not to but it in the base spec. We don't really know how = to make this work well yet. Ideally it would be an optimization you used = when you could so that a client could still connect to a peer that would = do state and do the DDR for it. Saying something like the flag indicates = don't keep state breaks clients among other things. You would need the = option to be a little more nuanced than that. I think we should define = all of this in the DDR draft - trying to guess what we need before we = know what we are doing is likely to result in getting it wrong.=20 >=20 I don't think this is quite right: the issue isn't really whether all = nodes in the overlay support it but rather whether they support DRR. Here's my reasoning: a requester who uses this option is basically = committing to only receiving responses via DRR, since the Via List will not be unwindable by the responder. However, = because a requester has no real a priori way of knowing a responder's capability this means that any node in the = overlay must already support DRR because otherwise any intermediate or terminal node has no way of responding to = the request. So, this extension is only useful in an overlay in which everyone supports DRR; where it's = basically a way of indicating "use DRR only" and telling intermediaries they don't need to store state. However, with that said, it seems to me that the forward compatibility = issue goes away: if we do decide to use this flag to enable DRR, then all the nodes in the overlay will have to be = DRR-capable, at which point we can define this extension or similar at the time we define DRR. So while I had originally edited this extension into the draft, I have = now concluded we should remove it after all. Best, -Ekr From bbl@lowekamp.net Tue Feb 8 18:24:55 2011 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 4C3063A682F for ; Tue, 8 Feb 2011 18:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 G7vlj7-6-JNU for ; Tue, 8 Feb 2011 18:24:54 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 30E5E3A6841 for ; Tue, 8 Feb 2011 18:24:54 -0800 (PST) Received: by gxk27 with SMTP id 27so2692366gxk.31 for ; Tue, 08 Feb 2011 18:25:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.219.1 with SMTP id r1mr921199ybg.85.1297218302063; Tue, 08 Feb 2011 18:25:02 -0800 (PST) Received: by 10.150.97.1 with HTTP; Tue, 8 Feb 2011 18:25:02 -0800 (PST) In-Reply-To: <4D2B8BBE.3050303@acm.org> References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> Date: Tue, 8 Feb 2011 21:25:02 -0500 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2) 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, 09 Feb 2011 02:24:55 -0000 On Mon, Jan 10, 2011 at 5:44 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks for your responses. see below for more comments. > > On 01/07/2011 02:24 PM, Bruce Lowekamp wrote: >> inline >> >> On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin = wrote: >> More questions, comments and nits: >> > > [...] > >> >> - A.10. It seems that this version of RELOAD lacks the support of virtua= l >> servers (see draft-harjula-p2psip-loadbalancing-survey), more precisely = a way to >> share connections between two virtual servers on the same physical serve= r (see >> Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, >> Wide-area cooperative storage with CFS: "Use of virtual servers could >> potentially increase the number of hops in a Chord lookup. =C2=A0CFS avo= ids this >> expense by allowing virtual servers on the same physical server to exami= ne each >> others' tables: the fact that these virtual servers can take short-cuts = through >> each others' routing table exactly compensates for the increases number = of >> servers."). =C2=A0Because the certificates contains a list of Node-IDs, = it is not >> possible to know on a hop by hop basis what are the source and destinati= on >> NodeIds of a specific message. =C2=A0Section 3 of >> draft-rosenberg-dispatch-vipr-reload-usage seems to acknowledge that by = adding a >> PeerID Shim to exchange the source and destination peerIDs (aka Node-IDs= ). >> >> Because of this, it is probably a good idea to add in p2psip-base the >> possibility to know the source Node-ID and destination Node-ID of a mess= age. >> One way to do that would have be to have the sender of a message add its= own >> Node-ID in the via_list, and the Node-ID of the destination in the >> destination_list before sending a message (similar to what SIP is doing)= , but I >> guess that it is too late for such a modification. >> >> >>> I totally agree that vnodes should share routing state. =C2=A0But it's = not >>> clear to me what benefit would be obtained by making that sort of a >>> protocol change. >> >>> * on request routing, a message should normally have exactly one >>> destination node-id. =C2=A0The only reason to have more would be that t= he >>> request sender has some particular reason to want to source-route the >>> request. >>> * on response sending, with recursive response you simply want to >>> reverse the initial request routing. =C2=A0If there was an advantage to >>> "short-cutting" between v-nodes, it would have been done on the >>> request routing. =C2=A0 If you're not doing recursive response routing, >>> then this case is the same as request routing. > > Let's forget for now the solution I proposed. =C2=A0Do you agree that Sec= tion 3 of > draft-rosenberg-dispatch-vipr-reload-usage exposes a problem that would b= e worth > been solved in p2psip-base? I think we're merging two separate issues here: - how do you differentiate the sender of an end-to-end-message - how do you identify the multiple Node-IDs of an adjacent node For the first, I think SignerIdentity is the logical place. Using hash_alg, certificate_hash, and Node-ID would be sufficient. For adjacent nodes, I would rather encode it using an IceExtension in the Attach sequence that's already flowing than use a shim approach, particularly because it avoids issues with datagram protocols. I have mixed feelings on whether either of these should be in the base protocol. I really think that SignerIdentity should handle that case. But I think the support for multiple NodeIDs over a connection adds a lot of complexity and might be better as an extension. Bruce From bbl@lowekamp.net Tue Feb 8 18:41:55 2011 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 4D4893A681A for ; Tue, 8 Feb 2011 18:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 JeY7yPyPw0UM for ; Tue, 8 Feb 2011 18:41:54 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 39B243A6806 for ; Tue, 8 Feb 2011 18:41:54 -0800 (PST) Received: by gwb20 with SMTP id 20so2920088gwb.31 for ; Tue, 08 Feb 2011 18:42:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.136.6 with SMTP id j6mr868022ybd.142.1297219322210; Tue, 08 Feb 2011 18:42:02 -0800 (PST) Received: by 10.150.97.1 with HTTP; Tue, 8 Feb 2011 18:42:02 -0800 (PST) In-Reply-To: <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> Date: Tue, 8 Feb 2011 21:42:02 -0500 Message-ID: From: Bruce Lowekamp To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG , Roni Even Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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, 09 Feb 2011 02:41:55 -0000 On Tue, Feb 8, 2011 at 8:11 PM, Eric Rescorla wrote: > > On Feb 8, 2011, at 3:48 PM, Cullen Jennings wrote: > >> >> On the topic of a flag to not keep state... just having a flag won't wor= k. It has to be an overlay option because all the nodes in the overlay need= to support it. Once you have it as an overlay option, you don't need it in= the base spec. I just don't see any reason to put it in the base spec - it= can be done in extension just as well - and I see lots of reasons not to b= ut it in the base spec. We don't really know how to make this work well yet= . Ideally it would be an optimization you used when you could so that a cli= ent could still connect to a peer that would do state and do the DDR for it= . Saying something like the flag indicates don't keep state breaks clients = among other things. You would need the option to be a little more nuanced t= han that. I think we should define all of this in the DDR draft - trying to= guess what we need before we know what we are doing is likely to result in= getting it wrong. >> > > > I don't think this is quite right: the issue isn't really whether all nod= es in the overlay support it but rather whether > they support DRR. > > Here's my reasoning: a requester who uses this option is basically commit= ting to only receiving responses via DRR, > since the Via List will not be unwindable by the responder. However, beca= use a requester has no real a priori way > of knowing a responder's capability this means that any node in the overl= ay must already support DRR because > otherwise any intermediate or terminal node has no way of responding to t= he request. So, this extension is > only useful in an overlay in which everyone supports DRR; where it's basi= cally a way of indicating "use DRR only" > and telling intermediaries they don't need to store state. > I don't think this is what is proposed here. DRR requires the sender and receiver to support it. The no-state flag simply indicates that the intermediate peer should not keep internal state (i.e. use a compressed id, etc). It can forward the message by adding itself to the via-list as normal. Now an intermediate peer that was aware of DRR could know that adding itself to the via-list is unnecessary and not do it. But I think that should be left to the extension. And for DRR, in particular, the nodes need to be prepared for the response to be dropped regardless of whether they both support the extension, so presumably any such extension would specify a fallback to normal routing on retransmissions of the original request. Certainly we need a draft that fully specifies DRR and eventually other routing options. But I don't believe it's true that all nodes need to support it. On the contrary, if we don't have the flag then all nodes (at least routing peers) would need to support DRR, but if we do have the flag then DRR can be implemented to work between any two nodes that support it. Bruce > However, with that said, it seems to me that the forward compatibility is= sue goes away: if we do decide to use this > flag to enable DRR, then all the nodes in the overlay will have to be DRR= -capable, at which point we can define > this extension or similar at the time we define DRR. > > So while I had originally edited this extension into the draft, I have no= w concluded we should remove it after > all. > > Best, > -Ekr > > From ekr@skype.net Tue Feb 8 21:01:25 2011 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 2A4723A68F2 for ; Tue, 8 Feb 2011 21:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 yYFq4DgnkGU4 for ; Tue, 8 Feb 2011 21:01:23 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 19C693A68ED for ; Tue, 8 Feb 2011 21:01:22 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id EA6DA170D; Wed, 9 Feb 2011 06:01:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=6I qmue0tjUDY+vyb0FT5FhlUCQo=; b=jHXmsFEd8BFGA+6W+jHIWRlsuGifUX+nGJ jLwzfNEb1r1WQLYftF1RniFTG/+2YrN0PAXCIiqyFIaEJOzGSh/YHD7RjzH+ZWtj mBbELz0pQKlg5kz6jxqUwXkC7tH/+sEDIq5g4ckmfQe4ek2xa6zS4ovhSDwvdElc qJLjLCMaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=oE3O9B2r3IOdFbs2tJJPzO 6StwjkvzhApVvG2hnWmemvHBV0LH1yJA1DOveQxczBwN48XteH+BC/CWqR71xSM/ 5io6A7Yb6+wqVCjg/DoP/3yK6K3prhpQplKQ2kmOwBkOkpW0yjTz622IrpMGPl/K xWMagimD1pwF0Bn8B7B+0= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id E88787F3; Wed, 9 Feb 2011 06:01:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id C4AD435073DA; Wed, 9 Feb 2011 06:01:29 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMeVbasEmhi6; Wed, 9 Feb 2011 06:01:28 +0100 (CET) Received: from [192.168.1.103] (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by zimbra.skype.net (Postfix) with ESMTPSA id 63CF43507259; Wed, 9 Feb 2011 06:01:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Eric Rescorla In-Reply-To: Date: Tue, 8 Feb 2011 21:04:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> To: Bruce Lowekamp X-Mailer: Apple Mail (2.1082) Cc: P2PSIP WG , Roni Even Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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, 09 Feb 2011 05:01:25 -0000 On Feb 8, 2011, at 6:42 PM, Bruce Lowekamp wrote: > On Tue, Feb 8, 2011 at 8:11 PM, Eric Rescorla wrote: >>=20 >> On Feb 8, 2011, at 3:48 PM, Cullen Jennings wrote: >>=20 >>>=20 >>> On the topic of a flag to not keep state... just having a flag won't = work. It has to be an overlay option because all the nodes in the = overlay need to support it. Once you have it as an overlay option, you = don't need it in the base spec. I just don't see any reason to put it in = the base spec - it can be done in extension just as well - and I see = lots of reasons not to but it in the base spec. We don't really know how = to make this work well yet. Ideally it would be an optimization you used = when you could so that a client could still connect to a peer that would = do state and do the DDR for it. Saying something like the flag indicates = don't keep state breaks clients among other things. You would need the = option to be a little more nuanced than that. I think we should define = all of this in the DDR draft - trying to guess what we need before we = know what we are doing is likely to result in getting it wrong. >>>=20 >>=20 >>=20 >> I don't think this is quite right: the issue isn't really whether all = nodes in the overlay support it but rather whether >> they support DRR. >>=20 >> Here's my reasoning: a requester who uses this option is basically = committing to only receiving responses via DRR, >> since the Via List will not be unwindable by the responder. However, = because a requester has no real a priori way >> of knowing a responder's capability this means that any node in the = overlay must already support DRR because >> otherwise any intermediate or terminal node has no way of responding = to the request. So, this extension is >> only useful in an overlay in which everyone supports DRR; where it's = basically a way of indicating "use DRR only" >> and telling intermediaries they don't need to store state. >>=20 >=20 > I don't think this is what is proposed here. DRR requires the sender > and receiver to support it. The no-state flag simply indicates that > the intermediate peer should not keep internal state (i.e. use a > compressed id, etc). Right now, there isn't a no-state flag, so I think what it indicates is = what's at question here. The no-state flag in the version I checked in meant=20 that there was not going to be a response and so no state should be kept of any kind. > It can forward the message by adding itself to > the via-list as normal. I'm not sure this is "normal". It's one of several options, that as far = as I know of have no preference ranking in the draft. I'm very uncomfortable with = creating a flag that affects only one mechanism for symmetric return routing. > And for DRR, in particular, the nodes need to be prepared for the > response to be dropped regardless of whether they both support the > extension, so presumably any such extension would specify a fallback > to normal routing on retransmissions of the original request. >=20 Really? Why would you think that? All sorts of things can go wrong that = don't indicate that reverse routing is the problem. > Certainly we need a draft that fully specifies DRR and eventually > other routing options. But I don't believe it's true that all nodes > need to support it. On the contrary, if we don't have the flag then > all nodes (at least routing peers) would need to support DRR, but if > we do have the flag then DRR can be implemented to work between any > two nodes that support it. With no discovery mechanism, I don't see how this is useful, which is = why the DRR mechanism we just removed required universal support in the overlay. -Ekr >> However, with that said, it seems to me that the forward = compatibility issue goes away: if we do decide to use this >> flag to enable DRR, then all the nodes in the overlay will have to be = DRR-capable, at which point we can define >> this extension or similar at the time we define DRR. >>=20 >> So while I had originally edited this extension into the draft, I = have now concluded we should remove it after >> all. >>=20 >> Best, >> -Ekr >>=20 >>=20 From Even.roni@huawei.com Wed Feb 9 01:50:05 2011 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 833623A696E for ; Wed, 9 Feb 2011 01:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 2eCLR8cFUuks for ; Wed, 9 Feb 2011 01:50:04 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id A8DFE3A696D for ; Wed, 9 Feb 2011 01:50:02 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGC00CGSGJX3I@szxga05-in.huawei.com> for p2psip@ietf.org; Wed, 09 Feb 2011 17:47:57 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGC001TKGJW3H@szxga05-in.huawei.com> for p2psip@ietf.org; Wed, 09 Feb 2011 17:47:57 +0800 (CST) Received: from windows8d787f9 (bzq-109-67-8-53.red.bezeqint.net [109.67.8.53]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGC002BLGJMNO@szxml01-in.huawei.com>; Wed, 09 Feb 2011 17:47:56 +0800 (CST) Date: Wed, 09 Feb 2011 11:43:39 +0200 From: Roni Even In-reply-to: <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> To: 'Eric Rescorla' , 'Cullen Jennings' Message-id: <01be01cbc83d$db453fe0$91cfbfa0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvH9hId7Yv8PZncTsalzQHofoVhPQARRcjg References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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, 09 Feb 2011 09:50:05 -0000 Hi Guys, I am not sure I understand your points. I would like to describe again the DRR proposal in draft-jiang-p2psip-relay-04 and explain the status keeping flag. The DRR proposal proposes to add a new forwarding option for an extensive routing mode that will supply the information that will allow the destination peer to connect directly back to the requestor to establish a DRR mode. So this still allows the receiver to use SRR if it does not support DRR. Note that the new forwarding option must include all the information needed to support the DRR or Relay mode. The issue with the state keeping flag in my view is to try to address the issue where according to the base draft as describe at the figure at the end of section 3.3 where the intermediary node keep the state of the via list expecting the response to go back via itself, note that the flag only recommends to the intermediary that it may not be useful to change the via list but it does not change the via list. If DRR is preferred, the flag means that it is not required to keep state. On the other hand I think that the solution will work even without the flag since there is timeout for the response, the intermediary will delete the state after the timeout but having the flag will make it cleaner. Regards Roni Even > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Wednesday, February 09, 2011 3:12 AM > To: Cullen Jennings > Cc: P2PSIP WG; Roni Even > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from > meeting - DRR > > > On Feb 8, 2011, at 3:48 PM, Cullen Jennings wrote: > > > > > On the topic of a flag to not keep state... just having a flag won't > work. It has to be an overlay option because all the nodes in the > overlay need to support it. Once you have it as an overlay option, you > don't need it in the base spec. I just don't see any reason to put it > in the base spec - it can be done in extension just as well - and I see > lots of reasons not to but it in the base spec. We don't really know > how to make this work well yet. Ideally it would be an optimization you > used when you could so that a client could still connect to a peer that > would do state and do the DDR for it. Saying something like the flag > indicates don't keep state breaks clients among other things. You would > need the option to be a little more nuanced than that. I think we > should define all of this in the DDR draft - trying to guess what we > need before we know what we are doing is likely to result in getting it > wrong. > > > > > I don't think this is quite right: the issue isn't really whether all > nodes in the overlay support it but rather whether > they support DRR. > > Here's my reasoning: a requester who uses this option is basically > committing to only receiving responses via DRR, > since the Via List will not be unwindable by the responder. However, > because a requester has no real a priori way > of knowing a responder's capability this means that any node in the > overlay must already support DRR because > otherwise any intermediate or terminal node has no way of responding to > the request. So, this extension is > only useful in an overlay in which everyone supports DRR; where it's > basically a way of indicating "use DRR only" > and telling intermediaries they don't need to store state. > > However, with that said, it seems to me that the forward compatibility > issue goes away: if we do decide to use this > flag to enable DRR, then all the nodes in the overlay will have to be > DRR-capable, at which point we can define > this extension or similar at the time we define DRR. > > So while I had originally edited this extension into the draft, I have > now concluded we should remove it after > all. > > Best, > -Ekr > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Wed Feb 9 08:44:19 2011 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 5A1053A65A5 for ; Wed, 9 Feb 2011 08:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.832 X-Spam-Level: X-Spam-Status: No, score=-101.832 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 QNGLhRhFTeIh for ; Wed, 9 Feb 2011 08:44:18 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 387AF3A63CA for ; Wed, 9 Feb 2011 08:44:17 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 532D7DBCC052; Wed, 9 Feb 2011 16:44:22 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 91A1BDBCC050; Wed, 9 Feb 2011 16:44:21 +0000 (UTC) Message-ID: <4D52C465.6020807@acm.org> Date: Wed, 09 Feb 2011 08:44:21 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2) 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, 09 Feb 2011 16:44:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/08/2011 06:25 PM, Bruce Lowekamp wrote: > On Mon, Jan 10, 2011 at 5:44 PM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Thanks for your responses. see below for more comments. >> >> On 01/07/2011 02:24 PM, Bruce Lowekamp wrote: >>> inline >>> >>> On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin wrote: >>> More questions, comments and nits: >>> >> >> [...] >> >>> >>> - A.10. It seems that this version of RELOAD lacks the support of virtual >>> servers (see draft-harjula-p2psip-loadbalancing-survey), more precisely a way to >>> share connections between two virtual servers on the same physical server (see >>> Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, >>> Wide-area cooperative storage with CFS: "Use of virtual servers could >>> potentially increase the number of hops in a Chord lookup. CFS avoids this >>> expense by allowing virtual servers on the same physical server to examine each >>> others' tables: the fact that these virtual servers can take short-cuts through >>> each others' routing table exactly compensates for the increases number of >>> servers."). Because the certificates contains a list of Node-IDs, it is not >>> possible to know on a hop by hop basis what are the source and destination >>> NodeIds of a specific message. Section 3 of >>> draft-rosenberg-dispatch-vipr-reload-usage seems to acknowledge that by adding a >>> PeerID Shim to exchange the source and destination peerIDs (aka Node-IDs). >>> >>> Because of this, it is probably a good idea to add in p2psip-base the >>> possibility to know the source Node-ID and destination Node-ID of a message. >>> One way to do that would have be to have the sender of a message add its own >>> Node-ID in the via_list, and the Node-ID of the destination in the >>> destination_list before sending a message (similar to what SIP is doing), but I >>> guess that it is too late for such a modification. >>> >>> >>>> I totally agree that vnodes should share routing state. But it's not >>>> clear to me what benefit would be obtained by making that sort of a >>>> protocol change. >>> >>>> * on request routing, a message should normally have exactly one >>>> destination node-id. The only reason to have more would be that the >>>> request sender has some particular reason to want to source-route the >>>> request. >>>> * on response sending, with recursive response you simply want to >>>> reverse the initial request routing. If there was an advantage to >>>> "short-cutting" between v-nodes, it would have been done on the >>>> request routing. If you're not doing recursive response routing, >>>> then this case is the same as request routing. >> >> Let's forget for now the solution I proposed. Do you agree that Section 3 of >> draft-rosenberg-dispatch-vipr-reload-usage exposes a problem that would be worth >> been solved in p2psip-base? > > I think we're merging two separate issues here: > > - how do you differentiate the sender of an end-to-end-message > - how do you identify the multiple Node-IDs of an adjacent node > > For the first, I think SignerIdentity is the logical place. Using > hash_alg, certificate_hash, and Node-ID would be sufficient. I agree, with one caveat: If the sender of the message is also an adjacent node, and the extension described below is not implemented, then { hash_alg, certificate_hash, Node-ID } does not permit to differentiate the sender if there is multiple Node-IDs in the certificate. This is because the Via is added by the receiving node instead of the sending node. > > For adjacent nodes, I would rather encode it using an IceExtension in > the Attach sequence that's already flowing than use a shim approach, > particularly because it avoids issues with datagram protocols. OK. I still think that having 1) each node adding the Via before sending (instead of by the receiving node), 2) all nodes adding the next hop on top of the destination_list before forwarding and 3) the receiving node dropping the first node in the destination_list before applying the routing algorithm would have been a better solution. > > I have mixed feelings on whether either of these should be in the base > protocol. I really think that SignerIdentity should handle that case. > But I think the support for multiple NodeIDs over a connection adds a > lot of complexity and might be better as an extension. Well, I am willing to write immediately the I-D for such extension (because my implementation is using multiple Node-IDs per certificate), so let me know if this is the way to go. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1SxGMACgkQ9RoMZyVa61dG/QCcC1Kl6ELen4VzE3rJGgfl0F8R 5PIAoKeX3u87MSGiUpthSqnHY/Emvrhz =6AGB -----END PGP SIGNATURE----- From ekr@skype.net Wed Feb 9 09:17:23 2011 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 F135C3A67C2 for ; Wed, 9 Feb 2011 09:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 wzFN3jvqQABN for ; Wed, 9 Feb 2011 09:17:22 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 7BFE93A67A5 for ; Wed, 9 Feb 2011 09:17:22 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 4C9401710; Wed, 9 Feb 2011 18:17:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=4/ LqgypKRRxxuZwWgbxMRBp++/0=; b=KhOWYnQtgZ7o41YhQvAF1o7kYHS/MNSTT2 fCGTCSzBqnzkHOS2MEoLuAIc2bVKY3PJ7z/ImXNqQf6eWbCt3PZ56ADeeOn1yBN3 U7zIJhfsZKs2Mawc8lKamJQFzICqXIe4roUSyIswE6PqhLnwgXbCZ4oS7xlGUGRY tqw/7TD7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=ChQhPzU1FjlbyoVkx0CtSf pSrD4tRWVHN+9JCMAzGCrsgRSvs4JNdrQqeEPD7KFDFXnT2N0tQWoJOQR8+xs7sU L/k+dsO7AVo02K7j4wmCKBNjcsuatbcDfR5HzQM8vJ0n8mxLT/Jpn6n+R1TiEnMR mLfJcDxtgzrdRhiYQf9uc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 4A1427F3; Wed, 9 Feb 2011 18:17:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 1367D1678D06; Wed, 9 Feb 2011 18:17:30 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI0oeYokQh2a; Wed, 9 Feb 2011 18:17:28 +0100 (CET) Received: from tango.rtfm.com.pao.office.skype.net (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id 8C9D41672684; Wed, 9 Feb 2011 18:17:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Eric Rescorla In-Reply-To: <01be01cbc83d$db453fe0$91cfbfa0$%roni@huawei.com> Date: Wed, 9 Feb 2011 09:20:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> <01be01cbc83d$db453fe0$91cfbfa0$%roni@huawei.com> To: Roni Even X-Mailer: Apple Mail (2.1082) Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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, 09 Feb 2011 17:17:24 -0000 Yes, I understand this argument. My point is that you need to make symmetric return routing work in any = case, which means you need to do whatever you do to the via list to make that work, so that this flag doesn't work. -Ekr On Feb 9, 2011, at 1:43 AM, Roni Even wrote: > Hi Guys, > I am not sure I understand your points. I would like to describe again = the > DRR proposal in draft-jiang-p2psip-relay-04 and explain the status = keeping > flag. >=20 > The DRR proposal proposes to add a new forwarding option for an = extensive > routing mode that will supply the information that will allow the > destination peer to connect directly back to the requestor to = establish a > DRR mode. So this still allows the receiver to use SRR if it does not > support DRR. Note that the new forwarding option must include all the > information needed to support the DRR or Relay mode. > The issue with the state keeping flag in my view is to try to address = the > issue where according to the base draft as describe at the figure at = the end > of section 3.3 where the intermediary node keep the state of the via = list > expecting the response to go back via itself, note that the flag only > recommends to the intermediary that it may not be useful to change the = via > list but it does not change the via list. If DRR is preferred, the = flag > means that it is not required to keep state. On the other hand I think = that > the solution will work even without the flag since there is timeout = for the > response, the intermediary will delete the state after the timeout but > having the flag will make it cleaner.=20 >=20 >=20 > Regards > Roni Even >=20 >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >> Behalf Of Eric Rescorla >> Sent: Wednesday, February 09, 2011 3:12 AM >> To: Cullen Jennings >> Cc: P2PSIP WG; Roni Even >> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft = from >> meeting - DRR >>=20 >>=20 >> On Feb 8, 2011, at 3:48 PM, Cullen Jennings wrote: >>=20 >>>=20 >>> On the topic of a flag to not keep state... just having a flag won't >> work. It has to be an overlay option because all the nodes in the >> overlay need to support it. Once you have it as an overlay option, = you >> don't need it in the base spec. I just don't see any reason to put it >> in the base spec - it can be done in extension just as well - and I = see >> lots of reasons not to but it in the base spec. We don't really know >> how to make this work well yet. Ideally it would be an optimization = you >> used when you could so that a client could still connect to a peer = that >> would do state and do the DDR for it. Saying something like the flag >> indicates don't keep state breaks clients among other things. You = would >> need the option to be a little more nuanced than that. I think we >> should define all of this in the DDR draft - trying to guess what we >> need before we know what we are doing is likely to result in getting = it >> wrong. >>>=20 >>=20 >>=20 >> I don't think this is quite right: the issue isn't really whether all >> nodes in the overlay support it but rather whether >> they support DRR. >>=20 >> Here's my reasoning: a requester who uses this option is basically >> committing to only receiving responses via DRR, >> since the Via List will not be unwindable by the responder. However, >> because a requester has no real a priori way >> of knowing a responder's capability this means that any node in the >> overlay must already support DRR because >> otherwise any intermediate or terminal node has no way of responding = to >> the request. So, this extension is >> only useful in an overlay in which everyone supports DRR; where it's >> basically a way of indicating "use DRR only" >> and telling intermediaries they don't need to store state. >>=20 >> However, with that said, it seems to me that the forward = compatibility >> issue goes away: if we do decide to use this >> flag to enable DRR, then all the nodes in the overlay will have to be >> DRR-capable, at which point we can define >> this extension or similar at the time we define DRR. >>=20 >> So while I had originally edited this extension into the draft, I = have >> now concluded we should remove it after >> all. >>=20 >> Best, >> -Ekr >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >=20 From Even.roni@huawei.com Wed Feb 9 11:35:30 2011 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 7D9003A69E2 for ; Wed, 9 Feb 2011 11:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 7u5kqeck6zso for ; Wed, 9 Feb 2011 11:35:29 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 23D6C3A69F5 for ; Wed, 9 Feb 2011 11:35:29 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGD00ARV7R454@szxga05-in.huawei.com> for p2psip@ietf.org; Thu, 10 Feb 2011 03:35:29 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGD0038B7R46W@szxga05-in.huawei.com> for p2psip@ietf.org; Thu, 10 Feb 2011 03:35:28 +0800 (CST) Received: from windows8d787f9 (bzq-109-67-8-53.red.bezeqint.net [109.67.8.53]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGD004ZO7QYTG@szxml02-in.huawei.com>; Thu, 10 Feb 2011 03:35:28 +0800 (CST) Date: Wed, 09 Feb 2011 21:31:19 +0200 From: Roni Even In-reply-to: To: 'Eric Rescorla' Message-id: <003a01cbc88f$f1097b00$d31c7100$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvIfUXv8eZmvx8CQXmUU5xZtYEreAAEmdfw References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> <01be01cbc83d$db453fe0$91cfbfa0$%roni@huawei.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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, 09 Feb 2011 19:35:30 -0000 EKR, I am not sure why the flag does not work for symmetric return, state keeping by intermediaries is optional according to section 3.3 and is not required for it to work. Roni > -----Original Message----- > From: Eric Rescorla [mailto:ekr@skype.net] > Sent: Wednesday, February 09, 2011 7:20 PM > To: Roni Even > Cc: 'Cullen Jennings'; 'P2PSIP WG' > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from > meeting - DRR > > Yes, I understand this argument. > > My point is that you need to make symmetric return routing work in any > case, > which means you need to do whatever you do to the via list to make that > work, so that this flag doesn't work. > > -Ekr > > On Feb 9, 2011, at 1:43 AM, Roni Even wrote: > > > Hi Guys, > > I am not sure I understand your points. I would like to describe > again the > > DRR proposal in draft-jiang-p2psip-relay-04 and explain the status > keeping > > flag. > > > > The DRR proposal proposes to add a new forwarding option for an > extensive > > routing mode that will supply the information that will allow the > > destination peer to connect directly back to the requestor to > establish a > > DRR mode. So this still allows the receiver to use SRR if it does not > > support DRR. Note that the new forwarding option must include all the > > information needed to support the DRR or Relay mode. > > The issue with the state keeping flag in my view is to try to address > the > > issue where according to the base draft as describe at the figure at > the end > > of section 3.3 where the intermediary node keep the state of the via > list > > expecting the response to go back via itself, note that the flag only > > recommends to the intermediary that it may not be useful to change > the via > > list but it does not change the via list. If DRR is preferred, the > flag > > means that it is not required to keep state. On the other hand I > think that > > the solution will work even without the flag since there is timeout > for the > > response, the intermediary will delete the state after the timeout > but > > having the flag will make it cleaner. > > > > > > Regards > > Roni Even > > > >> -----Original Message----- > >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > >> Behalf Of Eric Rescorla > >> Sent: Wednesday, February 09, 2011 3:12 AM > >> To: Cullen Jennings > >> Cc: P2PSIP WG; Roni Even > >> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft > from > >> meeting - DRR > >> > >> > >> On Feb 8, 2011, at 3:48 PM, Cullen Jennings wrote: > >> > >>> > >>> On the topic of a flag to not keep state... just having a flag > won't > >> work. It has to be an overlay option because all the nodes in the > >> overlay need to support it. Once you have it as an overlay option, > you > >> don't need it in the base spec. I just don't see any reason to put > it > >> in the base spec - it can be done in extension just as well - and I > see > >> lots of reasons not to but it in the base spec. We don't really know > >> how to make this work well yet. Ideally it would be an optimization > you > >> used when you could so that a client could still connect to a peer > that > >> would do state and do the DDR for it. Saying something like the flag > >> indicates don't keep state breaks clients among other things. You > would > >> need the option to be a little more nuanced than that. I think we > >> should define all of this in the DDR draft - trying to guess what we > >> need before we know what we are doing is likely to result in getting > it > >> wrong. > >>> > >> > >> > >> I don't think this is quite right: the issue isn't really whether > all > >> nodes in the overlay support it but rather whether > >> they support DRR. > >> > >> Here's my reasoning: a requester who uses this option is basically > >> committing to only receiving responses via DRR, > >> since the Via List will not be unwindable by the responder. However, > >> because a requester has no real a priori way > >> of knowing a responder's capability this means that any node in the > >> overlay must already support DRR because > >> otherwise any intermediate or terminal node has no way of responding > to > >> the request. So, this extension is > >> only useful in an overlay in which everyone supports DRR; where it's > >> basically a way of indicating "use DRR only" > >> and telling intermediaries they don't need to store state. > >> > >> However, with that said, it seems to me that the forward > compatibility > >> issue goes away: if we do decide to use this > >> flag to enable DRR, then all the nodes in the overlay will have to > be > >> DRR-capable, at which point we can define > >> this extension or similar at the time we define DRR. > >> > >> So while I had originally edited this extension into the draft, I > have > >> now concluded we should remove it after > >> all. > >> > >> Best, > >> -Ekr > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip > > From ekr@skype.net Wed Feb 9 11:39:28 2011 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 9A5013A6838 for ; Wed, 9 Feb 2011 11:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 BH+fkQNc06-T for ; Wed, 9 Feb 2011 11:39:27 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 91F933A69ED for ; Wed, 9 Feb 2011 11:39:27 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id EF2AD1713; Wed, 9 Feb 2011 20:39:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=2g F3ymZORgteiusDe0/zotnKYlA=; b=hYqHilQcieHmbUaf9k3EJzCg7gH0/N8HIc OvWOWzQrWZ7eX9Hq7Xxj79LmO8fRzOI2pb7r8bF3essSeGfz/zfy767sCReDdhr3 v48IG1R71UOdKqiYYlzT+OFmo85W/oQBI3810rl4P5B3iAIPTYbcOBhSJoUHULMj ZYAkJImyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=gTeSSoOAhxk5jo5Y3PApC6 Ka6Nh3+7v8rRLTktpdPOFr6AdjhmsvpEbktEnodcXE8da0bQ+Z/uIgGBLDiXPWof gqOP6qeaBFppQCsXQCCfCBcxsHapVAzfWL6lnWGre3cf0XYrn0kTL+JMu+grFMR6 aheMrIAIqHazf7N5cxRFg= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id ED96F1712; Wed, 9 Feb 2011 20:39:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id CC529350798A; Wed, 9 Feb 2011 20:39:36 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hdH-Tu2soRv; Wed, 9 Feb 2011 20:39:36 +0100 (CET) Received: from tango.rtfm.com.pao.office.skype.net (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id 7C4663507517; Wed, 9 Feb 2011 20:39:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Eric Rescorla In-Reply-To: <003a01cbc88f$f1097b00$d31c7100$%roni@huawei.com> Date: Wed, 9 Feb 2011 11:42:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <481E65B9-A508-4E33-AC61-D06617CD5314@skype.net> References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> <01be01cbc83d$db453fe0$91cfbfa0$%roni@huawei.com> <003a01cbc88f$f1097b00$d31c7100$%roni@huawei.com> To: Roni Even X-Mailer: Apple Mail (2.1082) Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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, 09 Feb 2011 19:39:28 -0000 On Feb 9, 2011, at 11:31 AM, Roni Even wrote: > EKR, > I am not sure why the flag does not work for symmetric return, state > keeping by intermediaries is optional according to section 3.3 and is = not > required for it to work. The intermediary's job is to keep the via list in a state where it is = unwindable. It is a purely local matter how it does so. It's not reasonable to tell = intermediaries who would otherwise keep state that they must instead modify the via = list to include the full unwind path. -Ekr From Even.roni@huawei.com Wed Feb 9 14:08:10 2011 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 8EFE43A6839 for ; Wed, 9 Feb 2011 14:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 ocOFA7VdJMfF for ; Wed, 9 Feb 2011 14:08:09 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A36413A6823 for ; Wed, 9 Feb 2011 14:08:09 -0800 (PST) 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 <0LGD00DB4ETF0E@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 10 Feb 2011 06:08:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGD00422ETF6C@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 10 Feb 2011 06:08:03 +0800 (CST) Received: from windows8d787f9 ([109.67.8.53]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGD00JW8ET8RU@szxml02-in.huawei.com>; Thu, 10 Feb 2011 06:08:03 +0800 (CST) Date: Thu, 10 Feb 2011 00:03:53 +0200 From: Roni Even In-reply-to: <481E65B9-A508-4E33-AC61-D06617CD5314@skype.net> To: 'Eric Rescorla' Message-id: <007b01cbc8a5$41e84050$c5b8c0f0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvIkRgUvtpWZf8qTCq/Zy+tbcQr6gAE2HaA References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> <01be01cbc83d$db453fe0$91cfbfa0$%roni@huawei.com> <003a01cbc88f$f1097b00$d31c7100$%roni@huawei.com> <481E65B9-A508-4E33-AC61-D06617CD5314@skype.net> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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, 09 Feb 2011 22:08:10 -0000 Hi, I see what EKR means but I think that there is some inconsistency in section 3.3. The requirement says: "Low state: RELOAD's routing algorithms must not require significant state to be stored on intermediate peers." Yet when talking about state keeping later in the section it says what EKR points out "This option requires greater state to be stored on intermediate peers but saves a small amount of bandwidth and reduces the need for modifying the message en route. Selection of this mode of operation is a choice for the individual peer;" I think that maybe this should be changed and that the selection of this mode whould be allowed by overlay configuration and may be overridden by a flag. I am not sure why an intermediary should decide on the via list content. Roni Even > -----Original Message----- > From: Eric Rescorla [mailto:ekr@skype.net] > Sent: Wednesday, February 09, 2011 9:42 PM > To: Roni Even > Cc: 'Cullen Jennings'; 'P2PSIP WG' > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from > meeting - DRR > > > On Feb 9, 2011, at 11:31 AM, Roni Even wrote: > > > EKR, > > I am not sure why the flag does not work for symmetric return, state > > keeping by intermediaries is optional according to section 3.3 and is > not > > required for it to work. > > The intermediary's job is to keep the via list in a state where it is > unwindable. It > is a purely local matter how it does so. It's not reasonable to tell > intermediaries > who would otherwise keep state that they must instead modify the via > list to > include the full unwind path. > > -Ekr From bbl@lowekamp.net Sun Feb 13 17:03:44 2011 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 2044D3A6C2F for ; Sun, 13 Feb 2011 17:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 0bcpQ7g4g7Op for ; Sun, 13 Feb 2011 17:03:42 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3B3643A6C0B for ; Sun, 13 Feb 2011 17:03:42 -0800 (PST) Received: by iwc10 with SMTP id 10so4584297iwc.31 for ; Sun, 13 Feb 2011 17:04:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.228.68 with SMTP id jd4mr4126559icb.499.1297645442325; Sun, 13 Feb 2011 17:04:02 -0800 (PST) Received: by 10.42.224.70 with HTTP; Sun, 13 Feb 2011 17:04:02 -0800 (PST) In-Reply-To: <4D52C465.6020807@acm.org> References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> Date: Sun, 13 Feb 2011 20:04:02 -0500 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Cc: P2PSIP WG Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2) 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, 14 Feb 2011 01:03:44 -0000 Marc, I think there's an underlying issue here of whether it's important to - use the same "physical" connection between two physical nodes that are both acting as multiple virtual nodes for all pairs of connectivity between them AND - differentiate on the receipt of a message what pair of virtual nodes A'->B' the original sender believed the message was going between. I'm not immediately convinced that this is a useful property for the routing system, as if each physical node is merging the virtual nodes' routing tables and forwarding to the closest match, I don't think it's necessary for reliable routing. However, if you have a pointer to a description of why this would be useful, I'd be very interested in reading it. With that said, my current opinion is that what you want to accomplish can and should be accomplished through a new routing algorithm. However, I think we should move to incorporate the new SignerIdentity into the base draft and probably handle the IceExtension as a new draft. But both should probably get a thread of their own so they have more eyes. More comments inline On Wed, Feb 9, 2011 at 11:44 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/08/2011 06:25 PM, Bruce Lowekamp wrote: >> On Mon, Jan 10, 2011 at 5:44 PM, Marc Petit-Huguenin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Thanks for your responses. see below for more comments. >>> >>> On 01/07/2011 02:24 PM, Bruce Lowekamp wrote: >>>> inline >>>> >>>> On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin wrote: >>>> More questions, comments and nits: >>>> >>> >>> [...] >>> >>>> >>>> - A.10. It seems that this version of RELOAD lacks the support of virtual >>>> servers (see draft-harjula-p2psip-loadbalancing-survey), more precisely a way to >>>> share connections between two virtual servers on the same physical server (see >>>> Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, >>>> Wide-area cooperative storage with CFS: "Use of virtual servers could >>>> potentially increase the number of hops in a Chord lookup. CFS avoids this >>>> expense by allowing virtual servers on the same physical server to examine each >>>> others' tables: the fact that these virtual servers can take short-cuts through >>>> each others' routing table exactly compensates for the increases number of >>>> servers."). Because the certificates contains a list of Node-IDs, it is not >>>> possible to know on a hop by hop basis what are the source and destination >>>> NodeIds of a specific message. Section 3 of >>>> draft-rosenberg-dispatch-vipr-reload-usage seems to acknowledge that by adding a >>>> PeerID Shim to exchange the source and destination peerIDs (aka Node-IDs). >>>> >>>> Because of this, it is probably a good idea to add in p2psip-base the >>>> possibility to know the source Node-ID and destination Node-ID of a message. >>>> One way to do that would have be to have the sender of a message add its own >>>> Node-ID in the via_list, and the Node-ID of the destination in the >>>> destination_list before sending a message (similar to what SIP is doing), but I >>>> guess that it is too late for such a modification. >>>> >>>> >>>>> I totally agree that vnodes should share routing state. But it's not >>>>> clear to me what benefit would be obtained by making that sort of a >>>>> protocol change. >>>> >>>>> * on request routing, a message should normally have exactly one >>>>> destination node-id. The only reason to have more would be that the >>>>> request sender has some particular reason to want to source-route the >>>>> request. >>>>> * on response sending, with recursive response you simply want to >>>>> reverse the initial request routing. If there was an advantage to >>>>> "short-cutting" between v-nodes, it would have been done on the >>>>> request routing. If you're not doing recursive response routing, >>>>> then this case is the same as request routing. >>> >>> Let's forget for now the solution I proposed. Do you agree that Section 3 of >>> draft-rosenberg-dispatch-vipr-reload-usage exposes a problem that would be worth >>> been solved in p2psip-base? >> >> I think we're merging two separate issues here: >> >> - how do you differentiate the sender of an end-to-end-message >> - how do you identify the multiple Node-IDs of an adjacent node >> >> For the first, I think SignerIdentity is the logical place. Using >> hash_alg, certificate_hash, and Node-ID would be sufficient. > > I agree, with one caveat: If the sender of the message is also an adjacent > node, and the extension described below is not implemented, then { hash_alg, > certificate_hash, Node-ID } does not permit to differentiate the sender if there > is multiple Node-IDs in the certificate. This is because the Via is added by > the receiving node instead of the sending node. > Again, I think a new SignerIdentity would be sufficient for identifying the originator of the message. You're right that it doesn't identify the virtual node acting in this case. >> >> For adjacent nodes, I would rather encode it using an IceExtension in >> the Attach sequence that's already flowing than use a shim approach, >> particularly because it avoids issues with datagram protocols. > > OK. I still think that having 1) each node adding the Via before sending > (instead of by the receiving node), 2) all nodes adding the next hop on top of > the destination_list before forwarding and 3) the receiving node dropping the > first node in the destination_list before applying the routing algorithm would > have been a better solution. > This strikes me as a major change, but if you want to start a separate thread on it, we could see if others feel the same way. I think this routing algorithm is only required if we want the property above. No objections to your defining a routing algorithm extension that has this property, of course. >> >> I have mixed feelings on whether either of these should be in the base >> protocol. I really think that SignerIdentity should handle that case. >> But I think the support for multiple NodeIDs over a connection adds a >> lot of complexity and might be better as an extension. > > Well, I am willing to write immediately the I-D for such extension (because my > implementation is using multiple Node-IDs per certificate), so let me know if > this is the way to go. > Probably best to start a separate thread, but I'd be happy to see a draft proposing the IceExtension. Bruce > Thanks. > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk1SxGMACgkQ9RoMZyVa61dG/QCcC1Kl6ELen4VzE3rJGgfl0F8R > 5PIAoKeX3u87MSGiUpthSqnHY/Emvrhz > =6AGB > -----END PGP SIGNATURE----- > From bbl@lowekamp.net Sun Feb 13 17:15:56 2011 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 C83343A6A64 for ; Sun, 13 Feb 2011 17:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 K1ibs2id7rr9 for ; Sun, 13 Feb 2011 17:15:52 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A32563A69E0 for ; Sun, 13 Feb 2011 17:15:52 -0800 (PST) Received: by iwc10 with SMTP id 10so4591221iwc.31 for ; Sun, 13 Feb 2011 17:16:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.230.198 with SMTP id jn6mr4202519icb.97.1297646174069; Sun, 13 Feb 2011 17:16:14 -0800 (PST) Received: by 10.42.224.70 with HTTP; Sun, 13 Feb 2011 17:16:13 -0800 (PST) In-Reply-To: <007b01cbc8a5$41e84050$c5b8c0f0$%roni@huawei.com> References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> <5C753D64-5D86-4CCF-9C44-42C42021A3B5@cisco.com> <3EB53AEB-1135-471A-BEBC-AC6697394605@skype.net> <01be01cbc83d$db453fe0$91cfbfa0$%roni@huawei.com> <003a01cbc88f$f1097b00$d31c7100$%roni@huawei.com> <481E65B9-A508-4E33-AC61-D06617CD5314@skype.net> <007b01cbc8a5$41e84050$c5b8c0f0$%roni@huawei.com> Date: Sun, 13 Feb 2011 20:16:13 -0500 Message-ID: From: Bruce Lowekamp To: Roni Even Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR 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, 14 Feb 2011 01:15:56 -0000 There are some proposals for why an intermediate peer might wish to use a compressed (opaque) via-list entry. Mostly to do with hiding some of the topology from other nodes. To some extent, maybe the central question here is whether such behavior should be controlled by routing flags or overlay flags, and if a node wishes to hide topology, is it permissible for it to refuse to route messages inconsistent with this goal, thus forcing nodes trying to use other routing algorithms to fallback to more basic routing techniques. Roni, I think your suggestion of overlay parameters to restrict what routing options are available would accomplish the same goals as the routing flag (as far as enabling DRR-compliant forwarding), so I think if you think that's compatible with what you want to accomplish and are happy with it, we should go in that direction. Bruce On Wed, Feb 9, 2011 at 5:03 PM, Roni Even wrote: > Hi, > I see what EKR means but I think that there is some inconsistency in sect= ion > 3.3. > The requirement says: > > "Low state: =C2=A0 =C2=A0RELOAD's routing algorithms must not require > =C2=A0 =C2=A0 =C2=A0significant state to be stored on intermediate peers.= " > > Yet when talking about state keeping later in the section it says what EK= R > points out > > "This =C2=A0option requires greater state to be stored on intermediate pe= ers but > =C2=A0 saves a small amount of bandwidth and reduces the need for modifyi= ng > =C2=A0 the message en route. =C2=A0Selection of this mode of operation is= a > =C2=A0 choice for the individual peer;" > > I think that maybe this should be changed and that the selection of this > mode whould be allowed by overlay configuration and may be overridden by = a > flag. I am not sure why an intermediary should decide on the via list > content. > > Roni Even > > >> -----Original Message----- >> From: Eric Rescorla [mailto:ekr@skype.net] >> Sent: Wednesday, February 09, 2011 9:42 PM >> To: Roni Even >> Cc: 'Cullen Jennings'; 'P2PSIP WG' >> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from >> meeting - DRR >> >> >> On Feb 9, 2011, at 11:31 AM, Roni Even wrote: >> >> > EKR, >> > I am not sure why the flag does not work for =C2=A0symmetric return, s= tate >> > keeping by intermediaries is optional according to section 3.3 and is >> not >> > required for it to work. >> >> The intermediary's job is to keep the via list in a state where it is >> unwindable. It >> is a purely local matter how it does so. It's not reasonable to tell >> intermediaries >> who would otherwise keep state that they must instead modify the via >> list to >> include the full unwind path. >> >> -Ekr > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From petithug@acm.org Sun Feb 13 18:34:23 2011 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 9E99E3A6C3E for ; Sun, 13 Feb 2011 18:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.94 X-Spam-Level: X-Spam-Status: No, score=-101.94 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 AWTLSc5kUDAy for ; Sun, 13 Feb 2011 18:34:22 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id EE12A3A6C32 for ; Sun, 13 Feb 2011 18:34:21 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 480A4DBD401C; Mon, 14 Feb 2011 02:34:42 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 6BE7BDBCC04E; Mon, 14 Feb 2011 02:34:41 +0000 (UTC) Message-ID: <4D5894C0.2010303@acm.org> Date: Sun, 13 Feb 2011 18:34:40 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2) 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, 14 Feb 2011 02:34:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/13/2011 05:04 PM, Bruce Lowekamp wrote: > Marc, > > I think there's an underlying issue here of whether it's important to > - use the same "physical" connection between two physical nodes that > are both acting as multiple virtual nodes for all pairs of > connectivity between them > AND > - differentiate on the receipt of a message what pair of virtual nodes > A'->B' the original sender believed the message was going between. > > I'm not immediately convinced that this is a useful property for the > routing system, as if each physical node is merging the virtual nodes' > routing tables and forwarding to the closest match, I don't think it's > necessary for reliable routing. However, if you have a pointer to a > description of why this would be useful, I'd be very interested in > reading it. > > With that said, my current opinion is that what you want to accomplish > can and should be accomplished through a new routing algorithm. OK, fair enough. > However, I think we should move to incorporate the new SignerIdentity > into the base draft and probably handle the IceExtension as a new > draft. OK, I'll write the I-D before the cut-off, and will implement it. Thanks. > But both should probably get a thread of their own so they > have more eyes. > > More comments inline > > On Wed, Feb 9, 2011 at 11:44 AM, Marc Petit-Huguenin wrote: > On 02/08/2011 06:25 PM, Bruce Lowekamp wrote: >>>> On Mon, Jan 10, 2011 at 5:44 PM, Marc Petit-Huguenin wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Thanks for your responses. see below for more comments. >>>>> >>>>> On 01/07/2011 02:24 PM, Bruce Lowekamp wrote: >>>>>> inline >>>>>> >>>>>> On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin wrote: >>>>>> More questions, comments and nits: >>>>>> >>>>> >>>>> [...] >>>>> >>>>>> >>>>>> - A.10. It seems that this version of RELOAD lacks the support of virtual >>>>>> servers (see draft-harjula-p2psip-loadbalancing-survey), more precisely a way to >>>>>> share connections between two virtual servers on the same physical server (see >>>>>> Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, >>>>>> Wide-area cooperative storage with CFS: "Use of virtual servers could >>>>>> potentially increase the number of hops in a Chord lookup. CFS avoids this >>>>>> expense by allowing virtual servers on the same physical server to examine each >>>>>> others' tables: the fact that these virtual servers can take short-cuts through >>>>>> each others' routing table exactly compensates for the increases number of >>>>>> servers."). Because the certificates contains a list of Node-IDs, it is not >>>>>> possible to know on a hop by hop basis what are the source and destination >>>>>> NodeIds of a specific message. Section 3 of >>>>>> draft-rosenberg-dispatch-vipr-reload-usage seems to acknowledge that by adding a >>>>>> PeerID Shim to exchange the source and destination peerIDs (aka Node-IDs). >>>>>> >>>>>> Because of this, it is probably a good idea to add in p2psip-base the >>>>>> possibility to know the source Node-ID and destination Node-ID of a message. >>>>>> One way to do that would have be to have the sender of a message add its own >>>>>> Node-ID in the via_list, and the Node-ID of the destination in the >>>>>> destination_list before sending a message (similar to what SIP is doing), but I >>>>>> guess that it is too late for such a modification. >>>>>> >>>>>> >>>>>>> I totally agree that vnodes should share routing state. But it's not >>>>>>> clear to me what benefit would be obtained by making that sort of a >>>>>>> protocol change. >>>>>> >>>>>>> * on request routing, a message should normally have exactly one >>>>>>> destination node-id. The only reason to have more would be that the >>>>>>> request sender has some particular reason to want to source-route the >>>>>>> request. >>>>>>> * on response sending, with recursive response you simply want to >>>>>>> reverse the initial request routing. If there was an advantage to >>>>>>> "short-cutting" between v-nodes, it would have been done on the >>>>>>> request routing. If you're not doing recursive response routing, >>>>>>> then this case is the same as request routing. >>>>> >>>>> Let's forget for now the solution I proposed. Do you agree that Section 3 of >>>>> draft-rosenberg-dispatch-vipr-reload-usage exposes a problem that would be worth >>>>> been solved in p2psip-base? >>>> >>>> I think we're merging two separate issues here: >>>> >>>> - how do you differentiate the sender of an end-to-end-message >>>> - how do you identify the multiple Node-IDs of an adjacent node >>>> >>>> For the first, I think SignerIdentity is the logical place. Using >>>> hash_alg, certificate_hash, and Node-ID would be sufficient. > > I agree, with one caveat: If the sender of the message is also an adjacent > node, and the extension described below is not implemented, then { hash_alg, > certificate_hash, Node-ID } does not permit to differentiate the sender if there > is multiple Node-IDs in the certificate. This is because the Via is added by > the receiving node instead of the sending node. > > >> Again, I think a new SignerIdentity would be sufficient for >> identifying the originator of the message. You're right that it >> doesn't identify the virtual node acting in this case. > >>>> >>>> For adjacent nodes, I would rather encode it using an IceExtension in >>>> the Attach sequence that's already flowing than use a shim approach, >>>> particularly because it avoids issues with datagram protocols. > > OK. I still think that having 1) each node adding the Via before sending > (instead of by the receiving node), 2) all nodes adding the next hop on top of > the destination_list before forwarding and 3) the receiving node dropping the > first node in the destination_list before applying the routing algorithm would > have been a better solution. > > >> This strikes me as a major change, but if you want to start a separate >> thread on it, we could see if others feel the same way. I think this >> routing algorithm is only required if we want the property above. No >> objections to your defining a routing algorithm extension that has >> this property, of course. > > > >>>> >>>> I have mixed feelings on whether either of these should be in the base >>>> protocol. I really think that SignerIdentity should handle that case. >>>> But I think the support for multiple NodeIDs over a connection adds a >>>> lot of complexity and might be better as an extension. > > Well, I am willing to write immediately the I-D for such extension (because my > implementation is using multiple Node-IDs per certificate), so let me know if > this is the way to go. > > >> Probably best to start a separate thread, but I'd be happy to see a >> draft proposing the IceExtension. > >> Bruce > > > > Thanks. > >> - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1YlL4ACgkQ9RoMZyVa61dKzwCfXRdXpdciAOD9e34qyEmpuofv +VQAoKbsdbCju6vadmAcdNvUVNTlFy77 =Qayk -----END PGP SIGNATURE----- From petithug@acm.org Sat Feb 19 15:53:02 2011 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 A953C3A6F7F for ; Sat, 19 Feb 2011 15:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 y4Dzn4q6q5-8 for ; Sat, 19 Feb 2011 15:53:01 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id BBE503A6CC3 for ; Sat, 19 Feb 2011 15:53:01 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id E3DD5EBC4026; Sat, 19 Feb 2011 23:53:38 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 43354EBC4024; Sat, 19 Feb 2011 23:53:38 +0000 (UTC) Message-ID: <4D605801.20704@acm.org> Date: Sat, 19 Feb 2011 15:53:37 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: [P2PSIP] Multiple Node-IDs in certificate [was Re: draft-ietf-p2psip-base-12 (2)] 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: Sat, 19 Feb 2011 23:53:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/13/2011 05:04 PM, Bruce Lowekamp wrote: > Marc, > > I think there's an underlying issue here of whether it's important to > - use the same "physical" connection between two physical nodes that > are both acting as multiple virtual nodes for all pairs of > connectivity between them > AND > - differentiate on the receipt of a message what pair of virtual nodes > A'->B' the original sender believed the message was going between. > > I'm not immediately convinced that this is a useful property for the > routing system, as if each physical node is merging the virtual nodes' > routing tables and forwarding to the closest match, I don't think it's > necessary for reliable routing. However, if you have a pointer to a > description of why this would be useful, I'd be very interested in > reading it. > > With that said, my current opinion is that what you want to accomplish > can and should be accomplished through a new routing algorithm. > However, I think we should move to incorporate the new SignerIdentity > into the base draft and probably handle the IceExtension as a new > draft. But both should probably get a thread of their own so they > have more eyes. I spent more time on this problem(s) (the fact that the information on a specific subject are scattered all over the I-D does not help, for sure), and I am now less sure that there is a need for this changes. Let's take the issues one by one: 1. Connections sharing: I am still running some simulations and so far I do not have an definitive answer, so let forget about this for now. Hopefully it could be done as an extension, as you suggested. 2. Knowing the Node-ID of the sender of an end-to-end message, when multiple Node-IDs are used in the certificate: - - If the message is a request and traversed at least one peer, then the sender Node-ID will be the first Node-ID in the via list. - - If the message is a request that was sent over a direct connection, then the sender Node-ID is the Node-ID associated with the connection - see (3). - - If the message is an answer, then the sender Node-ID is the same Node-ID that was used to send the matching request. An implementation had to store it for the end-to-end retransmission, so it is retrievable from the transaction-id. 3. Knowing the Node-ID of the sender of a message on a direct connection, when multiple Node-IDs are used in the certificate: - - Because direct connections are established by Attach, the Node-ID of the sender of a message on a direct connection is also the Node-ID of the sender of the Attach message (request or answer) that was used to establish the direct connection - see (2). Now there is one case that does not work: a client with a certificate with multiple Node-IDs. Because a client connects directly to a bootstrap peer (without Attach), the bootstrap node has no way to know which Node-ID to choose on the certificate. When the Attach to the admitting peer will be sent by the client, the bootstrap peer will not be able to know what Node-ID to add in the via list, and so will not be able to route back the answer. And neither a new SignerIdentity or IceExtension can help in this case. So because it is not possible to join an overlay with a certificate containing multiple Node-IDs, the only way it could work would be to join with a certificate containing one Node-ID then after the Attach to the admitting peer switch to a certificate with multiple Node-IDs. Was that the intent? - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1gWAAACgkQ9RoMZyVa61fFXwCfegOrqYADs9809eM+N0y5muMA gRUAn2x4ZThclCBYbEZ4aMMmrM4p+3PO =gCJY -----END PGP SIGNATURE----- From ekr@skype.net Sat Feb 19 18:04:56 2011 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 274A83A7072 for ; Sat, 19 Feb 2011 18:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3O+TVrSvXqKH for ; Sat, 19 Feb 2011 18:04:55 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id B863B3A6EDA for ; Sat, 19 Feb 2011 18:04:54 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 150067F8; Sun, 20 Feb 2011 03:05:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=VX 6Hv0MunmUa3xfTkN3T6KewuxE=; b=lser3Q8gnEHjy6AblL2BY90UJmvKS1Eogk GLZr5kqfMurj6ulCB+KP/gJJ2+FqPsvKU09VheeBouQAvqD05I3c9kj3J3uAhq9V CzgSVWg0T04SfYRFyrS6FR7DKYT0w8HchtttCullWDaNUO8U/K1punRQ7kj6+9++ o3qyJljcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=qqviqq1W3z3JzNP00e4t2t cW0t1Z3CVZaICaoAS95hU0cPW6W5+R4Sk2V21ZT4Y4FVspG8c31FROpEhw5cf1sK /vPJh3hCs+TR59StbD585hTmAH4Kx7SJTpGJwXVS5PzIMlf3UQC1+e6TKYohDSFs 700FD2vzX2MvQB4+4rh7g= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 134BF7F6; Sun, 20 Feb 2011 03:05:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id E212A3506F77; Sun, 20 Feb 2011 03:05:29 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp3chcCB09O1; Sun, 20 Feb 2011 03:05:28 +0100 (CET) Received: from [192.168.1.103] (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by zimbra.skype.net (Postfix) with ESMTPSA id 523173506F5B; Sun, 20 Feb 2011 03:05:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Eric Rescorla In-Reply-To: <4D605801.20704@acm.org> Date: Sat, 19 Feb 2011 18:09:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A3441F9-EEEE-42F7-A447-A4292F667201@skype.net> References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> <4D605801.20704@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP WG Subject: Re: [P2PSIP] Multiple Node-IDs in certificate [was Re: draft-ietf-p2psip-base-12 (2)] 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, 20 Feb 2011 02:04:56 -0000 On Feb 19, 2011, at 3:53 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 02/13/2011 05:04 PM, Bruce Lowekamp wrote: >> Marc, >>=20 >> I think there's an underlying issue here of whether it's important to >> - use the same "physical" connection between two physical nodes that >> are both acting as multiple virtual nodes for all pairs of >> connectivity between them >> AND >> - differentiate on the receipt of a message what pair of virtual = nodes >> A'->B' the original sender believed the message was going between. >>=20 >> I'm not immediately convinced that this is a useful property for the >> routing system, as if each physical node is merging the virtual = nodes' >> routing tables and forwarding to the closest match, I don't think = it's >> necessary for reliable routing. However, if you have a pointer to a >> description of why this would be useful, I'd be very interested in >> reading it. >>=20 >> With that said, my current opinion is that what you want to = accomplish >> can and should be accomplished through a new routing algorithm. >> However, I think we should move to incorporate the new SignerIdentity >> into the base draft and probably handle the IceExtension as a new >> draft. But both should probably get a thread of their own so they >> have more eyes. >=20 > I spent more time on this problem(s) (the fact that the information on = a > specific subject are scattered all over the I-D does not help, for = sure), and I > am now less sure that there is a need for this changes. Let's take = the issues > one by one: >=20 > 1. Connections sharing: I am still running some simulations and so = far I do not > have an definitive answer, so let forget about this for now. = Hopefully it could > be done as an extension, as you suggested. >=20 > 2. Knowing the Node-ID of the sender of an end-to-end message, when = multiple > Node-IDs are used in the certificate: >=20 > - - If the message is a request and traversed at least one peer, then = the sender > Node-ID will be the first Node-ID in the via list. Regrettably, this is not always true due to via list compression. If you = want to know this, we should add an extension to the signature. > - - If the message is a request that was sent over a direct = connection, then the > sender Node-ID is the Node-ID associated with the connection - see = (3). >=20 > - - If the message is an answer, then the sender Node-ID is the same = Node-ID that > was used to send the matching request. An implementation had to store = it for > the end-to-end retransmission, so it is retrievable from the = transaction-id. I fear that this is not true as well, since you can send to a = resource-id. -Ekr > 3. Knowing the Node-ID of the sender of a message on a direct = connection, when > multiple Node-IDs are used in the certificate: >=20 > - - Because direct connections are established by Attach, the Node-ID = of the > sender of a message on a direct connection is also the Node-ID of the = sender of > the Attach message (request or answer) that was used to establish the = direct > connection - see (2). >=20 > Now there is one case that does not work: a client with a certificate = with > multiple Node-IDs. Because a client connects directly to a bootstrap = peer > (without Attach), the bootstrap node has no way to know which Node-ID = to choose > on the certificate. When the Attach to the admitting peer will be = sent by the > client, the bootstrap peer will not be able to know what Node-ID to = add in the > via list, and so will not be able to route back the answer. And = neither a new > SignerIdentity or IceExtension can help in this case. >=20 > So because it is not possible to join an overlay with a certificate = containing > multiple Node-IDs, the only way it could work would be to join with a > certificate containing one Node-ID then after the Attach to the = admitting peer > switch to a certificate with multiple Node-IDs. Was that the intent? >=20 >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iEYEARECAAYFAk1gWAAACgkQ9RoMZyVa61fFXwCfegOrqYADs9809eM+N0y5muMA > gRUAn2x4ZThclCBYbEZ4aMMmrM4p+3PO > =3DgCJY > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Sun Feb 20 10:27:29 2011 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 C89CC3A6F02 for ; Sun, 20 Feb 2011 10:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.036 X-Spam-Level: X-Spam-Status: No, score=-102.036 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 PrfEHP1odftb for ; Sun, 20 Feb 2011 10:27:28 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 9BC613A6E40 for ; Sun, 20 Feb 2011 10:27:28 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 04806DBCC050; Sun, 20 Feb 2011 18:28:08 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id A1C96DBCC04E; Sun, 20 Feb 2011 18:28:06 +0000 (UTC) Message-ID: <4D615D35.8050507@acm.org> Date: Sun, 20 Feb 2011 10:28:05 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Eric Rescorla References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> <4D605801.20704@acm.org> <7A3441F9-EEEE-42F7-A447-A4292F667201@skype.net> In-Reply-To: <7A3441F9-EEEE-42F7-A447-A4292F667201@skype.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Multiple Node-IDs in certificate [was Re: draft-ietf-p2psip-base-12 (2)] 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, 20 Feb 2011 18:27:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/19/2011 06:09 PM, Eric Rescorla wrote: > > On Feb 19, 2011, at 3:53 PM, Marc Petit-Huguenin wrote: > > On 02/13/2011 05:04 PM, Bruce Lowekamp wrote: >>>> Marc, >>>> >>>> I think there's an underlying issue here of whether it's important to >>>> - use the same "physical" connection between two physical nodes that >>>> are both acting as multiple virtual nodes for all pairs of >>>> connectivity between them >>>> AND >>>> - differentiate on the receipt of a message what pair of virtual nodes >>>> A'->B' the original sender believed the message was going between. >>>> >>>> I'm not immediately convinced that this is a useful property for the >>>> routing system, as if each physical node is merging the virtual nodes' >>>> routing tables and forwarding to the closest match, I don't think it's >>>> necessary for reliable routing. However, if you have a pointer to a >>>> description of why this would be useful, I'd be very interested in >>>> reading it. >>>> >>>> With that said, my current opinion is that what you want to accomplish >>>> can and should be accomplished through a new routing algorithm. >>>> However, I think we should move to incorporate the new SignerIdentity >>>> into the base draft and probably handle the IceExtension as a new >>>> draft. But both should probably get a thread of their own so they >>>> have more eyes. > > I spent more time on this problem(s) (the fact that the information on a > specific subject are scattered all over the I-D does not help, for sure), and I > am now less sure that there is a need for this changes. Let's take the issues > one by one: > > 1. Connections sharing: I am still running some simulations and so far I do not > have an definitive answer, so let forget about this for now. Hopefully it could > be done as an extension, as you suggested. > > 2. Knowing the Node-ID of the sender of an end-to-end message, when multiple > Node-IDs are used in the certificate: > > - If the message is a request and traversed at least one peer, then the sender > Node-ID will be the first Node-ID in the via list. > >> Regrettably, this is not always true due to via list compression. If you want to know >> this, we should add an extension to the signature. > > > - If the message is a request that was sent over a direct connection, then the > sender Node-ID is the Node-ID associated with the connection - see (3). > > - If the message is an answer, then the sender Node-ID is the same Node-ID that > was used to send the matching request. An implementation had to store it for > the end-to-end retransmission, so it is retrievable from the transaction-id. > >> I fear that this is not true as well, since you can send to a resource-id. OK, so the Signature extension is mandatory to use multiple Node-IDs in certificates. But the IceExtension still seems useless, as, thanks to the Signature extension, we always know the Node-Id on each side of the Attach. Also a client joining the overlay using a certificate with multiple Node-IDs, using the procedure in the second bullet of section 3.2.1 will still have problems. > >> -Ekr > > 3. Knowing the Node-ID of the sender of a message on a direct connection, when > multiple Node-IDs are used in the certificate: > > - Because direct connections are established by Attach, the Node-ID of the > sender of a message on a direct connection is also the Node-ID of the sender of > the Attach message (request or answer) that was used to establish the direct > connection - see (2). > > Now there is one case that does not work: a client with a certificate with > multiple Node-IDs. Because a client connects directly to a bootstrap peer > (without Attach), the bootstrap node has no way to know which Node-ID to choose > on the certificate. When the Attach to the admitting peer will be sent by the > client, the bootstrap peer will not be able to know what Node-ID to add in the > via list, and so will not be able to route back the answer. And neither a new > SignerIdentity or IceExtension can help in this case. > > So because it is not possible to join an overlay with a certificate containing > multiple Node-IDs, the only way it could work would be to join with a > certificate containing one Node-ID then after the Attach to the admitting peer > switch to a certificate with multiple Node-IDs. Was that the intent? - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1hXTQACgkQ9RoMZyVa61fFxgCfeCH/W0/Fljeh6Z8VKQsypbim U2UAniOnZDWZkLSJnZqGiD7AAMFMwrfU =WNCK -----END PGP SIGNATURE----- From petithug@acm.org Wed Feb 23 09:52:03 2011 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 912513A6915 for ; Wed, 23 Feb 2011 09:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.065 X-Spam-Level: X-Spam-Status: No, score=-102.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 vY5ANSYkJuMs for ; Wed, 23 Feb 2011 09:52:02 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 727DC3A6810 for ; Wed, 23 Feb 2011 09:52:02 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 319C411BC407C; Wed, 23 Feb 2011 17:52:50 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 16E3811BC407A for ; Wed, 23 Feb 2011 17:52:49 +0000 (UTC) Message-ID: <4D65496F.3010204@acm.org> Date: Wed, 23 Feb 2011 09:52:47 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] draft-ietf-p2psip-base-12 (6) 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, 23 Feb 2011 17:52:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another question. A.44. Section 5.6.6 Last paragraph and table Section 5.5.1.5 states that "[a]n overlay MUST be either all ICE or all No-ICE", so I do not see how this table works. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1lSWUACgkQ9RoMZyVa61fZIQCeOs3h+4KHqFcXqy4H82aoUtea 4F0An2eK54x56aOO2jUKPClcetHYjjRT =U6Jh -----END PGP SIGNATURE----- From bbl@lowekamp.net Sun Feb 27 17:17:00 2011 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 953573A6A5D for ; Sun, 27 Feb 2011 17:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 mjdxvA8CaqQJ for ; Sun, 27 Feb 2011 17:16:59 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6CCAC3A6A5A for ; Sun, 27 Feb 2011 17:16:59 -0800 (PST) Received: by iwl42 with SMTP id 42so3002778iwl.31 for ; Sun, 27 Feb 2011 17:17:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.59.145 with SMTP id wo17mr2791484icb.291.1298855877356; Sun, 27 Feb 2011 17:17:57 -0800 (PST) Received: by 10.42.241.9 with HTTP; Sun, 27 Feb 2011 17:17:57 -0800 (PST) In-Reply-To: <4D615D35.8050507@acm.org> References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> <4D605801.20704@acm.org> <7A3441F9-EEEE-42F7-A447-A4292F667201@skype.net> <4D615D35.8050507@acm.org> Date: Sun, 27 Feb 2011 20:17:57 -0500 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Multiple Node-IDs in certificate [was Re: draft-ietf-p2psip-base-12 (2)] 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, 28 Feb 2011 01:17:00 -0000 On Sun, Feb 20, 2011 at 1:28 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/19/2011 06:09 PM, Eric Rescorla wrote: >> >> On Feb 19, 2011, at 3:53 PM, Marc Petit-Huguenin wrote: >> >> On 02/13/2011 05:04 PM, Bruce Lowekamp wrote: >>>>> Marc, >>>>> >>>>> I think there's an underlying issue here of whether it's important to >>>>> - use the same "physical" connection between two physical nodes that >>>>> are both acting as multiple virtual nodes for all pairs of >>>>> connectivity between them >>>>> AND >>>>> - differentiate on the receipt of a message what pair of virtual node= s >>>>> A'->B' the original sender believed the message was going between. >>>>> >>>>> I'm not immediately convinced that this is a useful property for the >>>>> routing system, as if each physical node is merging the virtual nodes= ' >>>>> routing tables and forwarding to the closest match, I don't think it'= s >>>>> necessary for reliable routing. =C2=A0However, if you have a pointer = to a >>>>> description of why this would be useful, I'd be very interested in >>>>> reading it. >>>>> >>>>> With that said, my current opinion is that what you want to accomplis= h >>>>> can and should be accomplished through a new routing algorithm. >>>>> However, I think we should move to incorporate the new SignerIdentity >>>>> into the base draft and probably handle the IceExtension as a new >>>>> draft. =C2=A0But both should probably get a thread of their own so th= ey >>>>> have more eyes. >> >> I spent more time on this problem(s) (the fact that the information on a >> specific subject are scattered all over the I-D does not help, for sure)= , and I >> am now less sure that there is a need for this changes. =C2=A0Let's take= the issues >> one by one: >> >> 1. Connections sharing: =C2=A0I am still running some simulations and so= far I do not >> have an definitive answer, so let forget about this for now. =C2=A0Hopef= ully it could >> be done as an extension, as you suggested. >> >> 2. Knowing the Node-ID of the sender of an end-to-end message, when mult= iple >> Node-IDs are used in the certificate: >> >> - If the message is a request and traversed at least one peer, then the = sender >> Node-ID will be the first Node-ID in the via list. >> >>> Regrettably, this is not always true due to via list compression. If yo= u want to know >>> this, we should add an extension to the signature. >> >> >> - If the message is a request that was sent over a direct connection, th= en the >> sender Node-ID is the Node-ID associated with the connection - see (3). >> >> - If the message is an answer, then the sender Node-ID is the same Node-= ID that >> was used to send the matching request. =C2=A0An implementation had to st= ore it for >> the end-to-end retransmission, so it is retrievable from the transaction= -id. >> >>> I fear that this is not true as well, since you can send to a resource-= id. > > OK, so the Signature extension is mandatory to use multiple Node-IDs in > certificates. =C2=A0But the IceExtension still seems useless, as, thanks = to the > Signature extension, we always know the Node-Id on each side of the Attac= h. > I think the IceExtension would be needed for connection sharing, so since you said you're setting that aside for now, I agree. > Also a client joining the overlay using a certificate with multiple Node-= IDs, > using the procedure in the second bullet of section 3.2.1 will still have= problems. > Assuming the Attach is using SignerIdentity, I don't see any problems with that, since the peer would know the node-id that the node is using. >> >>> -Ekr >> >> 3. Knowing the Node-ID of the sender of a message on a direct connection= , when >> multiple Node-IDs are used in the certificate: >> >> - Because direct connections are established by Attach, the Node-ID of t= he >> sender of a message on a direct connection is also the Node-ID of the se= nder of >> the Attach message (request or answer) that was used to establish the di= rect >> connection - see (2). >> >> Now there is one case that does not work: a client with a certificate wi= th >> multiple Node-IDs. =C2=A0Because a client connects directly to a bootstr= ap peer >> (without Attach), the bootstrap node has no way to know which Node-ID to= choose >> on the certificate. =C2=A0When the Attach to the admitting peer will be = sent by the >> client, the bootstrap peer will not be able to know what Node-ID to add = in the >> via list, and so will not be able to route back the answer. =C2=A0And ne= ither a new >> SignerIdentity or IceExtension can help in this case. >> >> So because it is not possible to join an overlay with a certificate cont= aining >> multiple Node-IDs, the only way it could work would be to join with a >> certificate containing one Node-ID then after the Attach to the admittin= g peer >> switch to a certificate with multiple Node-IDs. =C2=A0Was that the inten= t? > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk1hXTQACgkQ9RoMZyVa61fFxgCfeCH/W0/Fljeh6Z8VKQsypbim > U2UAniOnZDWZkLSJnZqGiD7AAMFMwrfU > =3DWNCK > -----END PGP SIGNATURE----- > From bbl@lowekamp.net Sun Feb 27 17:25:41 2011 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 04C6F3A6A5A for ; Sun, 27 Feb 2011 17:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 Zi0OVthbU3UW for ; Sun, 27 Feb 2011 17:25:40 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E194F3A6959 for ; Sun, 27 Feb 2011 17:25:39 -0800 (PST) Received: by iwl42 with SMTP id 42so3007125iwl.31 for ; Sun, 27 Feb 2011 17:26:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.171.200 with SMTP id k8mr4282193icz.90.1298856398264; Sun, 27 Feb 2011 17:26:38 -0800 (PST) Received: by 10.42.241.9 with HTTP; Sun, 27 Feb 2011 17:26:38 -0800 (PST) In-Reply-To: <4D65496F.3010204@acm.org> References: <4D65496F.3010204@acm.org> Date: Sun, 27 Feb 2011 20:26:38 -0500 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (6) 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, 28 Feb 2011 01:25:41 -0000 Sorry, that table (and text) in 5.6.6 should have been removed Bruce On Wed, Feb 23, 2011 at 12:52 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Another question. > > A.44. Section 5.6.6 Last paragraph and table > > Section 5.5.1.5 states that "[a]n overlay MUST be either all ICE or all No-ICE", > so I do not see how this table works. > > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk1lSWUACgkQ9RoMZyVa61fZIQCeOs3h+4KHqFcXqy4H82aoUtea > 4F0An2eK54x56aOO2jUKPClcetHYjjRT > =U6Jh > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From peng.yonglin@zte.com.cn Sun Feb 27 17:51:53 2011 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 F2AED3A6961 for ; Sun, 27 Feb 2011 17:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 2MzaDMQ4DKNz for ; Sun, 27 Feb 2011 17:51:51 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id C81FC3A6966 for ; Sun, 27 Feb 2011 17:51:50 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205952075036648; Mon, 28 Feb 2011 09:47:43 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 47420.4725650751; Mon, 28 Feb 2011 09:43:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p1S1qgtK019525; Mon, 28 Feb 2011 09:52:42 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) To: P2PSIP WG , "dbryan@ethernot.org" , "br@brianrosen.net" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Mon, 28 Feb 2011 09:52:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-28 09:52:43, Serialize complete at 2011-02-28 09:52:43 Content-Type: multipart/alternative; boundary="=_alternative 000A57AD48257845_=" X-MAIL: mse02.zte.com.cn p1S1qgtK019525 Cc: hao.zhenwu@zte.com.cn, meng.yu@zte.com.cn Subject: [P2PSIP] A new version of draft about Network Management Scenarios for RELOAD, for your comments. 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, 28 Feb 2011 01:51:53 -0000 This is a multipart message in MIME format. --=_alternative 000A57AD48257845_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0ZWQgYSBuZXcgZHJhZnQ6IE5ldHdvcmsgTWFuYWdl bWVudCBTY2VuYXJpb3MgZm9yIFJFTE9BRC4gSXQgDQppcyBhdCANCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1wZW5nLXAycHNpcC1uZXR3b3JrLW1hbmFnZW1lbnQtc2NlbmFyaW9zLTAx LnR4dA0KLg0KDQpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUhIA0KDQoNCkZpbGVuYW1lOiAgICAg ICAgICAgICAgICAgZHJhZnQtcGVuZy1wMnBzaXAtbmV0d29yay1tYW5hZ2VtZW50LXNjZW5hcmlv cw0KUmV2aXNpb246ICAgICAgICAgICAgICAgICAwMQ0KVGl0bGU6ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE5ldHdvcmsgTWFuYWdlbWVudCBTY2VuYXJpb3MgZm9yIFJFTE9BRA0KQ3JlYXRp b25fZGF0ZTogICAgICAgICAgICAyMDExLTAyLTI1DQpXRyBJRDogICAgICAgICAgICAgICAgICAg ICAgICAgICAgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KTnVtYmVyX29mX3BhZ2VzOiAxMQ0KDQpB YnN0cmFjdDoNClRoZSBSRUxPQUQgcHJvdG9jb2wgY2FuIGJlIGFwcGxpZWQgaW4gZGlmZmVyZW50 IGtpbmRzIG9mIHNjZW5hcmlvcywNCmluY2x1ZGluZyBJbnRlcm5ldCwgdGVsZWNvbW11bmljYXRp b24gbmV0d29yaywgZW50ZXJwcmlzZSBuZXR3b3JrLA0KZXRjLiAgVGhpcyBkb2N1bWVudCBzdW1t YXJpemVzIHRoZSBuZXR3b3JrIG1hbmFnZW1lbnQgc2NlbmFyaW9zIGJ5DQphbmFseXppbmcgdHlw aWNhbCBhcHBsaWNhdGlvbiBtb2RlbCBmb3IgZWFjaCBvZiB0aGUgYWJvdmUgdGhyZWUga2luZHMN Cm9mIHNjZW5hcmlvcy4NCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQpFbWFpbKO6cGVuZy55b25nbGluQHp0ZS5jb20uY24NCnBob25lo7o4ODE5 MA0KzeIgz9+jujAyNS01Mjg3ODE5MA0KytYgu/qjujEzNzc2NjM3Mjc0DQoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0 byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4N ClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRl bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZv ciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 000A57AD48257845_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgYWxsLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2UgaGF2ZSBzdWJtaXRlZCBh IG5ldyBkcmFmdDogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+TmV0d29y aw0KTWFuYWdlbWVudCBTY2VuYXJpb3MgZm9yIFJFTE9BRC4gSXQgaXMgYXQgPC9mb250PjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1wZW5nLXAycHNpcC1uZXR3b3JrLW1h bmFnZW1lbnQtc2NlbmFyaW9zLTAxLnR4dCI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXBlbmctcDJwc2lwLW5l dHdvcmstbWFuYWdlbWVudC1zY2VuYXJpb3MtMDEudHh0PC9mb250PjwvYT48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkFueSBjb21tZW50cyBhcmUgd2VsY29tZSEgJm5ic3A7PC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+RmlsZW5hbWU6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXBlbmct cDJwc2lwLW5ldHdvcmstbWFuYWdlbWVudC1zY2VuYXJpb3M8YnI+DQpSZXZpc2lvbjogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 MDE8YnI+DQpUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCk5ldHdvcmsgTWFuYWdlbWVudCBTY2VuYXJpb3MgZm9yIFJF TE9BRDxicj4NCkNyZWF0aW9uX2RhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzIwMTEtMDItMjU8YnI+DQpXRyBJRDogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCkluZGVwZW5kZW50IFN1Ym1pc3Npb248YnI+DQpOdW1iZXJfb2ZfcGFnZXM6IDExPGJyPg0K PGJyPg0KQWJzdHJhY3Q6PGJyPg0KVGhlIFJFTE9BRCBwcm90b2NvbCBjYW4gYmUgYXBwbGllZCBp biBkaWZmZXJlbnQga2luZHMgb2Ygc2NlbmFyaW9zLDxicj4NCmluY2x1ZGluZyBJbnRlcm5ldCwg dGVsZWNvbW11bmljYXRpb24gbmV0d29yaywgZW50ZXJwcmlzZSBuZXR3b3JrLDxicj4NCmV0Yy4g Jm5ic3A7VGhpcyBkb2N1bWVudCBzdW1tYXJpemVzIHRoZSBuZXR3b3JrIG1hbmFnZW1lbnQgc2Nl bmFyaW9zIGJ5PGJyPg0KYW5hbHl6aW5nIHR5cGljYWwgYXBwbGljYXRpb24gbW9kZWwgZm9yIGVh Y2ggb2YgdGhlIGFib3ZlIHRocmVlIGtpbmRzPGJyPg0Kb2Ygc2NlbmFyaW9zLjxicj4NCjwvdHQ+ PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KRW1haWyjunBl bmcueW9uZ2xpbkB6dGUuY29tLmNuPGJyPg0KcGhvbmWjujg4MTkwPGJyPg0KzeIgz9+jujAyNS01 Mjg3ODE5MDxicj4NCsrWILv6o7oxMzc3NjYzNzI3NDxicj4NCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L2ZvbnQ+DQo8YnI+PHByZT4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJz cDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2lu Zm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNw O2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRl cidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNh dGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1l ZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFp biZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQm bmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNw O3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7 ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7 d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50 ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hv bSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJz cDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vy cm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNw O29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJl c3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1 c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5i c3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000A57AD48257845_=-- From petithug@acm.org Sun Feb 27 18:53:21 2011 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 A5FEC3A6A81 for ; Sun, 27 Feb 2011 18:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.087 X-Spam-Level: X-Spam-Status: No, score=-102.087 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Cv-5dZJ-aAVo for ; Sun, 27 Feb 2011 18:53:21 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id E9FE73A6A73 for ; Sun, 27 Feb 2011 18:53:20 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 15706EBC4026; Mon, 28 Feb 2011 02:54:20 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 5607AEBC4024; Mon, 28 Feb 2011 02:54:19 +0000 (UTC) Message-ID: <4D6B0E5A.7050509@acm.org> Date: Sun, 27 Feb 2011 18:54:18 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> <4D605801.20704@acm.org> <7A3441F9-EEEE-42F7-A447-A4292F667201@skype.net> <4D615D35.8050507@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Multiple Node-IDs in certificate [was Re: draft-ietf-p2psip-base-12 (2)] 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, 28 Feb 2011 02:53:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/27/2011 05:15 PM, Bruce Lowekamp wrote: > On Sun, Feb 20, 2011 at 1:28 PM, Marc Petit-Huguenin wrote: [...] > > OK, so the Signature extension is mandatory to use multiple Node-IDs in > certificates. But the IceExtension still seems useless, as, thanks to the > Signature extension, we always know the Node-Id on each side of the Attach. > > >> I think the IceExtension would be needed for connection sharing, so >> since you said you're setting that aside for now, I agree. > > Also a client joining the overlay using a certificate with multiple Node-IDs, > using the procedure in the second bullet of section 3.2.1 will still have problems. > > >> Assuming the Attach is using SignerIdentity, I don't see any problems >> with that, since the peer would know the node-id that the node is >> using. Clients that are using the mechanism described in the last paragraph of section 3.2.1 do not send Attach, so a peer would have to spy on the first message coming from the connection of this client to extract the Node-ID from the SignerIdentity and be able to add the connection to the connection table. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1rDlcACgkQ9RoMZyVa61dE/wCfadcwiQFAnaQuOGG6VxOphl+D Dk4AniSw21hHNXbDm/GM442x+nOB05Fe =6hrr -----END PGP SIGNATURE-----