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

[Behcet Sarikaya <[e-mail]>]

Luca,



On Fri, Jun 22, 2018 at 3:46 AM, Luca Muscariello <
[e-mail]> wrote:

> 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?
>>
>
What about 3) here, I don't see any answer to that in the mail.

Also let me state that the analysis you are giving here involves so many
things like CCN/NDN, Id-Loc, transport layer, network layer
and so on, let me state that you can not resolve anything about such big
things within a few sentences.

Behcet

> >> >
>> >> >
>> >> > 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,
>> >>
>>
>