RE: [P2PSIP] HIP: optional, mandatory?

"Henry Sinnreich" <hsinnrei@adobe.com> Mon, 14 January 2008 15:13 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JER06-000787-6X; Mon, 14 Jan 2008 10:13:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JER05-0006vD-0V for p2psip@ietf.org; Mon, 14 Jan 2008 10:13:21 -0500
Received: from exprod6og105.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JER04-0005av-46 for p2psip@ietf.org; Mon, 14 Jan 2008 10:13:20 -0500
Received: from source ([192.150.20.142]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP; Mon, 14 Jan 2008 07:12:57 PST
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m0EFCoGb012397; Mon, 14 Jan 2008 07:12:55 -0800 (PST)
Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m0EFCnRC025493; Mon, 14 Jan 2008 07:12:49 -0800 (PST)
Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 07:12:49 -0800
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [P2PSIP] HIP: optional, mandatory?
Date: Mon, 14 Jan 2008 07:12:22 -0800
Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE4F4@namail5.corp.adobe.com>
In-Reply-To: <e1e2f6d96894.47875b39@us.army.mil>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [P2PSIP] HIP: optional, mandatory?
Thread-Index: AchUdAmi1WoonMFpSQmdMmPOKtYEwgCS03Ww
References: <476BA8D9.4010203@ericsson.com><20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com><476E2B7C.9070601@ericsson.com><20d2bdfb0801081416t41b9b84atb3a147659771036@mail.gmail.com><77F357662F8BFA4CA7074B0410171B6D04049B22@XCH-NW-5V1.nw.nos.boeing.com><7C5B8529-85C9-4977-8C57-34E9041ED1EC@nomadiclab.com><77F357662F8BFA4CA7074B0410171B6D04049B33@XCH-NW-5V1.nw.nos.boeing.com><10DA6CAF-DB5B-4B89-9417-4BEFD816B1E5@cs.columbia.edu><4571B070-0B2F-4076-AAAB-4398295C9E88@cisco.com><465FBE4D-F548-4D7C-855C-10498AF22E6C@quinthar.com><284DBC3B-BF18-400D-8D00-3EB367AEAAA3@cisco.com> <e1e2f6d96894.47875b39@us.army.mil>
From: Henry Sinnreich <hsinnrei@adobe.com>
To: "Roy, Radhika R Dr CTR USA USAMC" <radhika.r.roy@us.army.mil>, Cullen Jennings <fluffy@cisco.com>
X-OriginalArrivalTime: 14 Jan 2008 15:12:49.0429 (UTC) FILETIME=[ECF52450:01C856BF]
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Cc: P2PSIP Mailing List <p2psip@ietf.org>
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

Radhika,

> what is the problem to proceed per P2PSIP charter for accomplishing
the mandated > work items (may be in a limited way) soon which may be
ready for deployment?

I presume you share the view that "ready for deployment" means open
available running code and performance reports from actual test
deployments and you don't mean just eloquently written papers?

Henry

-----Original Message-----
From: Roy, Radhika R Dr CTR USA USAMC [mailto:radhika.r.roy@us.army.mil]

Sent: Friday, January 11, 2008 11:04 AM
To: Cullen Jennings
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] HIP: optional, mandatory?

If it is so as Cullen has explained, what is the problem to proceed per
P2PSIP charter for accomplishing the mandated work items (may be in a
limited way) soon which may be ready for deployment?

Cheers!
Radhika

----- Original Message -----
From: Cullen Jennings 
Date: Friday, January 11, 2008 11:40
Subject: Re: [P2PSIP] HIP: optional, mandatory?
To: David Barrett 
Cc: P2PSIP Mailing List 

> 
> On Jan 10, 2008, at 8:23 PM, David Barrett wrote:
> 
> > We don't need more options for what we CAN do, we need decisions 
> on 
> > what we WILL do.
> 
> Yep - agree. And what I want to do is standardize something that 
> lets me build deployable interoperable solutions soon. Success for 
> me 
> involves deployments.
> 
> > If we're not considering making HIP mandatory, then let's stop 
> 
> > talking about it and start focusing on those things that *will* 
> be 
> > mandatory.
> 
> The P2PSIP WG has made very few decisions since it was formed. 
> IMHO, 
> what we need to do real soon now is pick something as a starting 
> point for a WG document then go and make the decision to change it 
> to 
> be what we want. Until we do that, my belief is that the WG will 
> make fairly marginal progress.
> 
> >
> > That said, I think this HIP discussion is the best thing to 
> happen 
> > in P2PSIP for years. It seems like the most practical and 
> powerful 
> > solution, the best layering of functionality, and the most 
> feasible 
> > design that I've yet to hear. Moving the hard P2P code into a 
> > reusable HIP layer makes a lot of sense,
> 
> this is way outside anything HIP was charted to do or is working on
> 
> > not only for P2PSIP, but for the internet as a whole. It seems 
> > like a wagon that we should voluntarily and enthusiastically 
> hitch 
> > ourselves to, rather than try to reproduce or compete with it, 
> or 
> > toss it in the overflowing bucket of optional extensions.
> >
> > It seems sensible to have a base HIP layer that either comes pre-
> 
> > installed with the OS or redistributed by the application 
> (similar 
> > to WinPCap). (I could even see making a sort of "HIP-lite" self-
> 
> > contained library that can be linked straight into the 
> application 
> > for when installing a Then P2PSIP can be one of many HIP-using 
> 
> > applications that are vastly simplified by being insulated from 
> the 
> > gnarly realities of NAT and firewall penetration, mobility, etc.
> >
> > This makes a lot more sense than continually reproducing this 
> > really hard functionality in every application.
> 
> Most of the concrete proposals layer the p2p code such that the 
> library that provided the p2p part could be used by other 
> applications. This is a good design but not something you need HIP 
> to 
> accomplish.
> 
> >
> > -david
> 
> Cullen 
> 
> >
> > On Jan 11, 2008, at 7:33 AM, Cullen Jennings wrote:
> >
> >>
> >> I was assuming most folks were talking about (3) given that 
> much 
> >> of HIP is still being designed and it will be awhile to get 
> things 
> >> build and deployed. I know lots of parts of HIP have been done 
> but 
> >> when we are talking about mobility, nat traversal, no DNS, and 
> >> easy end user installations, there is still work. Anyway, I am 
> in 
> >> the 3 category.
> >>
> >> Cullen 
> >> On Jan 10, 2008, at 2:14 PM, Henning Schulzrinne wrote:
> >>
> >>> One of the issues I don't understand about this discussion is 
> >>> whether all instances of P2PSIP would be expected to be 
> running 
> >>> HIP or just some. There seem to be at least three options:
> >>>
> >>> (1) Mandatory to implement and run
> >>>
> >>> The only non-recursive-dependency model seems to be that peer 
> >>> nodes would store the HIT-IP bindings in their routing tables. 
> 
> >>> (This largely negates any mobility advantages, but that's a 
> >>> separate discussion.)
> >>>
> >>> (2) Mandatory to implement, but there can be instances of an 
> >>> overlay (or maybe even part of an overlay) that don't use HIP
> >>>
> >>> This would require providing ICE functionality at both the HIP 
> 
> >>> level and directly to the P2P protocol.
> >>>
> >>> (3) Optional to implement and run
> >>>
> >>> This only works if you can have mixed HIP-non-HIP nodes. Also 
> >>> requires implementations of ICE in both layers and the ability 
> to 
> >>> mix-and-match HIP and non-HIP nodes within an overlay, unless 
> >>> each overlay has a "HIP flag".
> >>>
> >>> I admit that I'm rather worried about the complexity of this 
> >>> whole edifice. I think it would be helpful if the proponents 
> of a 
> >>> HIP-based approach stated clearly which of these they have in 
> mind.>>>
> >>> Henning

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip