Hi, all: It is a good technical debate.
There seems to be two kinds of trends as follows: 1. Take abstraction of lower layers to the upper as much one can for solving higher application layer problems (because lower layers are unable to provide satisfactory services to meet their those needs). 2. Make the applications independent of lower layers as much as you can (as billions of applications cannot afford in keeping up with the changes in the lower layers all the time - draining of resources - distractions from the main focus of building quality applications). For item 1, cross-layer approaches are becoming popular in ad hoc mobile wireless environments. However, they seem to be stopped up to layer 3. For item 2, it has been the trends from beginning of the computer communications networks. However, some of the problems faced in the lowers are not good enough to satisfy the upper layer applications' needs. For example, NAT crossing and ensuring of the end-to-end security for the real-time VoIP traffic. What do we do? We have to find a trade-off between the above two approaches. Let us see how we proceed in P2P-SIP protocol developments. BR/Radhika ----- Original Message ----- From: Bruce Lowekamp Date: Thursday, June 26, 2008 13:48 Subject: Re: [P2PSIP] HIP for P2P SIP To: Dean Willis Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], P2PSIP WG , [EMAIL PROTECTED], Henry Sinnreich > To some extent, these questions are orthogonal to the questions > about a > potential relationship between HIP and P2PSIP. > > Using HIP in a decentralized manner requires a distributed > rendezvous > service (and distributed name service). An overlay such as have > been > proposed by the various peer protocol proposals is ideal for > running > such services. > > P2PSIP requires a distributed registrar service. This service > also > requires a peer protocol (and some layers on top) and is not > supplied by > HIP. > > Now there are still some architectural questions of whether the > peer > protocol connections should be formed using HIP or not and also > questions about how to provide the best interface for applications > using > the services. > > Regardless of the answers to those questions, I hope we can > develop a > peer protocol that can be extended to support the various models > for > interacting with HIP (and work without HIP) and let future > development > and deployments determine what architectures are truly useful. > > Bruce > > > Dean Willis wrote: > > > > On Jun 26, 2008, at 1:42 AM, Gonzalo Camarillo wrote: > > > >> Hi Henry, > >> > >>> Yes, I know, developing HIP code looks like opening a whole > new can of > >>> worms, but nothing compares to what we are looking at now when > trying to > >>> traverse NAT, support mobility, multihoming, etc. for each > application>>> protocol and their various flavors separately. > >> > >> yes, that is what HIP is about (i.e., implementing those > functions at > >> a lower layer so that they do not have to be redesigned by > every > >> single application-layer protocol). > >> > > > > This asks the question "Why don't we believe in HIP in this role?" > > > > Is it because we've seen HIP struggling to advance for many > years and > > think we can move more quickly? > > > > Is it because we think the IETF's immune system will suppress > HIP but > > that application-level work can move through? > > > > Is it because we think that doing this stuff at the HIP level > requires > > widespread OS and IP stack changes, but that we can deploy > > application-level solutions without it? > > > > Is it because we think that if HIP solves the problems, then > there will > > be no fun work left to do on applications? > > > > Or is there something else? > > > > There must be some reason, as I would think that if people > really > > believed in HIP that the entire resources of the IETF would be > bent > > towards getting it wrapped up and ready to go, since solving > these > > problems again and again for every different application makes > no more > > sense than would reinventing IP for every application. > > > > -- > > Dean > > _______________________________________________ > > P2PSIP mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
