Re: [Nfvrg] results of virtual IMS and virtual SBC testing using COTS hardware. Thanks.

["B. Khasnabish" <[e-mail]>]

​Hi Diego,

Sure, no problem, and we understand.

​Thanks a lot.​

Best.

Bhumip

​


On Tue, Dec 15, 2015 at 2:01 PM, DIEGO LOPEZ GARCIA <
[e-mail]> wrote:

> Hi Bhumip,
>
> As NFVRG chair I’d like to request you to refrain from sending this kind
> of press releases through the NFVRG list. I hope that you’ll agree with me
> that this kind of communications is not relevant to the work of the group
> and follows a commercial style that is far from the open discussion on
> research and technical matters that is the goal of the NFVRG.
>
> Thanks for your understanding.
>
> Be goode,
>
> On 15 Dec 2015, at 12:35 , B. Khasnabish <[e-mail]> wrote:
>
>
> ..... In the tests, the *vIMS *& *vSBC *Cloud UniCore solutions achieved
> *high *Call Attempts Per Second(*CAPS*) capacity and throughput
> with *excellent *Mean Opinion Score (*MOS*) on a Commercial
> Off-The-Shelf (*COTS*) Intel-based server.
>
> (for more details, pls see below and at the following URL:
> http://www.cn-c114.net/577/a931739.html)
>
> ​====================================================
> ​Telefonica Successfully Completes ZTE vIMS and vSBC Performance Tests in
> Madrid NFV Reference Lab
>
> Updated:2015/12/9 10:53
>
> ZTE Corporation (0763.HK <http://0763.hk/> / 000063.SZ <http://000063.sz/>),
> a major international provider of telecommunications, enterprise and
> consumer technology solutions for the Mobile Internet, and Telefonica have
> jointly tested ZTE vIMS & vSBC VNFs, part of ZTE’s Cloud UniCore portfolio,
> in Telefonica’s NFV Reference Lab in Madrid, Spain. OpenMANO stack, the
> ground-breaking module for the easy creation and deployment of complex
> network scenarios of Telefonica’s NFV Reference Lab, was used to test ZTE’s
> solutions.
>
> The objective of the tests was to benchmark the deployment and performance
> of network functions virtualisation (NFV) solutions. The resulting data has
> provided clear evidence of the performance range service providers can
> expect from virtualised, software-based networking infrastructure.
>
> The establishment of NFV benchmarks is part of a joint effort by both
> companies within the Telefonica NFV Reference Lab framework. ZTE’s
> virtualised evolved packet core (vEPC) was previously tested in
> Telefonica’s Reference Lab as part of this effort.
>
> Cloud UniCore is based on virtualisation technology with software and
> hardware decoupling. Hardware resources are virtualised and various
> applications can be deployed on the same virtualised hardware platform.
> With the quick deployment capabilities of cloud computing, Cloud UniCore
> shortens the configuration and provisioning process from several weeks to
> several minutes, thus significantly enhancing agility of network expansion.
> It also implements dynamic scalability of virtualised network functions to
> eliminate capacity bottlenecks.
>
> The vIMS & vSBC Cloud UniCore solutions were deployed on a set of virtual
> machines (VM) which takes advantage of Intel? Xeon? processor-based servers
> and the Intel? Data Plane Development Kit in order to meet the performance
> required by the world's largest telecommunication and service providers.
>
> In the tests, the vIMS & vSBC Cloud UniCore solutions achieved high Call
> Attempts Per Second(CAPS)capacity and throughput with excellent Mean
> Opinion Score(MOS)on a Commercial Off-The-Shelf (COTS) Intel?-based server.
>
> The results delivered were outstanding, reaching Telefonica’s expected
> performance levels and smooth deployment objectives which allowed the test
> to be completed in a very short amount of time. ZTE and Telefonica will
> continue testing other elements of ZTE’s NFV portfolio in the coming months.
>
> Javier Gavilán, Planning and Technology Director at Telefonica- Global CTO
> said: “Telefonica has been and will be quite active on the evolution of
> network virtualisation technologies. With our NFV Reference Lab we aim to
> help the ecosystem of partners and network equipment vendors to test and
> develop virtualised network functions, so we are very pleased to
> collaborate with ZTE, a reference partner in NFV.”
>
> Antonio Elizondo, Head of Network Virtualisation Strategy at Telefonica
> I+D-Global CTO said: “The performance of ZTE vIMS & vSBC Cloud UniCore
> solutions is quite high and aligned with our expectations on a
> well-designed VNF, as it is needed for its deployment in the commercial
> network. We’re looking forward to continuing our work with ZTE, and
> strengthening our collaboration in the NFV field.”
>
> ZTE is committed to the development of NFV and cloud-based network
> technologies, cooperating with operators and technology providers around
> the world in proof of concept (PoC) projects. To date, ZTE’s virtualised
> core network solutions are deployed in 5 commercial, and 28 trial projects
> globally.
>   Source:C114
> ​ ​====================================================
>
> On Wed, Dec 2, 2015 at 11:03 AM, B. Khasnabish <[e-mail]> wrote:
>
>> ​Dave, Diego,
>>
>> Many Thanks to both of you.
>>
>> We plan to address these comments/suggestions in a future version of this
>> draft by
>>
>> (a) adding appropriate citations and reasons behind the assumptions ,
>>
>> ​(b) adopting a consistent definition,
>>
>> (c) exploring further the categories of COTS which are more suitable for
>> reliable services
>>
>> (d) discussing any add-on features of COTS that  may make certain COTS
>> hardware more suitable for reliable services than others
>>
>> (e) clearly mentioning the functions being simulated, and
>>
>> (f) exploring how the concept of silent error can be applied to both
>> hardware and software.
>>
>> Once again, many thanks, and we looking forward to other suggestions and
>> comments.
>>
>> Best.
>>
>> Bhumip
>> ​
>>
>> Best.
>> ​
>>
>>
>> On Tue, Dec 1, 2015 at 12:36 PM, DIEGO LOPEZ GARCIA <
>> [e-mail]> wrote:
>>
>>> Hi,
>>>
>>> <unchair_mode>
>>>
>>>  Just to express my support to all of Dave´s comments, and especially to
>>> the suspicion you express as conclusion. I see a great value in this draft
>>> from the point of view of strategies to achieve system-wide five-nines (or
>>> even beyond), and don’t see the need to confront COTS vs special-purpose
>>> telecom hardware.
>>>
>>> </unchair_mode>
>>>
>>> Be goode,
>>>
>>> On 1 Dec 2015, at 18:05 , Dave Dolson <[e-mail]> wrote:
>>>
>>> Some comments:
>>>
>>> 1. In the draft there is a premise that software errors on COTS hardware
>>> are different from hardware/software errors on dedicated telecom equipment.
>>> Obviously there could be silent hardware and software errors on any type of
>>> device. If you are going to have this premise, I think there needs to be
>>> some evidence, citation or explanation. In my career I have seen some
>>> pretty nasty hardware defects. Some were fatal but some were silent. One
>>> could claim that functional hardware flaws are *less* likely in COTS
>>> hardware, based on wide adoption and wide testing base. And both types of
>>> systems are largely controlled by software.
>>>
>>> 2. You state COTS machines have relaxed design criteria. Obviously this
>>> is a huge generalization, not supported by any citations. Certainly there
>>> are also custom hardware solutions with relaxed design criteria. I think
>>> you need to be specific by referring to specific designs. E.g., RAM with
>>> error correction? Dual power supplies? RAID disks? And in that case, you
>>> should discuss hardware with or without such features, not “COTS vs.
>>> traditional”.
>>>
>>> 3. Some of the language in the draft is derogatory or dismissive of COTS
>>> equipment. I think you should avoid such language to be respectful of
>>> different designs. (use of “cowboy manner”, “COTS hardware and all its
>>> undesirable features”, “the COTS hardware and its related software are
>>> notorious” …) Don’t treat the COTS systems as poorly designed; rather see
>>> the design goals as different.
>>>
>>> 4. On the subject of five-9s, clearly the NFV approach is to create
>>> five-9s at the *system* level vs. the level of the individual box. Can you
>>> consistently adopt that definition? For example, it is confusing near the
>>> end of section 5 when you say “the requirements for traditional five 9s
>>> could be relaxed while keeping the same user experience in downtime.” Above
>>> that you say “with only two 9s server availability, the five 9s server part
>>> of  system availability can be achieved,” which I think is a more useful
>>> statement.
>>>
>>> 5. I think it would be helpful if you explained the function of the
>>> system being simulated. It seems like it is a database replicated on
>>> several servers?
>>>
>>> My suspicion is that juxtaposing COTS vs. traditional telecom in this
>>> draft is distracting from the value of your research. The silent error idea
>>> could be applied to any type of hardware.
>>>
>>>
>>> Sorry, but I’m not comfortable commenting on your theoretical analysis
>>> or simulation. Yes, I know that's the main point of the work... But as seen
>>> above, I find the assumptions about COTS vs. traditional telecom hardware
>>> to undermine any conclusions.
>>>
>>>
>>> -Dave
>>>
>>>
>>>
>>> From: Nfvrg [mailto:[e-mail] <[e-mail]>] On
>>> Behalf Of B. Khasnabish
>>> Sent: Saturday, October 17, 2015 8:24 PM
>>> To: [e-mail]
>>> Subject: [Nfvrg] Requesting review of and comments on
>>> draft-mlk-nfvrg-nfv-​reliability-using-co​
>>>
>>> Dear All,
>>> We have recently published a draft
>>> (datatracker.ietf.org/doc/draft-mlk-nfvrg-nfv-reliability-using-cots/)
>>> on
>>> "NFV Reliability using COTS Hardware" discussing the results of a recent
>>> study on the feasibility of using Commercial Off-The-Shelf (COTS) hardware
>>> for virtualized network functions in telecom equipment.
>>> This draft is based on the presentation
>>> (https://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-9.pdf)
>>> during IETF/IRTF-92 mtg. in Dallas, TX, USA on
>>> the 26th of March 2015. This draft attempts to address the work item
>>> no. 4 in the charter (http://datatracker.ietf.org/rg/nfvrg/charter/)
>>>
>>> -------------------------------------------------------------------------------
>>> 4. Service Verification with Regards to Security and Resiliency
>>> Reliability and security issues and relevant solutions related to the
>>> nature of VNFs are the objectives of this work item.
>>>
>>> ----------------------------------------------------------------------------------
>>> We are requesting your review of this draft and comments on it
>>> so that we can update the draft ASAP.
>>> Many thanks in advance for your kind attention.
>>> Best.
>>> Bhumip
>>> =====================================================
>>> _______________________________________________
>>> Nfvrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/nfvrg
>>>
>>>
>>> --
>>> "Esta vez no fallaremos, Doctor Infierno"
>>>
>>> Dr Diego R. Lopez
>>> Telefonica I+D
>>> http://people.tid.es/diego.lopez/
>>>
>>> e-mail: [e-mail]
>>> Tel:    [phone]
>>> Mobile: [phone]
>>> ----------------------------------
>>>
>>>
>>> ------------------------------
>>>
>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
>>> puede contener información privilegiada o confidencial y es para uso
>>> exclusivo de la persona o entidad de destino. Si no es usted. el
>>> destinatario indicado, queda notificado de que la lectura, utilización,
>>> divulgación y/o copia sin autorización puede estar prohibida en virtud de
>>> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
>>> que nos lo comunique inmediatamente por esta misma vía y proceda a su
>>> destrucción.
>>>
>>> The information contained in this transmission is privileged and
>>> confidential information intended only for the use of the individual or
>>> entity named above. If the reader of this message is not the intended
>>> recipient, you are hereby notified that any dissemination, distribution or
>>> copying of this communication is strictly prohibited. If you have received
>>> this transmission in error, do not read it. Please immediately reply to the
>>> sender that you have received this communication in error and then delete
>>> it.
>>>
>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>>> destinatário, pode conter informação privilegiada ou confidencial e é para
>>> uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o
>>> destinatário indicado, fica notificado de que a leitura, utilização,
>>> divulgação e/ou cópia sem autorização pode estar proibida em virtude da
>>> legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos
>>> o comunique imediatamente por esta mesma via e proceda a sua destruição
>>>
>>
>>
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
> http://people.tid.es/diego.lopez/
>
> e-mail: [e-mail]
> Tel:    [phone]
> Mobile: [phone]
> ----------------------------------
>
>
> ------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>