Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

[Luca Muscariello <[e-mail]>]

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 <[e-mail]> wrote:

> On Thu, Jun 21, 2018 at 3:29 AM, Luca Muscariello
> <[e-mail]> 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 <[e-mail]> wrote:
> >>
> >> On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello
> >> <[e-mail]> 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,
> >>
>