Subject: Re: [Nfvrg] Comments on draft-irtf-nfvrg-gaps-network-virtualization

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 3 Oct 2016 16:17:31 +0000

Dear Carlos 

My turn to be sorry for my delayed answer. 
I have proposed some comments inline.

Cheers,

Nico

-----Message d'origine-----
De : Carlos Jesús Bernardos Cano [mailto:[email-masked]] 
Envoyé : mardi 27 septembre 2016 12:38
À : Kuhn Nicolas; [email-masked]; [email-masked]
Objet : Re: [Nfvrg] Comments on draft-irtf-nfvrg-gaps-network-virtualization

Hi Nicolas,

first of all, my apologies for the belated reply. I was on vacation when you sent this e-mail and then I preferred to wait until we started working on the new revision of the draft.

Thanks a lot for your comments. Please see comments in-line below.

On Fri, 2016-08-12 at 08:31 +0000, Kuhn Nicolas wrote:
> Dear all,
>  
> Thank you for providing this document. IMHO, the state-of-the art is 
> clear and provides the necessary information to fully understand the 
> document.

[Carlos] Thanks!

>  
> I have some minor comments (mostly related to the presentation) and a 
> suggestion for a supplementary open research challenge.
>  
> - Section 4.2 : I am not a native speaker, but Service Guarantees does 
> not ring a bell.
> I would propose something like "Guaranteeing quality-of-service"
> I would be worth providing a definition or examples at the beginning 
> of this section.

[Carlos] OK, we'll change it to "Guaranteeing quality-of-service". We will also add some examples.
[Nico] Great. 

>  
> "
>    An important difference between NFV and traditional Cloud computing
>    comes from the very strict requirements posed by NFV in terms of
>    performance, stability and consistency.  Although there are some
>    tools and mechanisms to improve this, such as Enhanced Performance
>    Awareness (EPA), SR-IOV, NUMA, DPDK, etc, these are still unsolved
>    challenges.  [I-D.natarajan-nfvrg-containers-for-nfv] analyzes
>    different virtualization technologies that could be used, instead 
> of
>    just using VMs.
> "
> The objective of this paragraph is unclear to me and should be said 
> more explicitly.
> The issue is guaranteeing a network quality-of-service, which is less 
> of an issue for "traditional cloud computing". One open research issue 
> is finding out technologies that are different from VM and more 
> suitable for dealing with network functionalities.

[Carlos] OK, thanks. We'll adapt the text to clarify it.
[Nico] Thanks!

>  
> "
>    While the IPPM WG is a long running WG
>    that started in 1997 it does not have a charter item or active 
> drafts
>    related to the topic of network virtualization.
> "
> Should the IPPM WG provide tools to evaluate enable metrics evaluation 
> whatever the use case?
> The network virtualization is a technology and the NFVRG WG could use 
> IPPM metrics to evaluate the quality-of-service.

[Carlos] Not sure I fully got your comment here. The point is that in addition to using IPPM metrics as defined to evaluate quality-of- service, there is also the need of metrics that evaluate the performance of the network virtualization technology as such (e.g., if chaining VNFs or VNFCs, latencies introduced by that, etc). Do you think that can be tackled somehow also using IPPM work?
[Nico] Thank you for clarification. It is much clearer to me now. I have re-read the text and I do not see where it should be improved. Maybe by adding something as follows: 
" 
   The IP Performance Metrics (IPPM) WG defines metrics that can be used
   to measure the quality and performance of Internet services and
   applications running over transport layer protocols (e.g.  TCP, UPD)
   over IP.  It also develops and maintains protocols for the
   measurement of these metrics.  While the IPPM WG is a long running WG
   that started in 1997 it does not have a charter item or active drafts
   related to the topic of network virtualization. In addition to using IPPM
   metrics to evaluate the QoS, there is a need for specific metrics for assessing
   the performance of network virtualization techniques. 
"

>  
> "
>    Related to the need of diagnostics tools, there is also a need in
>    terms of predictive analysis allowing for reaction before an
>    operation anomaly takes place.
> "
> This sentence is not clear to me.

[Carlos] The idea here was to mention that in order to promptly react upon an anomaly (e.g., a server malfunction), it is required to have monitoring and analytics tools in place that could identify signs of an imminent problem. Do you think it'd help to add some text around those lines in the document?
[Nico] Ok. Thanks for the clarification. Maybe the following would be clearer?
"
   On top of diagnostic tools that enable an assessment of the QoS, predictive
   analyses are required to react before anomalies occur. 
   
" 

>  
> People usually "jump around" in RFCs, so providing a high level view 
> of this section would help, such as:
> 4.2.1 Virtualization technologies
> 4.2.2 Metrics for NFV charaterization
> 4.2.3 Predictive analysis
> 4.2.4 Portability

[Carlos] OK, it's a good idea to add that structure to help identifying the topics.

>  
> - Section 4.3 :
> I am not sure whether "energy efficiency" is the only performance 
> related challenge for the network virtualization.
> There are many things that can be improved with network 
> virtualization.
> We could imagine "latency reduction", "improved link usage", etc.
> I would propose to have a more general section:
> "Performance improvement", and this section could speak about energy 
> efficiency as one of the things that can be improved.
> In short, section 4.2 could speak about "guaranteeing the same 
> performance", while section 4.3 could be on "improving them". In this 
> view, the discussion on the performance evaluation in section 4.2 
> could be done in a dedicated section, or
> 4.3 merged into 4.2.

[Carlos] Again, very good point. We'll follow your proposed approach.
>  
> - section 4.5 :
> What is "tactile Internet" ?

[Carlos] It a term now used to refer to a network with ultra low latency requirements (like in the order of 1 ms or less for end-to-end
communications)
[Nico] Thanks for the clarification.

> You could also mention that network slicing is a key for introducing 
> new actors in existing market at low cost - by letting new players 
> rent "blocks" of capacity, if this new market provides performance 
> that are adequate with the application needs.
> E.g. broadcasting updates to many sensors with satellite broadcasting 
> capabilities.

[Carlos] OK, we'll add that text. Thanks.

>  
> - section 4.X :
> I think that one other research challenge for the NFV is to be a key 
> driver in hybriding networks for better benefits from the various 
> radios technologies. By deploying the VNF with the adequate 
> parameterization, it could be easier to assess the
> mobile(LTE)/fix(WiFi)
> or the broadband/broadcast paradigms. This induces discussions on 
> aggregation networks in which the VNF would be deployed. This 
> efficient usage of the available radio access technologies, such as 
> WiFi, LTE and satellite, is also one of the objectives of the 5G.
> This discussion may be worth putting in the "network slicing" section 
> ?

[Carlos] I tend to agree but not yet grasp all your point. Can you suggest some specific text that you feel could be added to the section on "network slicing"?
[Nico] I may have missed the following part in my first look at the document:
"
Hence, it is
   envisioned that a single virtual core network could be used by
   slicing separate resources to dedicated radio access networks (RANs)
   that are better suited for specific use cases.
" 

This somehow covers what I meant. 

> I hope that this helps.

[Carlos] It does indeed. Thanks a lot!
[Nico] Great then! 

Carlos

>  
> Kind regards,
>  
> Nico
> _______________________________________________
> Nfvrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nfvrg

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 04 Oct 2016 09:22:30 +0200

Dear Nico,

Thanks a lot for your input. We'll add it in the next update!

Carlos

On Mon, 2016-10-03 at 16:17 +0000, Kuhn Nicolas wrote:
> first of all, my apologies for the belated reply. I was on vacation
> when you sent this e-mail and then I preferred to wait until we
> started working on the new revision of the draft.
> 
> [Carlos] Not sure I fully got your comment here. The point is that in
> addition to using IPPM metrics as defined to evaluate quality-of-
> service, there is also the need of metrics that evaluate the
> performance of the network virtualization technology as such (e.g.,
> if chaining VNFs or VNFCs, latencies introduced by that, etc). Do you
> think that can be tackled somehow also using IPPM work?
> [Nico] Thank you for clarification. It is much clearer to me now. I
> have re-read the text and I do not see where it should be improved.
> Maybe by adding something as follows: 
> " 
> [Carlos] The idea here was to mention that in order to promptly react
> upon an anomaly (e.g., a server malfunction), it is required to have
> monitoring and analytics tools in place that could identify signs of
> an imminent problem. Do you think it'd help to add some text around
> those lines in the document?
> [Carlos] It a term now used to refer to a network with ultra low
> latency requirements (like in the order of 1 ms or less for end-to-
> end
> communications)
> [Carlos] I tend to agree but not yet grasp all your point. Can you
> suggest some specific text that you feel could be added to the
> section on "network slicing"?