MORTON, ALFRED C (AL)
2018-09-02 14:56:22 UTC
Hi Samuel and Jacob,
below are the comments I promised on your draft
(most sections through 5).
regards,
Al
(as a participant)
2. Conventions used in this document
[acm]
There's a new version of this paragraph, see RFC 8137
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
the new version clarifies that capitalization is needed for requirements,
and includes the word "NOT RECOMMENDED".
Segment 1 Packet 1
+-------------------------+ +-------------------------+
| Headers | | Headers |
| +---------------------+ | | +---------------------+ |
| | Pay Load - upto 64K | | | | Pay Load < 1500 | |
| +---------------------+ | | +---------------------+ |
+-------------------------+ +-------------------------+
[acm] s/Pay Load/Payload/
Hence, normal benchmarking methods are not relevant to the NVPs.
[acm]
So far, the only differences I see are
- TSO for TCP (layer 4)
- LRO with large payloads.
But we've dealt with Stateful traffic before (TCP connections in Firewalls).
I need to think about how 64k packets affects what we do, it certainly makes
BW the main event, and not header-processing rate.
Essentially, I'm looking to help add more definition and differentiation
for the Scope of this draft.
With Micro-services architecture, a single web app of the three tier
application model could now have 100s of smaller apps dedicated to
do just one job.
These 100s of small one responsibility only services will MUST be
secured into their own segment - hence pushing the scale boundaries
of the overlay from both simple segmentation perspective and also
from a security perspective.
[acm]
Micro-services means a fairly complete departure from the
monolithic architectures of the past. Some include
Micro-services as an aspect of Cloud-native NFV, where
containers are king (although, you haven't mentioned
containers yet, why not?). So there is some NVP-NFV overlap
here, too.
4. Scope
This document does not address Network Function Virtualization has
been covered already by previous IETF documents
(https://datatracker.ietf.org/doc/draft-ietf-bmwg-virtual-
net/?include_text=1) the focus of this document is Network
Virtualization Platform where the network functions are an intrinsic
part of the hypervisor's TCP stack, working closer to the
application layer and leveraging performance optimizations such
TSO/RSS provided by the TCP stack and the underlying hardware.
[acm]
Is this really a hypervisor, or a container management system?
[acm] the next sentence is a key one for the comment that follows:
... Because of the nature of
virtual infrastructures and multiple elements being hosted on the
same physical infrastructure, influence from other components cannot
be completely ruled out. For example, unlike in physical
infrastructures, logical routing or distributed firewall MUST NOT be
benchmarked independent of logical switching. System Under Test
definition MUST include all components involved with that particular
test.
Kommu & Rapp Expires December 27, 2018 [Page 8]
Internet-Draft NVP Benchmarking Considerations June 2018
+---------------------------------------------------+
| System Under Test |
| +-----------------------------------------------+ |
| | Hyper-Visor | |
| | | |
| | +-------------+ | |
| | | NVP | | |
| | +-----+ | Switch/ | +-----+ | |
| | | VM1 |<------>| Router/ |<------>| VM2 | | |
| | +-----+ VW | Fire Wall/ | VW +-----+ | |
| | | etc., | | |
| | +-------------+ | |
| | Legend | |
| | VM: Virtual Machine | |
| | VW: Virtual Wire | |
| +------------------------_----------------------+ |
+---------------------------------------------------+
Figure 2 Intra-Host System Under Test
[acm] Figure 2 is not realistic IMO, there should be at least one
Physical Interface in the path under test. Further, this is exactly the
sort of testing discussed in RFC 8204 (and the controversial
China Mobile draft that used VM traffic Generators).
(I think we have used NFVI (Infrastructure) synonymously with your NVP.)
[acm] Need to show the Physical NICs in Figure 3
Kommu & Rapp Expires December 27, 2018 [Page 9]
Internet-Draft NVP Benchmarking Considerations June 2018
+---------------------------------------------------+
| System Under Test |
| +-----------------------------------------------+ |
| | Hyper-Visor | |
| | +-------------+ | |
| | | NVP | | |
| | +-----+ | Switch/ | +-----+ | |
| | | VM1 |<------>| Router/ |<------>| VM2 | | |
| | +-----+ VW | Fire Wall/ | VW +-----+ | |
| | | etc., | | |
| | +-------------+ | |
| +------------------------_----------------------+ |
| ^ |
| | Network Cabling |
| v |
| +-----------------------------------------------+ |
| | Physical Networking Components | |
| | switches, routers, firewalls etc., | |
| +-----------------------------------------------+ |
| ^ |
| | Network Cabling |
| v |
| +-----------------------------------------------+ |
| | Hyper-Visor | |
| | +-------------+ | |
| | | NVP | | |
| | +-----+ | Switch/ | +-----+ | |
| | | VM1 |<------>| Router/ |<------>| VM2 | | |
| | +-----+ VW | Fire Wall/ | VW +-----+ | |
| | | etc., | | |
| | +-------------+ | |
| +------------------------_----------------------+ |
+---------------------------------------------------+
Legend
VM: Virtual Machine
VW: Virtual Wire
Figure 3 Inter-Host System Under Test
below are the comments I promised on your draft
(most sections through 5).
regards,
Al
(as a participant)
2. Conventions used in this document
[acm]
There's a new version of this paragraph, see RFC 8137
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
the new version clarifies that capitalization is needed for requirements,
and includes the word "NOT RECOMMENDED".
Segment 1 Packet 1
+-------------------------+ +-------------------------+
| Headers | | Headers |
| +---------------------+ | | +---------------------+ |
| | Pay Load - upto 64K | | | | Pay Load < 1500 | |
| +---------------------+ | | +---------------------+ |
+-------------------------+ +-------------------------+
[acm] s/Pay Load/Payload/
Hence, normal benchmarking methods are not relevant to the NVPs.
[acm]
So far, the only differences I see are
- TSO for TCP (layer 4)
- LRO with large payloads.
But we've dealt with Stateful traffic before (TCP connections in Firewalls).
I need to think about how 64k packets affects what we do, it certainly makes
BW the main event, and not header-processing rate.
Essentially, I'm looking to help add more definition and differentiation
for the Scope of this draft.
With Micro-services architecture, a single web app of the three tier
application model could now have 100s of smaller apps dedicated to
do just one job.
These 100s of small one responsibility only services will MUST be
secured into their own segment - hence pushing the scale boundaries
of the overlay from both simple segmentation perspective and also
from a security perspective.
[acm]
Micro-services means a fairly complete departure from the
monolithic architectures of the past. Some include
Micro-services as an aspect of Cloud-native NFV, where
containers are king (although, you haven't mentioned
containers yet, why not?). So there is some NVP-NFV overlap
here, too.
4. Scope
This document does not address Network Function Virtualization has
been covered already by previous IETF documents
(https://datatracker.ietf.org/doc/draft-ietf-bmwg-virtual-
net/?include_text=1) the focus of this document is Network
Virtualization Platform where the network functions are an intrinsic
part of the hypervisor's TCP stack, working closer to the
application layer and leveraging performance optimizations such
TSO/RSS provided by the TCP stack and the underlying hardware.
[acm]
Is this really a hypervisor, or a container management system?
[acm] the next sentence is a key one for the comment that follows:
... Because of the nature of
virtual infrastructures and multiple elements being hosted on the
same physical infrastructure, influence from other components cannot
be completely ruled out. For example, unlike in physical
infrastructures, logical routing or distributed firewall MUST NOT be
benchmarked independent of logical switching. System Under Test
definition MUST include all components involved with that particular
test.
Kommu & Rapp Expires December 27, 2018 [Page 8]
Internet-Draft NVP Benchmarking Considerations June 2018
+---------------------------------------------------+
| System Under Test |
| +-----------------------------------------------+ |
| | Hyper-Visor | |
| | | |
| | +-------------+ | |
| | | NVP | | |
| | +-----+ | Switch/ | +-----+ | |
| | | VM1 |<------>| Router/ |<------>| VM2 | | |
| | +-----+ VW | Fire Wall/ | VW +-----+ | |
| | | etc., | | |
| | +-------------+ | |
| | Legend | |
| | VM: Virtual Machine | |
| | VW: Virtual Wire | |
| +------------------------_----------------------+ |
+---------------------------------------------------+
Figure 2 Intra-Host System Under Test
[acm] Figure 2 is not realistic IMO, there should be at least one
Physical Interface in the path under test. Further, this is exactly the
sort of testing discussed in RFC 8204 (and the controversial
China Mobile draft that used VM traffic Generators).
(I think we have used NFVI (Infrastructure) synonymously with your NVP.)
[acm] Need to show the Physical NICs in Figure 3
Kommu & Rapp Expires December 27, 2018 [Page 9]
Internet-Draft NVP Benchmarking Considerations June 2018
+---------------------------------------------------+
| System Under Test |
| +-----------------------------------------------+ |
| | Hyper-Visor | |
| | +-------------+ | |
| | | NVP | | |
| | +-----+ | Switch/ | +-----+ | |
| | | VM1 |<------>| Router/ |<------>| VM2 | | |
| | +-----+ VW | Fire Wall/ | VW +-----+ | |
| | | etc., | | |
| | +-------------+ | |
| +------------------------_----------------------+ |
| ^ |
| | Network Cabling |
| v |
| +-----------------------------------------------+ |
| | Physical Networking Components | |
| | switches, routers, firewalls etc., | |
| +-----------------------------------------------+ |
| ^ |
| | Network Cabling |
| v |
| +-----------------------------------------------+ |
| | Hyper-Visor | |
| | +-------------+ | |
| | | NVP | | |
| | +-----+ | Switch/ | +-----+ | |
| | | VM1 |<------>| Router/ |<------>| VM2 | | |
| | +-----+ VW | Fire Wall/ | VW +-----+ | |
| | | etc., | | |
| | +-------------+ | |
| +------------------------_----------------------+ |
+---------------------------------------------------+
Legend
VM: Virtual Machine
VW: Virtual Wire
Figure 3 Inter-Host System Under Test