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

[Tom Herbert <[e-mail]>]

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,
>>
>> I would say the answer is no, unless you can prove beyond doubt that
>> violating the protocol layering archictecure of the Internet and the
>> E2E model is necessary to get those benefits. I don't believe that
>> proof has yet been provided (for this proposal or any other similar
>> ones and there have been several). The Internet is architectured such
>> that any transport protocol can run over a common network layer.
>> Mobility is a network layer concern and so should be part of the
>> network layer. Therefore, a network mobility solution should work
>> transparently with any transport layer (TCP, UCP, QUIC, SCTP, and new
>> ones we may come up with). The network/transport separation is not
>> maintained when we we see intermediate devices trying to participate
>> the transport layer which entails DPI and inevitably leads to protocol
>> ossification in the Internet.
>>
>> So we want middelboxes be less invasive in the transport layer, not
>> more invasive! You may want to look at early PLUS/SPUD efforts that
>> were attempting to turn UDP into a sort of of network layer protocol
>> to carry path information read by the network (they choose UDP because
>> of compatibility with existing HW instead of defining a new transport
>> protocol). This even included encoding flow semantics for network to
>> track (like the request/response tracking in hICN). These efforts got
>> pushback in part because it violates protocol layer and encouraged
>> DPI. In hindsight the answer now seems pretty simple: network layer
>> information belongs in network layer headers. If you want to signal
>> the network then just put information extension headers like HBH
>> options. EH also permits data modification by intermediate devices
>> which is useful for things like OAM.
>>
>> > IMO, yes.
>> >
>> > Is it worthy to implement a new transport service in user-space such as
>> > LEDBAT, QUIC or the variety of transport
>> > services running for RTC apps? The answer is up to the application. It
>> > is
>> > the app that decides.
>>
>> It's not just up to the application. It's up the network operators,
>> hardware vendors, as well as the OS vendors. The OS is a big problem.
>> There is simply no concept of instantaneously changing all OS
>> deployments to a support a new feature like this. It takes years to
>> get significant traction. Look at a protocol like MPTCP: it's good
>> protocol and shows a lot of value to many users, but deployment has
>> been stymied by lack of OS support. We are trying to fix the
>> situation, but it's not easy.
>>
>> > So, no, there is no need to change all hosts. IMO the answer is it
>> > depends.
>> >
>> > 3) when you enable hICN in an end host the local network configuration
>> > manages two distinct namespaces,
>> > one for locators and one for identifiers (intended as location
>> > independent
>> > names).  An end-host can manage several
>> > locators because might be multi-homed and can manage several identifiers
>> > because it has been assigned identifiers
>> > to name data sources at the host: mic, camera, an app etc.
>> > This host continues to be able to open TCP or UDP sockets (but also SCTP
>> > or
>> > others) with the usual socket bindings.
>> >
>> > Just to give an example: We are using our hICN  transport library for
>> > WebRTC, MPEG-DASH among other things.
>> > An MPEG-DASH segment can be retrieved by a video client using TCP, QUIC
>> > or
>> > the consumer/producer socket.
>> > The video player can sequentially switch protocol to retrieve the
>> > segment.
>> > Not that it make any sense but it's just
>> > to explain that they live in the same end-host.  If the app considers
>> > that
>> > one transport service can provide
>> > features that are advantageous it can optionally switch to it.
>> > There is no intent to replace TCP, UDP, LEDBAT, QUIC, SCTP or any other
>> > transport protocol with the consumer/producer
>> > sockets.
>>
>> Okay, but these protocols still need to work in mobile networks, which
>> means in hICN enabled network you still need a mobile infrastructure
>> to handle these "legacy" protocols. That means there are two distinct
>> mobility models needed-- hICN is not simplifying matters in this
>> regard.
>>
>> To me, the hICN story would be a lot more compelling if the transport
>> and network layer are decoupled so there was one solution that
>> provided seamless mobility for everyone in the network regardless of
>> type of transport protocol they use or application that they wish to
>> run. Beyond that, there might be opportunities to improve
>> communications by some coordinated interaction with the network (like
>> we propose in FAST), but these are strictly optimization and not
>> requirements to make basic communications work.
>>
>> Tom
>>
>> >
>> > Luca
>> >
>> >
>> >
>> > On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert <[e-mail]> wrote:
>> >>
>> >> On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello
>> >> <[e-mail]> wrote:
>> >> > More on the mobility use case which also makes deployment options
>> >> > easier
>> >> > to
>> >> > digest
>> >> >
>> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/
>> >> >
>> >>
>> >> From the draft:
>> >>
>> >> "The goal of hICN is to ease ICN insertion in existing IP
>> >> infrastructure
>> >> by:
>> >> ...
>> >>  3.  minor modification to existing IP routers/endpoints;"
>> >>
>> >> Can you elaborate on this "minor modification"? Especially for
>> >> endpoints, which I assume means hosts, what is the scope, the
>> >> necessary modifications, and deployment model. Also, will applications
>> >> have to change or use a new API for hICN?
>> >>
>> >> If the implication of hICN is that all Internet hosts need to change
>> >> to support a new consumer/producer communications model, a new
>> >> transport protocol, and a new application API-- there's nothing minor
>> >> about that!
>> >>
>> >> Tom
>> >>
>> >> >
>> >> > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig)
>> >> > <[e-mail]> wrote:
>> >> >>
>> >> >> This draft is about hICN and discusses various deployment options
>> >> >> with
>> >> >> associated pros and cons, without supporting one specifically.
>> >> >> Clearly,
>> >> >> depending on  application requirements, on network constraints, on
>> >> >> phase of
>> >> >> deployment/transition  etc. one option may be preferrable over
>> >> >> another
>> >> >> one
>> >> >> (and different ones may coexist).
>> >> >>
>> >> >>
>> >> >> One of the described deployment options also discusses combination
>> >> >> of
>> >> >> hICN
>> >> >> and SRv6, without opposing one approach to the other, rather
>> >> >> exploiting
>> >> >> in
>> >> >> the combination the advantages of both ones.
>> >> >>
>> >> >>
>> >> >> Giovanna
>> >> >>
>> >> >> ________________________________
>> >> >> From: Int-area <[e-mail]> on behalf of Behcet
>> >> >> Sarikaya
>> >> >> <[e-mail]>
>> >> >> Sent: Wednesday, June 20, 2018 4:18 PM
>> >> >> To: Luca Muscariello
>> >> >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm
>> >> >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility
>> >> >> management through hICN (hICN-AMM): Deployment options
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello
>> >> >> <[e-mail]> wrote:
>> >> >>>
>> >> >>> I wonder whether this conversation should happen in the intarea wg
>> >> >>> mailing list
>> >> >>> as the main draft was posted there in the first place. I don't know
>> >> >>> if
>> >> >>> cross posting is welcome
>> >> >>> but I take the risk.
>> >> >>>
>> >> >>> Going back to the question, the transport changes are related to
>> >> >>> the
>> >> >>> request/reply semantic
>> >> >>> of the architecture. The two distinct forwarding paths described in
>> >> >>> the
>> >> >>> draft take care
>> >> >>> of forwarding requests or replies.This ends up in the transport
>> >> >>> layer
>> >> >>> as
>> >> >>> a unidirectional
>> >> >>> channel to recv data or snd data. The replies carry data
>> >> >>> originating
>> >> >>> from
>> >> >>> a  transport end-point (snd buffer)
>> >> >>> that binds to an identifier which is location independent, an IPv6
>> >> >>> number
>> >> >>> which is not a locator.
>> >> >>>
>> >> >>> The forwarding path of the requests is very close to unmodified
>> >> >>> IPv6
>> >> >>> with
>> >> >>> the DST address carrying the identifier.
>> >> >>> If you check in the draft an hICN node does one additional lookup
>> >> >>> in a
>> >> >>> local cache though. But you can ignore that
>> >> >>> for now for sake of clarity. What is important is the address
>> >> >>> rewrite
>> >> >>> operation made on the SRC address
>> >> >>> of the request. A copy of the request is stored in the local cache
>> >> >>> and
>> >> >>> the locator of the output interface is written in the
>> >> >>> SRC address before transmission. This is used by an upstream hICN
>> >> >>> or
>> >> >>> the
>> >> >>> final end-point to know the locator that
>> >> >>> will be used to reply.
>> >> >>>
>> >> >>> Replies coming from the snd end-point are label swapped but not
>> >> >>> like
>> >> >>> MPLS.
>> >> >>> The label is the identifier itself that is stored in the SRC
>> >> >>> address
>> >> >>> of
>> >> >>> the reply,
>> >> >>> whereas the DST address is a locator. In this forwarding path a
>> >> >>> lookup
>> >> >>> is
>> >> >>> made in the local cache to
>> >> >>> find a request (one or many) and the associated locator (one or
>> >> >>> many)
>> >> >>> that matches the identifier.
>> >> >>> The DST addr field of the replies is rewritten with the locator(s)
>> >> >>> just
>> >> >>> obtained from the lookup.
>> >> >>> This is how the reply is forwarded to the end-points that issued
>> >> >>> requests
>> >> >>> for this identifier.
>> >> >>>
>> >> >>> For the replies there is no FIB lookup on the identifier (as it is
>> >> >>> in
>> >> >>> the
>> >> >>> SRC addr field).
>> >> >>> There can be a lookup in the FIB on the locator stored in the DST
>> >> >>> of
>> >> >>> the
>> >> >>> reply to
>> >> >>> reach back the previous hICN node or eventually the original
>> >> >>> end-point.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> My humble question is: are you supporting SRv6 or hICN?
>> >> >>
>> >> >> Regards
>> >> >> Behcet
>> >> >>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <[e-mail]>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello
>> >> >>>> <[e-mail]> wrote:
>> >> >>>> > The paragraph you reported is from the draft that describes hICN
>> >> >>>> > to
>> >> >>>> > enable
>> >> >>>> > several use cases.
>> >> >>>> > Mobility is one of those, not the only one.
>> >> >>>> > To clarify, the draft on hICN mobility deployment options
>> >> >>>> > focuses
>> >> >>>> > on
>> >> >>>> > the 5G
>> >> >>>> > service based architecture.
>> >> >>>> >
>> >> >>>> > You may be asking
>> >> >>>> > 1) is it possible to get all the features provided by hICN w/o
>> >> >>>> > updates
>> >> >>>> > to
>> >> >>>> > the transport layer?
>> >> >>>> > 2) is changing the transport protocol unnecessary difficult to
>> >> >>>> > enable
>> >> >>>> > all
>> >> >>>> > the use cases mentioned in the draft?
>> >> >>>> >
>> >> >>>> Sorry, but I'm still missing something fundamental here. AFAICT,
>> >> >>>> the
>> >> >>>> idea of hICN is to put routes in the local routing table and use
>> >> >>>> existing forwarding and routing to forward packets to mobile
>> >> >>>> nodes.
>> >> >>>> So
>> >> >>>> if a node changes location, then the routing tables need to be
>> >> >>>> updated. Effectively this is a bunch of host routes that need to
>> >> >>>> be
>> >> >>>> maintained. At least this is what I gather from the draft:
>> >> >>>>
>> >> >>>> "hICN network layer is about using the IPv6 FIB to determine a
>> >> >>>> next
>> >> >>>> hop router to forward requests or using a local packet cache to
>> >> >>>> determine if an incoming request can be satisfied locally."
>> >> >>>>
>> >> >>>> Is this correct? If it is, then I sort of understand how hICN
>> >> >>>> could
>> >> >>>> be
>> >> >>>> used for mobility or virtualization without network overlays, but
>> >> >>>> then
>> >> >>>> I'm completely lost as to why this would require any changes in
>> >> >>>> the
>> >> >>>> transport layer.
>> >> >>>>
>> >> >>>> Tom
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> > IMO, the answers are no for both.
>> >> >>>> >
>> >> >>>> > Luca
>> >> >>>> >
>> >> >>>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <[e-mail]>
>> >> >>>> > wrote:
>> >> >>>> >>
>> >> >>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
>> >> >>>> >> <[e-mail]> wrote:
>> >> >>>> >> > Hi all,
>> >> >>>> >> >
>> >> >>>> >> > the draft below has been posted and describes deployments
>> >> >>>> >> > options
>> >> >>>> >> > for
>> >> >>>> >> > anchorless mobility management  by using
>> >> >>>> >> > the hicn network architecture that implements icn semantics
>> >> >>>> >> > in
>> >> >>>> >> > IPv6
>> >> >>>> >> > networks.
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/
>> >> >>>> >> >
>> >> >>>> >> > A background document has been posted to the internet area WG
>> >> >>>> >> > and
>> >> >>>> >> > reported
>> >> >>>> >> > here for your convenience.
>> >> >>>> >> > The core principle behind hicn and mobility management is
>> >> >>>> >> > that
>> >> >>>> >> > data
>> >> >>>> >> > sources
>> >> >>>> >> > are named using location independent names
>> >> >>>> >> > encoded in IPv6 addresses. The transport service sitting on
>> >> >>>> >> > top
>> >> >>>> >> > of
>> >> >>>> >> > the
>> >> >>>> >> > hicn
>> >> >>>> >> > architecture is not based on usual TCP/UDP sockets
>> >> >>>> >> > but on a novel consumer/producer transport service that will
>> >> >>>> >> > be
>> >> >>>> >> > described in
>> >> >>>> >> > another draft.
>> >> >>>> >>
>> >> >>>> >> From the draft: "The transport end-point offers two kinds of
>> >> >>>> >> services
>> >> >>>> >> to applications: a producer and a consumer service. The service
>> >> >>>> >> is
>> >> >>>> >> instantiated in the application by opening communication
>> >> >>>> >> sockets
>> >> >>>> >> with
>> >> >>>> >> an API to perform basic transport service operations:
>> >> >>>> >> allocation,
>> >> >>>> >> initialization, configuration, data transmission and
>> >> >>>> >> reception."
>> >> >>>> >>
>> >> >>>> >> This seems like a pretty dramatic rethink of the transport
>> >> >>>> >> layer
>> >> >>>> >> just
>> >> >>>> >> for the purposes of mobility management. Will there be a way to
>> >> >>>> >> use
>> >> >>>> >> hICN at the network layer with exsiting and unmodified
>> >> >>>> >> transport
>> >> >>>> >> protocols (i.e. can this be done without boiling the ocean)?
>> >> >>>> >>
>> >> >>>> >> Thanks,
>> >> >>>> >> Tom
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >> > The current document and a companion document that will be
>> >> >>>> >> > posted
>> >> >>>> >> > soon
>> >> >>>> >> > describe the different deployment options
>> >> >>>> >> > with special care to the 5G service based architecture.
>> >> >>>> >> > Thanks for the comments already received that helped
>> >> >>>> >> > completing
>> >> >>>> >> > this -00
>> >> >>>> >> > draft.
>> >> >>>> >> >
>> >> >>>> >> > Luca
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> > _______________________________________________
>> >> >>>> >> > dmm mailing list
>> >> >>>> >> > [e-mail]
>> >> >>>> >> > https://www.ietf.org/mailman/listinfo/dmm
>> >> >>>> >> >
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> dmm mailing list
>> >> >>> [e-mail]
>> >> >>> https://www.ietf.org/mailman/listinfo/dmm
>> >> >>>
>> >> >>
>> >> >