Re: [P2PSIP] HIP: optional, mandatory?

["David A. Bryan" <[e-mail]>]

Fully agree with Cullen here as far as the flexibility of the proposed
peer protocols to extend beyond SIP. Ever since the decision was made
(early in the charter process) that while SIP would be the primary
app, we would design the protocol in such a way that it could be
easily reused for other applications, this has been a guiding
principal in all of the "concrete proposals" and I know that all the
various authors/implementors of these things have kept that very much
in mind for at least the last couple of years. I'm quite confident
that the peer protocol can be used for many things besides SIP.

Cullen further points out that much of what you mentioned -- a fully
fleshed out HIP P2P core -- isn't something that is currently
chartered standards-track work for the HIP WG. Building a peer
protocol is in scope for us. We need to make sure that what we deliver
is something that can be used by other applications (including, one
could imagine, HIP), but I don't think we wait for things to emerge
from another group that we are chartered to do!

I want to be clear that I don't think this means we rule out having a
HIP transport, but I think that if we say that we are going to wait
for HIP to provide the complete underlying P2P fabric (peer protocol
and all) that we use, we have things backwards -- that is what we are
chartered here to provide. I also think it will be a long wait, since
that particular work isn't chartered for P2P standards at the moment.
I think deployment is critical here and sooner, rather than later. We
need to be picking a direction and going with it very soon, not
waiting for another group to deliver.

As a completely personal view, I think HIP is interesting, but I think
it is a far longer path (years) to deployment if we make it mandatory.
I want to keep looking at it as it evolves, and I'd love to see us
specify how it would work with a peer protocol as a transport, but I
don't want every P2PSIP app to require HIP.

My 2 cents.

David (as individual)


On Jan 11, 2008 11:38 AM, Cullen Jennings <[e-mail]> wrote:
>
> 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 <with my individual hat on>
>
> >
> > 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 <with my individual hat on>
> >> 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
> >>> [e-mail]
> >>> https://www1.ietf.org/mailman/listinfo/p2psip
> >> _______________________________________________
> >> P2PSIP mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/p2psip
> >>
> >
>
>
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
>



-- 
David A. Bryan
[e-mail]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip