Re: REG: Draft draft-rosa-bmwg-vnfbench-00

Hi Sudhin Jacob,
Sorry for late reply, below follow some ideas regarding your questions.

About the first question.
Scaling VNFs is part of a topic under discussion, and proper metrics on how
to target such scenario (e.g., trigger orchestration scalng up/down) is a
metric that in our belief could be obtained by signaling mechanisms between
VNFs and orchestration entities (e.g., NFVO).
Coloured packets would describe specific traffic profiles, and therefore
characterize a particular type of service. Our current approach assigns
this definition of coloured packets in the case of benchmarking a VNF to be
established by the VNF developers (building what we referenced as a VNF
Benchmark Profile), that is an open topic for discussion. Because the
profile, in our view,  will determine if a VNF specific metrics is obtained
by the needs to be benchmarked with coloured packets, and specially, how
coloured packets will be defined.

About the second question.
The definition of throughput follows the specification defined in
https://tools.ietf.org/html/rfc2544#section-26.1
In the case of a burst of events (packet bursts) latency is also a
measurement that can be inferred, depending on the VNF benchmarking
profile. I.e., a burst of packets can represent different characteristics
according to the VNF itself (e.g., a firewall and a load balancer would
behave differently in case of bursts of events).
Again, we are doing research on the definition of such benchmarking
profiles that could define characteristics of metrics extraction for
particular VNFs. And we still don`t know, as in the case of burst events,
if the VNF can be benchmarked considering it`s internal functional
behaviours, for example. I think, part of the metrics definition come from
VNFs functionality and other parts from the service definition that the VNF
was defined to attend. How to benchmark a VNF considering these two factors
is something I am looking for.

I hope I could clarify your points.

And the draft is under a consistent review, inputs are welcome.

Best regards,
Raphael


On Sat, Jul 2, 2016 at 9:00 PM, <[email protected]> wrote:

> Send bmwg mailing list submissions to
>         [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/bmwg
> or, via email, send a message with subject or body 'help' to
>         [email protected]
>
> You can reach the person managing the list at
>         [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bmwg digest..."
>
>
> Today's Topics:
>
>    1. REG: Draft draft-rosa-bmwg-vnfbench-00 (Sudhin Jacob)
>    2. REG: draft-kim-bmwg-ha-nfvi-01 (Sudhin Jacob)
>    3. IETF-96 session: Agenda requests and Remote Participation
>       (MORTON, ALFRED C (AL))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 2 Jul 2016 01:50:14 +0000
> From: Sudhin Jacob <[email protected]>
> To: "[email protected]" <[email protected]>
> Subject: [bmwg] REG: Draft draft-rosa-bmwg-vnfbench-00
> Message-ID:
>         <
> BN6PR05MB2963E40766A41DD3068C779CC2260@BN6PR05MB2963.namprd05.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Respected Authors,
>
> I had gone through the draft. Could you please think of a scenario when
> there is an event like sports match/music concert where there will be spike
> in services after that that it will be removed, rapid adding of "N"
> services and deleting it back to the original "n"
> Service how the system will behave. Could you please  share your thought
> on this.  Could you please think of a situation how to handle colored
> packets.
>
> 6.1.3
> . Frame Loss Rate
> Objective: Provide, for a particular set of resources allocated, the
> frame loss rate among two or more VNF ports, expressed in VNF-BP.
>
> Could you please explain how you measure the throughput. Kindly let me
> know whether you are using frame of different size for measuring the
> throughput.  Correct me if I am wrong do we require latency measurement
> during a burst of events.
>
> Section 6.1.2
> . Latency
> Objective: Provide, for a particular set of resources allocated, the
> latency among two or more VNF ports, expressed in VNF-BP.
> Prerequisite: VNF (SUT) must be deployed and stable and its
> allocated resources collected. VNF must be reachable by agents.
> The frame size and respective throughput to be used for agents
> must be defined in the VNF-BP.
>
> Regards,
> Sudhin
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/bmwg/attachments/20160702/5b8b7117/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sat, 2 Jul 2016 07:26:02 +0000
> From: Sudhin Jacob <[email protected]>
> To: "[email protected]" <[email protected]>
> Subject: [bmwg] REG: draft-kim-bmwg-ha-nfvi-01
> Message-ID:
>         <
> BN6PR05MB2963E555C7C627850FFC0B5DC2260@BN6PR05MB2963.namprd05.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Respected Authors,
>
> Correct me if I am wrong there must be packet loss to be tested isn't as a
> port of HA. How the packet will be routed during the failover time kindly
> clarify.
>
>
> 3.2
> . Failover Time Check
> Even though the components of NFV infrastructure are redundant,
> failover time can be long. For example, when a failure happens, the
> VNF with failure stops and should be replaced by backup VNF but the
> time to be shifted to the new VNF can be varied with the VNF;
> stateless or stateful. Namely, redundancy does not guarantees high
> availability and short failover time is required to reach high
> availability. This section discusses strategy about measuring
> failover time.
>
> Could you please clarify the benchmarking on stateful and stateless
> failover.
>
> Regards,
> Sudhin
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/bmwg/attachments/20160702/6186ff22/attachment.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Sat, 2 Jul 2016 14:18:57 -0400
> From: "MORTON, ALFRED C (AL)" <[email protected]>
> To: "[email protected]" <[email protected]>
> Subject: [bmwg] IETF-96 session: Agenda requests and Remote
>         Participation
> Message-ID:
>         <
> 4AF73AA205019A4C8A1DDD32C034631D4593BBF5E2@NJFPSRVEXG0.research.att.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> BMWG,
>
> Please send requests for agenda time, along with the issues
> you wish to discuss and the related drafts, to the chairs:
> [email protected] and [email protected]
>
> IOW, if you have an issue you'd like to discuss on
> *any* WG draft, this is a chance to spend some
> valuable face2face time to resolve it efficiently!
>
> Also, for folks participating remotely, or those who
> would like to present remotely, please let us know who you
> are (and other details). The WG chairs must take some
> steps with our friends at Meetecho to make this possible.
>
> thanks,
> bmwg co-chairs
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bmwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bmwg
>
>
> ------------------------------
>
> End of bmwg Digest, Vol 142, Issue 1
> ************************************
>

_______________________________________________
bmwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bmwg