From jon.crowcroft at cl.cam.ac.uk Wed Apr 29 02:34:44 2015 From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 29 Apr 2015 10:34:44 +0100 Subject: [e2e] j'accuse NFV Message-ID: Try as I might, I cannot really see Network Function Virtualization as much more than yet another telco landgrab on internet stuff. But somewhat more critically, I vew the idea of taking some of our precious middle bodily fluid flow processing functions, and moving them a) off the box built by a middlebox expert, and b) off the direct path, as actually counter-productive. Lets just take three boring run-of-the-arithmetic-mill such services:- load balancer - this is on the latency critical path before you get to any service - additional latency/hops/virtualization overhead is counter-indicated by any sane business model wan accelerator - especially for 2.9x-4.8xG wireless data networking services - these are kind of rather localized by definition, right? I mean they are dealing with impedance mis-matches in the interweb (tcp splice, etc - see https://www.icsi.berkeley.edu/icsi/publication_details?n=3730 firewall (or ids) - so these sit on trust boundaries, so it seems like a reduction in security to move them anywhere (like above a hypervisor, unless people are running, say, seL4:-), plus they might also be protecting the infrastructure itself as well as customers, so it would seem counter-productive to increase their attach surface in any way So ok, not all virtualization involves moving stuff to a different location often. But it does also imply some resource pooling (i.e. more than 1 instance of a Foo in the NFooV is running above the hyperv) - so this seems like you might be buying into a wealth of pain with elasticity, when you had just nailed down super-hard multiplexed allocation of cycles for forwarding or filtering or protocol adaptation or responsive redirection etc etc... I guess if you are in the business of proxies (web content caches etc) then it might make sense, but then it isn't really a Network Function that is being virtualized - its just you have some server blades running xen or vmware or clickos or mirageOS or whatever with an HTTPd on them - err, so next, will we be running IP forwarding virtualized? oh, no, wait, thats just a, um VPN... so if the telco folks do manage to Virtualize all those annoying middle boxes Netwreck Functions, perhaps they could just cause them all to evaporate and restore the sublime end-to-end internet goodness....carrier-degrade, surely? j http://openmirage.org/ http://cnp.neclab.eu/clickos/ https://sel4.systems/ etc From jamel at cin.ufpe.br Wed Apr 29 04:05:26 2015 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Wed, 29 Apr 2015 08:05:26 -0300 Subject: [e2e] j'accuse NFV In-Reply-To: References: Message-ID: generic platforms can perform as well as dedicated ones using multi-core, and other tweaks, etc. An NFV function is one that can be moved and applied anywhere anytime in the network to transcode, firewall, traffic prioritization at the radio access (RAN), aggregate flows, etc... Many products already allow hot upgrade of switch/router software, a good NFV use example. We need to make sure that NFV does not kill e2e semantics so that we can continue developing applications without thinking about the subnet details. But the subnet should be free to reorganize itself. New business models may emerge where an ISP may on demand (a la Cloud) subscribe to network functions just like any other service. If we reject NFV then we also need to move away from SDN using the same arguments. Djamel On Wed, Apr 29, 2015 at 6:34 AM, Jon Crowcroft wrote: > Try as I might, I cannot really see Network Function Virtualization as much > more than yet another telco landgrab on internet stuff. But somewhat more > critically, I vew the idea of taking some of our precious middle bodily > fluid flow processing functions, and moving them a) off the box built by a > middlebox expert, and b) off the direct path, as actually > counter-productive. Lets just take three boring run-of-the-arithmetic-mill > such services:- > > load balancer - this is on the latency critical path before you get to any > service - additional latency/hops/virtualization overhead is > counter-indicated by any sane business model > > wan accelerator - especially for 2.9x-4.8xG wireless data networking > services - these are kind of rather localized by definition, right? I mean > they are dealing with impedance mis-matches in the interweb (tcp splice, > etc - see > https://www.icsi.berkeley.edu/icsi/publication_details?n=3730 > > firewall (or ids) - so these sit on trust boundaries, so it seems like a > reduction in security to move them anywhere (like above a hypervisor, > unless people are running, say, seL4:-), plus they might also be protecting > the infrastructure itself as well as customers, so it would seem > counter-productive to increase their attach surface in any way > > So ok, not all virtualization involves moving stuff to a different location > often. But it does also imply some resource pooling (i.e. more than 1 > instance of a Foo in the NFooV is running above the hyperv) - so this seems > like you might be buying into a wealth of pain with elasticity, when you > had just nailed down super-hard multiplexed allocation of cycles for > forwarding or filtering or protocol adaptation or responsive redirection > etc etc... > > I guess if you are in the business of proxies (web content caches etc) then > it might make sense, but then it isn't really a Network Function that is > being virtualized - its just you have some server blades running xen > or vmware or clickos or mirageOS or whatever with an HTTPd on them > > - err, so next, will we be running IP forwarding virtualized? oh, no, > wait, thats just a, um VPN... > > so if the telco folks do manage to Virtualize all those annoying middle > boxes Netwreck Functions, perhaps they could just cause them all to > evaporate and restore the sublime end-to-end internet > goodness....carrier-degrade, surely? > > j > http://openmirage.org/ > http://cnp.neclab.eu/clickos/ > https://sel4.systems/ > etc > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. > From lars at netapp.com Wed Apr 29 04:24:24 2015 From: lars at netapp.com (Eggert, Lars) Date: Wed, 29 Apr 2015 11:24:24 +0000 Subject: [e2e] j'accuse NFV In-Reply-To: References: Message-ID: <51B1319A-37D1-45F0-B648-126CBBB5BE29@netapp.com> CC'ing the NFVRG, since they may have some opinions here :-) On 2015-4-29, at 11:34, Jon Crowcroft wrote: > > Try as I might, I cannot really see Network Function Virtualization as much > more than yet another telco landgrab on internet stuff. But somewhat more > critically, I vew the idea of taking some of our precious middle bodily > fluid flow processing functions, and moving them a) off the box built by a > middlebox expert, and b) off the direct path, as actually > counter-productive. Lets just take three boring run-of-the-arithmetic-mill > such services:- > > load balancer - this is on the latency critical path before you get to any > service - additional latency/hops/virtualization overhead is > counter-indicated by any sane business model > > wan accelerator - especially for 2.9x-4.8xG wireless data networking > services - these are kind of rather localized by definition, right? I mean > they are dealing with impedance mis-matches in the interweb (tcp splice, > etc - see > https://www.icsi.berkeley.edu/icsi/publication_details?n=3730 > > firewall (or ids) - so these sit on trust boundaries, so it seems like a > reduction in security to move them anywhere (like above a hypervisor, > unless people are running, say, seL4:-), plus they might also be protecting > the infrastructure itself as well as customers, so it would seem > counter-productive to increase their attach surface in any way > > So ok, not all virtualization involves moving stuff to a different location > often. But it does also imply some resource pooling (i.e. more than 1 > instance of a Foo in the NFooV is running above the hyperv) - so this seems > like you might be buying into a wealth of pain with elasticity, when you > had just nailed down super-hard multiplexed allocation of cycles for > forwarding or filtering or protocol adaptation or responsive redirection > etc etc... > > I guess if you are in the business of proxies (web content caches etc) then > it might make sense, but then it isn't really a Network Function that is > being virtualized - its just you have some server blades running xen > or vmware or clickos or mirageOS or whatever with an HTTPd on them > > - err, so next, will we be running IP forwarding virtualized? oh, no, > wait, thats just a, um VPN... > > so if the telco folks do manage to Virtualize all those annoying middle > boxes Netwreck Functions, perhaps they could just cause them all to > evaporate and restore the sublime end-to-end internet > goodness....carrier-degrade, surely? > > j > http://openmirage.org/ > http://cnp.neclab.eu/clickos/ > https://sel4.systems/ > etc > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. From kelsayed at gmail.com Wed Apr 29 04:49:49 2015 From: kelsayed at gmail.com (Khaled Elsayed) Date: Wed, 29 Apr 2015 13:49:49 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: References: Message-ID: Well, yes latency added for that remote NVF is important issue, but I guess most people are into NVF for the flexibility and ease of adding/removing/configuring new services. A wrong usage model for NFV can certainly be anti-productive for a network. Like many other things in engineering, it is a trade-off. Just my two cents. Khaled On Wed, Apr 29, 2015 at 11:34 AM, Jon Crowcroft wrote: > Try as I might, I cannot really see Network Function Virtualization as much > more than yet another telco landgrab on internet stuff. But somewhat more > critically, I vew the idea of taking some of our precious middle bodily > fluid flow processing functions, and moving them a) off the box built by a > middlebox expert, and b) off the direct path, as actually > counter-productive. Lets just take three boring run-of-the-arithmetic-mill > such services:- > > load balancer - this is on the latency critical path before you get to any > service - additional latency/hops/virtualization overhead is > counter-indicated by any sane business model > > wan accelerator - especially for 2.9x-4.8xG wireless data networking > services - these are kind of rather localized by definition, right? I mean > they are dealing with impedance mis-matches in the interweb (tcp splice, > etc - see > https://www.icsi.berkeley.edu/icsi/publication_details?n=3730 > > firewall (or ids) - so these sit on trust boundaries, so it seems like a > reduction in security to move them anywhere (like above a hypervisor, > unless people are running, say, seL4:-), plus they might also be protecting > the infrastructure itself as well as customers, so it would seem > counter-productive to increase their attach surface in any way > > So ok, not all virtualization involves moving stuff to a different location > often. But it does also imply some resource pooling (i.e. more than 1 > instance of a Foo in the NFooV is running above the hyperv) - so this seems > like you might be buying into a wealth of pain with elasticity, when you > had just nailed down super-hard multiplexed allocation of cycles for > forwarding or filtering or protocol adaptation or responsive redirection > etc etc... > > I guess if you are in the business of proxies (web content caches etc) then > it might make sense, but then it isn't really a Network Function that is > being virtualized - its just you have some server blades running xen > or vmware or clickos or mirageOS or whatever with an HTTPd on them > > - err, so next, will we be running IP forwarding virtualized? oh, no, > wait, thats just a, um VPN... > > so if the telco folks do manage to Virtualize all those annoying middle > boxes Netwreck Functions, perhaps they could just cause them all to > evaporate and restore the sublime end-to-end internet > goodness....carrier-degrade, surely? > > j > http://openmirage.org/ > http://cnp.neclab.eu/clickos/ > https://sel4.systems/ > etc > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. > From jamel at cin.ufpe.br Wed Apr 29 05:46:02 2015 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Wed, 29 Apr 2015 09:46:02 -0300 Subject: [e2e] j'accuse NFV In-Reply-To: <51B1319A-37D1-45F0-B648-126CBBB5BE29@netapp.com> References: <51B1319A-37D1-45F0-B648-126CBBB5BE29@netapp.com> Message-ID: added value is gained by combining / orchestrating both planes. NFV may open the way to open network hardware and OS and perhaps cheaper one. Software development is faster/cheaper than a new hardware project. Take multicast, just like LDP, a controller may distribute on demand multicast capable functions to dynamically form an overlay instead of relying on hardware that supports multicast. Even better, a node may self-appoint itself with such function. Djamel On Wed, Apr 29, 2015 at 8:24 AM, Eggert, Lars wrote: > CC'ing the NFVRG, since they may have some opinions here :-) > > On 2015-4-29, at 11:34, Jon Crowcroft wrote: > > > > Try as I might, I cannot really see Network Function Virtualization as > much > > more than yet another telco landgrab on internet stuff. But somewhat more > > critically, I vew the idea of taking some of our precious middle bodily > > fluid flow processing functions, and moving them a) off the box built by > a > > middlebox expert, and b) off the direct path, as actually > > counter-productive. Lets just take three boring > run-of-the-arithmetic-mill > > such services:- > > > > load balancer - this is on the latency critical path before you get to > any > > service - additional latency/hops/virtualization overhead is > > counter-indicated by any sane business model > > > > wan accelerator - especially for 2.9x-4.8xG wireless data networking > > services - these are kind of rather localized by definition, right? I > mean > > they are dealing with impedance mis-matches in the interweb (tcp splice, > > etc - see > > https://www.icsi.berkeley.edu/icsi/publication_details?n=3730 > > > > firewall (or ids) - so these sit on trust boundaries, so it seems like a > > reduction in security to move them anywhere (like above a hypervisor, > > unless people are running, say, seL4:-), plus they might also be > protecting > > the infrastructure itself as well as customers, so it would seem > > counter-productive to increase their attach surface in any way > > > > So ok, not all virtualization involves moving stuff to a different > location > > often. But it does also imply some resource pooling (i.e. more than 1 > > instance of a Foo in the NFooV is running above the hyperv) - so this > seems > > like you might be buying into a wealth of pain with elasticity, when you > > had just nailed down super-hard multiplexed allocation of cycles for > > forwarding or filtering or protocol adaptation or responsive redirection > > etc etc... > > > > I guess if you are in the business of proxies (web content caches etc) > then > > it might make sense, but then it isn't really a Network Function that is > > being virtualized - its just you have some server blades running xen > > or vmware or clickos or mirageOS or whatever with an HTTPd on them > > > > - err, so next, will we be running IP forwarding virtualized? oh, no, > > wait, thats just a, um VPN... > > > > so if the telco folks do manage to Virtualize all those annoying middle > > boxes Netwreck Functions, perhaps they could just cause them all to > > evaporate and restore the sublime end-to-end internet > > goodness....carrier-degrade, surely? > > > > j > > http://openmirage.org/ > > http://cnp.neclab.eu/clickos/ > > https://sel4.systems/ > > etc > > _______________________________________________ > > end2end-interest mailing list > > end2end-interest at postel.org > > http://mailman.postel.org/mailman/listinfo/end2end-interest > > Contact list-owner at postel.org for assistance. > > > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. > From randy at psg.com Wed Apr 29 11:55:20 2015 From: randy at psg.com (Randy Bush) Date: Thu, 30 Apr 2015 03:55:20 +0900 Subject: [e2e] j'accuse NFV In-Reply-To: References: Message-ID: one place nfv is making inroads is route reflectors. those who do not believe that the data plane should be congruent with the control plane (i am not among them) like the cost saving of not having the fancy forwarding silicon. they trade the risks and and ops costs of strange failure modes and ugly debugging for capital cost savings. randy From mattmathis at google.com Wed Apr 29 15:01:24 2015 From: mattmathis at google.com (Matt Mathis) Date: Wed, 29 Apr 2015 15:01:24 -0700 Subject: [e2e] j'accuse NFV In-Reply-To: References: Message-ID: Ahh Ha! A litmus test for True SDN: "Software" must mean programmable by the owner! (AND NOT LOCKED DOWN BY THE VENDOR). NVS is one of the required components to enable control programmability around rich prebuilt data (or control) functions. If the "software" in the control plane is locked down by the vendor, then NVS (or for that matter, all of SDN) is little more than buzzword bingo. It just doesn't matter. I bet the nfv route reflectors mentioned by Randy all contain custom code to implement policies that can not be implemented by any off-the-shelf products. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Wed, Apr 29, 2015 at 11:55 AM, Randy Bush wrote: > one place nfv is making inroads is route reflectors. those who do not > believe that the data plane should be congruent with the control plane > (i am not among them) like the cost saving of not having the fancy > forwarding silicon. they trade the risks and and ops costs of strange > failure modes and ugly debugging for capital cost savings. > > randy > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. > From l.wood at surrey.ac.uk Wed Apr 29 15:26:00 2015 From: l.wood at surrey.ac.uk (l.wood@surrey.ac.uk) Date: Wed, 29 Apr 2015 22:26:00 +0000 Subject: [e2e] j'accuse NFV In-Reply-To: References: , Message-ID: <1430346359454.75464@surrey.ac.uk> Ah, j'accuse TLA. Jon started this back in '95 with his j'accuse ATM piece just as ATM was heading to its prolonged deathbed https://groups.google.com/forum/#!topic/info.ietf/HCe2X7jzuNY I later wrote some j'accuse DTN pieces comparing DTN to ATM: http://www.ietf.org/mail-archive/web/dtn/current/msg00026.html http://www.ietf.org/mail-archive/web/dtn/current/msg00054.html and now we're accusing NFV? A _j'accuse TCP_ piece is long overdue. Lloyd Wood http://sat-net.com/L.Wood hasn't read Zola. Or Proust. Or Comer. From detlef.bosau at web.de Thu Apr 30 08:32:48 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 30 Apr 2015 17:32:48 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: References: Message-ID: <55424B20.5010708@web.de> Perhaps my comment is a typical "Detlef" comment, but again I look at https://www.icsi.berkeley.edu/pubs/techreports/TR-14-003.pdf Section 2: Modern Mobile Networks. Followed by the (both fundamental and brand new) insight, that these differ from other networks in fundamental ways. Afterwars, I see table 1 with a lot of acronyms, which are always pleasant look at and memorizing them has its benefit in prevention of Alzheimer disease, And I see these funny things like: > 2.1.1 The Control Plane: > The control plane logically consists of two compo- > nents: >  > Radio network. > The handset connects to the base sta- > tion (Node B in 3G networks), which in turn is con- > trolled by the Radio Network Controller (RNC). In > 4G LTE networks, the RNC and Node Bs combine > into an enhanced Node B (eNB); this has the advan- > tage of reducing latency to the handset. The RNC is > primarily responsible for managing spectrum and bat- > tery usage of handsets. >  > Support nodes. > The Serving GPRS Support Node, > or SGSN (S-GW in LTE), is responsible for billing, > authentication, mobility management, and relaying > packets between the base stations under its control > and the gateway (Gateway GSN, or GGSN, in 3G; > Packet Gateway, or P-GW, in LTE). It also intercon- > nects decoupled 2G, 3G, and 4G deployments for a > given mobile operator. The GGSN serves as the gate- > way for handsets to access the Internet Excuse me for being nasty here. But I read literally several hundred of texts like these and except from filling my mind with useless acronyms, all these things hide the forest for the trees: The major characteristic for any wireless link ("a connection from one IP hop to an adjacent one") is: First: We don't know in advance how long it takes to deliver the datagram. Second: We don't know in advance, whether the datagram can be successfully delivered at all. (Of course in bounded time or a bounded number of transmission attempts, but one of these has to be bounded, otherwise we would face the risk of an infinite head of line blocking, when there is only a milk can in the way in "optimum unfortunate position"). These are the most prominent properties of wireless networks - and these are the important ones. Whether a packet passes a GGSN or a GGR2D2SN or a GGC3POSN or however these funny boxes are called, simply doesn't matter. The aforementioned two issues are ehough to drive the mechanisms in upper layers crazy. And I'm a bit frustrated that many researches try to work around this gap, which can hardly be closed, by digging in a whole Encyclopaedia Britannica of complex and impressive details, which are more or less meaningless for the outside world. I know, that this sounds very upset. But it reflects my experience from the fast fifteen years. A packet switching link is a black box, where a packet is submitted by a sender and which delivers the packet at the receiver after some time or discards it. No more, no less. And from the basic idea of internetworking - or packet switching (in the sense auf Baran's work) it MUST NOT matter, whether we use - Ethernet - HSDPA - Avian Carriers - message in a bottle. This sounds harsh, this is harsh. But from my perspective, I see us running into the same trouble again and again for more than twenty years now. There are literally hundreds of models for mobile networks around, all of them providing a huge number of gory details of implementation, but hardly any of them providing new insight. The reason is stated above: The insight into the dominant properties of mobile networks is as simple - as frustrating. And the situation will not ameliorate only because we consider 200 parameters instead of 20. Or fifty kinds of middle boxes instead of thirty. Or because we introduce the ultimate well thought out virtual abstraction and management tool - perhaps enhanced by a "software defined networks management plane federation". Or, as a former employer of me used to say: What cannot be achieved in a simple manner, will neither be achieved in a complicated one. We are used to model links by a link specific quadruple (queueing delay, MAC delay, serialization delay, propagation delay) and we insist in this model from the earliest days of network simulation (as I remember from this list) in FORTRAN IV programs in the 1960ies for about fifty years now. This model is oversimplified - and we cannot escape this insight by making our simulators or algorithms more complex. Sorry for the rant, but during the last years, I got crazy on these things. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From mattmathis at google.com Thu Apr 30 18:14:51 2015 From: mattmathis at google.com (Matt Mathis) Date: Thu, 30 Apr 2015 18:14:51 -0700 Subject: [e2e] j'accuse NFV In-Reply-To: <1430346359454.75464@surrey.ac.uk> References: <1430346359454.75464@surrey.ac.uk> Message-ID: On Wed, Apr 29, 2015 at 3:26 PM, wrote: > Ah, j'accuse TLA. > SDN is not is the same bucket, let me assure you. As for TCP, good algorithms are portable between protocols, bad algorithms are dangerous at any scale. Once you fully deconstruct the protocol, I don't care so much about the packet format. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. From vern at ICIR.org Thu Apr 30 19:49:31 2015 From: vern at ICIR.org (Vern Paxson) Date: Thu, 30 Apr 2015 19:49:31 -0700 Subject: [e2e] j'accuse NFV In-Reply-To: <55424B20.5010708@web.de> (Thu, 30 Apr 2015 17:32:48 +0200). Message-ID: <20150501024931.B4CCF2C4066@rock.ICSI.Berkeley.EDU> > Perhaps my comment is a typical "Detlef" comment, but again I look at > ... > Sorry for the rant, but during the last years, I got crazy on these things. It's okay, we know to just ignore your messages. Vern