Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
Tom, the document does not describe nor rely on a specific transport protocol exactly because the discussion on transport protocols is out of scope for Internet Area/DMM. We have tried to disantangle in the document the benefits of the class of ID-based approaches and the additional ones of hICN within that class. For hICN we have pointed out the desirable requirements in terms of transport layer (request/reply, connectionless, multipath, capable of source discovery etc) sand have distinguished the benefits resulting from the core capability of hICN to route/forward packets on location-independent identifiers with hop-by-hop dynamic forwarding etc (a.k.a. in the ICN way) from those additionally provided by a flexible transport layer building on ICN principles. Giovanna From: Int-area on behalf of Tom Herbert Sent: Friday, June 22, 2018 11:55 PM To: Luca Muscariello Cc: int-area Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options On Fri, Jun 22, 2018 at 2:22 PM, Luca Muscariello mailto:luca.muscarie...@gmail.com>> wrote: As of now, we do not intend to standardise anything. The intended status for this draft is informational as indicated. The system described in the draft has actually been around for quite a while at the IRTF. It might appear of immense scope and novelty to you as you might not be aware about the work done at the IRTF on this topic. https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxsemantics/ https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxmessages/ https://datatracker.ietf.org/rg/icnrg/documents/ ccnx draft are going to IRSG for final approval poll soon and is good starting point if you're interested. On the other hand hICN is an IPv6 forwarding pipeline that realises CCN semantics in IPv6 and that is how it is indented to be analysed in this scope. When I read the charter of this WG it seems it couldn't be a better fit. And BTW I have been invited by other list members to share this information about the topic in this list. So I did. The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. The group also serves as a forum to distribute information about ongoing activities in the area, create a shared understanding of the challenges and goals for the area, and to enable coordination. [] Luca, No where in the int-area charter do I see that transport protocols are in scope. Transport protocols are the domain of transport area. Architectural questions, like whether intermediate devices should be participating in the transport layer protocols or even parsing E2E transport protocols, or whether it's acceptable to create new IP protocol that only works with select transport protocols, might be reasonable questions to pose in int-area I would think. Tom Luca On Fri, Jun 22, 2018 at 7:38 PM Tom Herbert mailto:t...@herbertland.com>> wrote: On Fri, Jun 22, 2018 at 9:15 AM, Luca Muscariello mailto:luca.muscarie...@gmail.com>> wrote: IMHO, there's no such a thing as a wrong question. But you can always ask another one. And BTW, I answered already to one of the questions you redo. Yes, there will be another draft on transport. It is not ready but I can have a technical report right before the IETF week and I might give a presentation at the next ICNRG meeting. That is out of scope for this list I think. Yes, it is out of scope for this list. If the intent is to standardize a new transport protocol then that obviously needs to be done in transport area.. Honestly, given the immense scope and novelty of what hICN is attempting to do, I have to wonder if this work is better to be done in IRTF. Tom ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
As of now, we do not intend to standardise anything. The intended status for this draft is informational as indicated. The system described in the draft has actually been around for quite a while at the IRTF. It might appear of immense scope and novelty to you as you might not be aware about the work done at the IRTF on this topic. https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxsemantics/ https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxmessages/ https://datatracker.ietf.org/rg/icnrg/documents/ ccnx draft are going to IRSG for final approval poll soon and is good starting point if you're interested. On the other hand hICN is an IPv6 forwarding pipeline that realises CCN semantics in IPv6 and that is how it is indented to be analysed in this scope. When I read the charter of this WG it seems it couldn't be a better fit. And BTW I have been invited by other list members to share this information about the topic in this list. So I did. The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. The group also serves as a forum to distribute information about ongoing activities in the area, create a shared understanding of the challenges and goals for the area, and to enable coordination. [...] Luca On Fri, Jun 22, 2018 at 7:38 PM Tom Herbert wrote: > > > On Fri, Jun 22, 2018 at 9:15 AM, Luca Muscariello < > luca.muscarie...@gmail.com> wrote: > >> IMHO, there's no such a thing as a wrong question. But you can always ask >> another one. >> And BTW, I answered already to one of the questions you redo. Yes, there >> will be another draft on transport. >> It is not ready but I can have a technical report right before the IETF >> week and I might give a presentation >> at the next ICNRG meeting. That is out of scope for this list I think. >> >> Yes, it is out of scope for this list. If the intent is to standardize a > new transport protocol then that obviously needs to be done in transport > area. Honestly, given the immense scope and novelty of what hICN is > attempting to do, I have to wonder if this work is better to be done in > IRTF. > > Tom > > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
IMHO, there's no such a thing as a wrong question. But you can always ask another one. And BTW, I answered already to one of the questions you redo. Yes, there will be another draft on transport. It is not ready but I can have a technical report right before the IETF week and I might give a presentation at the next ICNRG meeting. That is out of scope for this list I think. On the other hand, the draft provides information about how a transport service sits on top of this forwarding machinery. There might be several transport protocols of course, likewise today there are multiple transport protocols using IPv6, providing different kind of services. They can be TCP friendly, they can be lower than best effort such as LEDBAT vs TCP etc. Without loss of generality, I can say that we have one specific implementation of a transport protocol that provides reliable transport services. We have used several flow control laws and algorithms including AIMD, MIMD, and more recently BBR. It has been demoed in different venues for some applications such as MPEG-DASH at SIGCOMM last year and also MWC last year. Some analysis about that can be found in the following paper. J. Samain, et. al Dynamic Adaptive Video Streaming: Towards a Systematic Comparison of ICN and TCP/IP. IEEE Trans. Multimedia 19(10): 2166-2181 (2017) https://doi.org/10.1109/TMM.2017.2733340 Another transport service that we have implemented and that I might demo during the IETF week is one used for a scalable RTC system based on WebRTC, Chrome and Simulcast. Nothing to do with TCP friendliness of course for this protocol. On Fri, Jun 22, 2018 at 5:39 PM Tom Herbert wrote: > >> >> #3 is the wrong question to ask. The right question is "Does the new > transport protocol disrupt TCP?". Of particular interest, how does the > protocol interact with TCP on wire? What is the congestion control of the > new transport protocol? How is it "TCP friendly"? As Behcet mentioned, > these are not things that can be answered in a few sentences on an email > thread. The draft posted seems bereft of any details about the new > transport protocol; will another draft be coming that specifies the > transport protocol and answers questions like this? > > Tom > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Fri, Jun 22, 2018 at 8:06 AM, Luca Muscariello < luca.muscarie...@gmail.com> wrote: > I answered to 3. Please dig into the reply for the full answer. In short > it is no, it does not. > And BTW, I am aware I'm not providing any analysis and that I'm not trying > to resolve any big thing > in an email thread discussion, I never said I was. > The objective is to answer to clarification questions from list members > about recently posted drafts. > Luca > > #3 is the wrong question to ask. The right question is "Does the new transport protocol disrupt TCP?". Of particular interest, how does the protocol interact with TCP on wire? What is the congestion control of the new transport protocol? How is it "TCP friendly"? As Behcet mentioned, these are not things that can be answered in a few sentences on an email thread. The draft posted seems bereft of any details about the new transport protocol; will another draft be coming that specifies the transport protocol and answers questions like this? Tom > > >> > >> > 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 >> >>> >> > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
I answered to 3. Please dig into the reply for the full answer. In short it is no, it does not. And BTW, I am aware I'm not providing any analysis and that I'm not trying to resolve any big thing in an email thread discussion, I never said I was. The objective is to answer to clarification questions from list members about recently posted drafts. Luca >>> >>> >> > >>> >> > 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 > >> >>> > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
Luca, On Fri, Jun 22, 2018 at 3:46 AM, Luca Muscariello < luca.muscarie...@gmail.com> 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 wrote: > >> On Thu, Jun 21, 2018 at 3:29 AM, Luca Muscariello >> 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
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
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 wrote: > On Thu, Jun 21, 2018 at 3:29 AM, Luca Muscariello > 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. > > > > > > > >
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
as 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 wrote: > >> > >> On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello > >> 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) > >> > 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 on behalf of Behcet > Sarikaya > >> >> > >> >> 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 > >> >> 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 o
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
witch 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 wrote: >> >> On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello >> 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) >> > 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 on behalf of Behcet Sarikaya >> >> >> >> 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 >> >> 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-po
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
I am sorry but I'm not sure I get your question right. I am not sure SRv6 is just a tunnelling technique but I am not right person to talk about that. We do mention SRv6 in the draft to show how hICN can use it to steer the next-hop path for the request carrying the ID in the DST addr field and for the reply to steer the next-hop path carrying the locator in the DST addr field. In the first place hICN makes use of the IPv6 FIB. This is the default. But there are several interoperable protocols that might be included in the next-hop pipeline processing. Does it clarify your doubts? Luca On Wed, Jun 20, 2018 at 4:54 PM Behcet Sarikaya wrote: > > > On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) < > gcaro...@cisco.com> 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. >> >> >> > I don't understand. > SRv6 is tunneling technique while hICN is talking about anchoress mobility. > Did I get something wrong? > > Behcet > >> Giovanna >> -- >> *From:* Int-area on behalf of Behcet >> Sarikaya >> *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 < >> luca.muscarie...@gmail.com> 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? >> >>
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
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? 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. 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. Luca On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert wrote: > On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello > 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) > > 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 on behalf of Behcet Sarikaya > >> > >> Sent: Wednesday, June 20, 2018 4:18 PM > >> To: Luca Muscariello > >> Cc:
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello 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) > 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 on behalf of Behcet Sarikaya >> >> 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 >> 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 >
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) < gcaro...@cisco.com> 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. > > > I don't understand. SRv6 is tunneling technique while hICN is talking about anchoress mobility. Did I get something wrong? Behcet > Giovanna > -- > *From:* Int-area on behalf of Behcet Sarikaya > > *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 < > luca.muscarie...@gmail.com> 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 wrote: >> >>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >>> 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 >>
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
More on the mobility use case which also makes deployment options easier to digest https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) < gcaro...@cisco.com> 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 on behalf of Behcet Sarikaya > > *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 < > luca.muscarie...@gmail.com> 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 wrote: >> >>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >>> 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 her
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
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. On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: > On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello > 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 wrote: > >> > >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello > >> 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:
