These solutions are not all isomorphic and comparison requires some careful taxonomy first. The -01 version of the draft Kalyani is taking care of will include that and will definitely help to compare things. https://datatracker.ietf.org/doc/draft-bogineni-dmm-optimized-mobile-user-plane
Let's wait for that work to be available to the list first, probably next week. Luca On Thu, Jun 21, 2018 at 8:47 PM Tom Herbert <t...@quantonium.net> wrote: > On Thu, Jun 21, 2018 at 3:29 AM, Luca Muscariello > <luca.muscarie...@gmail.com> wrote: > > There are several points raised here: > > 1) Alleged protocol layering violations and the e2e principle. > > 2) Relationship between the OS and transport services. > > > > > > 1) Many see the e2e principle as another instance of Occam's razor > applied > > to communication > > protocols function placement, I think it is even written in the first > paper > > that talks about it (Reed, Clark...). > > It's all about design patters for the development of distributed > > applications. > > Placement of function vertically in a layered architecture and > horizontally > > in the network path between end-points. > > > > In this respect, hICN, but I should say CCN and NDN realise that > principle > > with a new way to look at networking. > > Essentially naming data sources with location-independent identifiers. > > LISP, ILA, SRv6, and ILNP also do this. It's a core concept in > identifier locator separation protocols. ILNP requires changes to the > transport layer and endhosts to work, however ILA, SRv6, and LISP > don't-- these protocols operate strictly at the network layer as does > GTP. All of these have the goal to provide anchorless communication > (that could also be done in GTP as well given right changes to the > control plane). ILA and ILNP have they advantage that they don't have > any incur additional packet overhead, although I believe that ILNP > does use some extension headers which might be a convolution to use > over the Internet. > > Tom > > > > I am far from going to claim credits to the design principles behind > CCN/NDN > > as it is Van Jacobson and team > > who fundamentally designed that system. hICN is a convenient > implementation > > of CCN into IPv6 to make that > > design available in IPv6 now. > > > > Other attempts have introduced networking of location-independent > > identifiers in the Internet and the most notable > > one is LISP even if it is still the host to be identified. > > I would avoid to quote in full Brian Carpenter about this topic so I just > > report a reference. It's all in there. > > > > Brian E. Carpenter. 2014. IP addresses considered harmful. SIGCOMM > Comput. > > Commun. Rev. 44, 2 (April 2014), 65-69. DOI: > > http://dx.doi.org/10.1145/2602204.2602215 > > > > If we look at LISP for instance, the placement of protocol functions > > requires to have a mapping system. > > It is not exactly an instance of the Occam's razor though. But it is > > probably the best solution to a very > > specific problem formulation. > > > > The fact that the network has to support all transport protocols is > clearly > > false. The Internet is also IP multicast, > > among other things, > > and the transport protocols being cited (TCP/LEDBAT/QUIC etc) not only > will > > never work over IP multicast but > > have never been meant to at design time. > > > > hICN mobility for the 5G service based architecture is supposed to run > in a > > slice for the development of advanced > > applications (IoT, AR/VR, MEC etc) but also to rethink current > applications > > with these new transport services. > > This means that alternative solutions for mobility management in 5G, > such as > > GTP, LISP or derivations of it, are > > required to exist. > > In the current 5G standardisation effort there might be several mobility > > models co-existing and slicing has been > > designed in order to enable that. > > > > 2) This should probably be a whole new email thread and also other > mailing > > lists might be a better forum. > > > > It is true that applications make use of a communication API provided by > the > > OS. But that's quite generic. > > Those functions can be place in different parts of the OS. > > Our choice is to move communication functions, essentially the entire > stack, > > out of the kernel > > and use a server stack based on VPP https://git.fd.io and install > network > > functions just like any application in an application store. > > The client stack would also de deployed as a portable app. iOS 12 is the > > first mobile OS to adopt this kind of philosophy and we continue to adopt > > that approach for the time being. > > > > The fact that MPTCP encounters difficulties to be fully integrated in a > > specific OS component is an implementation issue > > that belongs to that particular component. The consequence of that > might be > > that multiple culturally different implementations > > and deployment options of network functions should exist in the future. > Not > > less. > > > > > > > > On Wed, Jun 20, 2018 at 7:18 PM Tom Herbert <t...@quantonium.net> wrote: > >> > >> On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello > >> <luca.muscarie...@gmail.com> wrote: > >> > The adjective minor is used in a comparative way. At least I intended > >> > that > >> > way. > >> > hICN allows to implement ICN features with less changes than using ICN > >> > as an > >> > overlay. > >> > On an absolute scale, I don't think that hICN requires negligible > >> > changes. > >> > So I haven't used the adjective minor as a synonym of negligible. > >> > I do think that having those changes are worthy for many apps. > >> > > >> > Back to your questions that I understand this way: > >> > 1) What is the hICN socket API? > >> > 2) Does hICN imply that all hosts have to change transport stack? > >> > 3) Does hICN disrupt the TCP/IP stack in an end host? > >> > > >> > > >> > 1) The answer to the first question is something that I wanted to > >> > discuss in > >> > the transport area > >> > but repeating does good. In the current implementation we support two > >> > different APIs. > >> > The first one is a BSD socket API, the second one is a post-socket API > >> > that > >> > is currently > >> > under development in the TAPS WG with a first integration in iOS 12 > >> > beta. > >> > I'm not > >> > contributing to TAPS but I think it is worthy to keep our > implementation > >> > updated with TAPS. > >> > I haven't finished to write a draft but I have a technical report > that I > >> > could share right before next IETF. > >> > > >> > 2) An application developer may or may not want to change to use this > >> > API. > >> > But I would turn the question around to ask, is it worthy to change > the > >> > application to exploit > >> > this new transport service and the underlying network service to get a > >> > certain number of benefits? > >> > >> Luca, > >> >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
