A couple of months ago, I had a problem with my home broadband connection, which intermittently cut out, or needed the router to be switched on/off again.
When I arranged a call-out from a BT engineer, I was told in no uncertain terms that if the problem was with my house-wiring, I'd be charged a fee. If it was a fault with the termination box or router, or external wiring, then BT would fix or replace it.
In other words, the little white BT-branded box and socket is the "demarcation point". It's where BT Openreach's responsibility stops, and the customer's starts. (BT Retail also provides me with an Infinity router, for Internet access, but that's technically a different service component, rather than network access).
Something similar is true with my mobile phone - the SIM card represents the demarcation-point for the connectivity part of Vodafone's service offering. It is essentially part of the network, rather than part of my phone. While I need operator settings and configurations to be pushed down to my device (eg APNs for Internet), that again is something separate.
Now consider what happens in a more software-driven, virtualised world.
For fixed connections, we may find either some sort of white-box termination unit (residential or business) down to which might be pushed virtual functions like a vRouter, vFirewall, vSmartHomeServer or whatever. Or alternatively, those virtualised functions might be located in a data-centre or local exchange server - there's a lot of talk about cloud-based vSetTopBoxes, for example.
And in mobile communications, we are starting to see eSIMs emerge for some use-cases, in which the manufacturer embeds a physical SIM chip in devices, and operator profiles get pushed down to it, or potentially switched between.
In both those cases, and various other forms of virtual/physical scenarios, we are moving from a world of clear and unambiguous demarcation points, to a world in which they are much less well-defined.
Today, if people switch SIM cards over to use a different network, or if a SIM stops working and needs replacing, or if consumers churn from one home broadband provider to another, then the lines of responsibility are pretty clear and obvious. There's very little finger-pointing that can occur.
But what happens with an eSIM? Is the manufacturer responsible if it stops working? Or is that the fault of the operator whose profile is working on it, the service provider which packaged and downloaded that profile, the software vendor(s) involved, the retailer where the device was bought - or worse, a second operator if the failure occured during a switch-over to a new profile? Who pays for the diagnosis, or for replacing the whole device if the eSIM can't be separated out? What happens if data is lost? Who is liable?
A similar set of questions apply with 3rd-party VNFs, or other software functions which drive underlying connectivity, or sit in the data path. We may be entering a world in which there is a "VNF AppStore" model - where the customer chooses between different software routers, or WiFi controllers, or firewalls. For businesses it may be possible to sell ethernet-style connectivity, and let the CIO take responsibility for those other connectivity-oriented functions, but that's clearly not an option for the consumer market.
This is different to higher-level virtual applications - if a game or a VoIP service stops working, but the network connection is still live, it's reasonable to assume that the connectivity function isn't to blame.
Overall, there's a lot of opacity here - nobody really knows how to deal with network responsibilities, in a world where there are no clear demarcation points. It's a set of lessons that will need to be learned very soon - and which will probably involve regulators or other authorities in disputes.
When I arranged a call-out from a BT engineer, I was told in no uncertain terms that if the problem was with my house-wiring, I'd be charged a fee. If it was a fault with the termination box or router, or external wiring, then BT would fix or replace it.
In other words, the little white BT-branded box and socket is the "demarcation point". It's where BT Openreach's responsibility stops, and the customer's starts. (BT Retail also provides me with an Infinity router, for Internet access, but that's technically a different service component, rather than network access).
Something similar is true with my mobile phone - the SIM card represents the demarcation-point for the connectivity part of Vodafone's service offering. It is essentially part of the network, rather than part of my phone. While I need operator settings and configurations to be pushed down to my device (eg APNs for Internet), that again is something separate.
Now consider what happens in a more software-driven, virtualised world.
For fixed connections, we may find either some sort of white-box termination unit (residential or business) down to which might be pushed virtual functions like a vRouter, vFirewall, vSmartHomeServer or whatever. Or alternatively, those virtualised functions might be located in a data-centre or local exchange server - there's a lot of talk about cloud-based vSetTopBoxes, for example.
And in mobile communications, we are starting to see eSIMs emerge for some use-cases, in which the manufacturer embeds a physical SIM chip in devices, and operator profiles get pushed down to it, or potentially switched between.
In both those cases, and various other forms of virtual/physical scenarios, we are moving from a world of clear and unambiguous demarcation points, to a world in which they are much less well-defined.
Today, if people switch SIM cards over to use a different network, or if a SIM stops working and needs replacing, or if consumers churn from one home broadband provider to another, then the lines of responsibility are pretty clear and obvious. There's very little finger-pointing that can occur.
But what happens with an eSIM? Is the manufacturer responsible if it stops working? Or is that the fault of the operator whose profile is working on it, the service provider which packaged and downloaded that profile, the software vendor(s) involved, the retailer where the device was bought - or worse, a second operator if the failure occured during a switch-over to a new profile? Who pays for the diagnosis, or for replacing the whole device if the eSIM can't be separated out? What happens if data is lost? Who is liable?
A similar set of questions apply with 3rd-party VNFs, or other software functions which drive underlying connectivity, or sit in the data path. We may be entering a world in which there is a "VNF AppStore" model - where the customer chooses between different software routers, or WiFi controllers, or firewalls. For businesses it may be possible to sell ethernet-style connectivity, and let the CIO take responsibility for those other connectivity-oriented functions, but that's clearly not an option for the consumer market.
This is different to higher-level virtual applications - if a game or a VoIP service stops working, but the network connection is still live, it's reasonable to assume that the connectivity function isn't to blame.
Overall, there's a lot of opacity here - nobody really knows how to deal with network responsibilities, in a world where there are no clear demarcation points. It's a set of lessons that will need to be learned very soon - and which will probably involve regulators or other authorities in disputes.
4 comments:
These are really good points. Another element of this problem is determining where the instrumentation will be implemented, and in the best case the demarcation points and the instrumentation points will coexist in the same physical/virtual elements. It's unfortunate that most consumer equipment almost completely lacks diagnostic instrumentation. Back to your example, try asking your cable company how much bandwidth they see to your home modem. The answer I get here (with Verizon FiOS and Brighthouse DOCSIS) is that they don't have any bandwidth, latency, or jitter tests that they can run on the modem to get an independent view of performance vs. the connected devices in my house. This leaves it open to being my problem or their problem, making me responsible for isolating the perceived fault. The same problem exists with wireless technology... my AT&T service with Wi-Fi calling leaves it to be my problem or AT&T's when calls don't complete, fail, or suffer audio quality issues. And these issues are exacerbated by virtualization.
Thanks for sharing our experience and knowledge. It is always good to have alternative to your broadband connection and most countries offer wireless routers and also SIM based services to keep you stay connected to the online world.
Precisely why we need a consistent framework that maps layers and boundary points consistently across an array of contextual supply and demand differences.
Nice opening to what's around the corner. As usual, Michael's comment cuts to the chase. It's probably going to be the Wild West all over again until industry and regulators get on the same page.
Post a Comment