idnits 2.17.1 draft-faibish-nfsv4-data-reduction-attributes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 24, 2019) is 1586 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5661 (ref. '4') (Obsoleted by RFC 8881) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network File System Version 4 S. Faibish 2 Internet-Draft D. Black 3 Intended status: Informational P. Shilane 4 Expires: June 24, 2020 Dell EMC 5 December 24, 2019 7 Support for Data Reduction Attributes in nfsv4 Version 2 8 draft-faibish-nfsv4-data-reduction-attributes-01 10 Abstract 12 This document proposes extending NFSv4 operations to add new 13 named attributes to be used in the protocol to provide information 14 about the data reduction properties of files. The new data reduction 15 attributes are proposed to allow the client application to 16 communicate to the NFSv4 server data reduction attributes 17 associated with files and directories using new metadata, 18 communicated to the Block Storage data reduction engines. 19 Corresponding new named attributes are proposed to allow clients 20 and client applications to query the server for data reduction 21 attributes support and allow to get and set data reduction 22 attributes on files and directories. Such data reduction 23 metadata is used as hints to the file server about what type of data 24 reduction to apply. The proposed data reduction attributes include 25 achievable ratios for compression and deduplication plus whether 26 each data reduction technique applies to a file or directory. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of Internet-Draft Shadow Directories can be accessed at 44 https://www.ietf.org/standards/ids/internet-draft-mirror-sites/. 46 This Internet-Draft will expire on June 24, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. New Named Attributes . . . . . . . . . . . . . . . . . . . . 8 69 4. File System Support . . . . . . . . . . . . . . . . . . . . . 9 70 5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Data Reduction Named Attributes . . . . . . . . . . . . . . . 9 72 7. Protocol Enhancements . . . . . . . . . . . . . . . . . . . . 10 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . 11 76 10.1. Normative References . . . . . . . . . . . . . . . . 11 77 10.2 Informative References . . . . . . . . . . . . . . . . 11 78 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 Many NFS servers use expensive solid state media, e.g., NVMe SSDs, 84 complemented by data reduction processing of files to reduce their 85 size on the Block Storage via compression and deduplication, thereby 86 optimizing media usage. This draft considers scenarios in which 87 data reduction processing is performed in Block Storage for NFS 88 servers, i.e., compression and deduplication processing occurs in 89 the background or inline as a consequence of NFS files being 90 written to the Block Storage. In these scenarios, the data reduction 91 engines in Block Storage have limited information about how 92 reducible (compressible and/or deduplicate-able) the data written 93 to NFS is. 95 There is additional strong interest to improve data reduction when 96 using NVMe accessed media and exposing such data attributes to the 97 Block Storage as files or directory attributes over NFS is one 98 means of providing this critical information to Block Storage data 99 reduction engines. 101 There is an expired draft for use of NVMe (over fabric) in accessing 102 a pNFS SCSI Layout [3] which could will be extended to communicate 103 data reduction attributes to NVMe storage. The shortcoming of the 104 current pNFS SCSI NVMe layout is that it has no information related 105 to data reduction attributes. This document discusses potential use 106 of NFSv4 named attributes as currently standardized in [2], for 107 communicating additional data reduction metadata; a future version 108 of this document will propose updates to the NFSv4 protocol to 109 support this functionality. 111 The purpose of this draft is to define new name attributes that 112 will allow applications to send richer metadata information to the 113 NFS server in order to optimize Block Storage data reduction engine 114 operations and improve data reduction for data stored by NFS 115 servers. 117 Applications can handle files with different compression and 118 deduplication characteristics and send this information to the data 119 reduction engines. Current applications have defined data reduction 120 characteristics and there are clear definitions for the typical 121 compression and deduplication ratios of some types of data 122 independent of the application that generated the data. For example 123 electronic data analysis (EDA) has no single de facto standard file 124 extension but generates application files with common compression 125 and deduplication characteristics. Knowing that a file is compressed 126 improves the latency and/or throughput of the NFS server by not 127 attempting to further compress the files. An additional example is 128 that NFS backup of files that are already stored on the Block 129 Storage is likely to result in a very high deduplication ratio. 131 1.1 Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [1]. 137 In this document, these words will appear with that interpretation 138 only when in ALL CAPS. Lower case uses of these words are not to be 139 interpreted as carrying RFC-2119 significance. We will refer to the 140 block devices used by the NFS servers as "Block Storage". 142 2. Use Cases 144 Applications can use named attributes to store metadata together 145 with the files and directories. Metadata regarding data reduction 146 attributes may be available from applications that use different 147 types of files. This metadata may not be directly useful to the file 148 system but is relevant to the compression and deduplication engines 149 used by the Block Storage to improve data reduction. Use of data 150 reduction metadata is not expected to significantly impact I/O 151 latency or throughput (IOPS). 153 File Domain | Block Domain 154 | 155 +-------------+ | +-----------------+ 156 | NFS Server |------------|--------->|Reduction Engine | 157 +------+------+ | +--------+--------+ 158 ^ | | 159 | | | 160 | | v 161 +------+------+ | +--------+--------+ 162 | NFS Client | | | Block storage | 163 +------+------+ | +-----------------+ 164 ^ | 165 | | 166 | | 167 +------+------+ | 168 | Application | | 169 +-------------+ | 170 Figure 1: Data Reduction Domains for NFSv4 172 Figure 1 shows the NFSv4 server configuration, data flow and 173 functionality domains with the data reduction engine in the Block 174 domain and located above the Block Storage. This figure represents 175 NFSv4 without parallel NFS (pNFS) support. In this structure the NFS 176 server can communicate named attributes as metadata directly to the 177 Reduction Engine via an extension to the interface to Block Storage. 179 In general applications using block devices rely on SCSI protocols 180 to access the data. Although SCSI protocols have a rich API, most 181 communication between hosts and Block Storage, e.g., storage arrays, 182 is in terms of blocks, not files. In contrast, applications use large 183 files to read and write data to and from NFS servers. In general, 184 NFS servers use NFS file systems that are stored on SCSI (or NVMe) 185 devices provisioned from Block Storage, e.g., external storage 186 arrays, as Block Storage but file metadata, e.g., file type and file 187 size, is not transferred to the block array in a explicit manner. 189 An NFS Server might be able to infer data reduction characteristics 190 based on the file type, e.g., a ".mp4" file can be expected to be an 191 MP4 file that contains MPEG-4 content [7]. This is not sufficient 192 due to file content variability, e.g., as a large variety of codecs 193 are used to create MPEG-4 content whose compressibility may vary by 194 codec. To go beyond the file type, the NFS Server could read the 195 file contents to determine compressibility, but this is problematic 196 due to complexity, e.g., the NFS Server may need to parse a 197 significant amount of an MP4 file to obtain the information 198 necessary to understand its compressibility characteristics. This 199 may be impractical if the file is not written to the NFS Server 200 sequentially, and moreover introduces an undesirable dependency on 201 not only the MP4 file format, but also the set of supported codecs 202 that it supports and individual codec characteristics. It is much 203 better to have the application provide information on 204 compressibility, as the application that generates an MP4 file has 205 the information on the file's contents. A mechanism is needed to 206 pass that information to the NFS Server; this document proposes 207 adding and using new named attributes. 209 So, although the attributes are stored with the files, the current 210 NFSv4 named attributes specifications [4] indicates that named 211 attributes are accessed by the OPENATTR operation, which accesses a 212 hidden directory of attributes associated with a file system object 213 and contains files whose names represent the named attributes and 214 whose data bytes are the value of the attribute. If the NFS 215 server extracts the data reduction named attributes and pass their 216 contents to the Block Storage functionality, the Block Storage 217 reduction engines could parse that content and adapt its data 218 reduction behavior accordingly. 220 File Domain | Block Domain 221 +-------------+ | +------------------+ 222 | |------------------|----->| | 223 | pNFS Server | +-------|----->| Reduction Engine | 224 | | | +----|----->| | 225 +------+------+ | | | +---------+--------+ 226 ^ | | | | 227 | | | | | 228 | | | | v 229 +------+------+ NVMe | | | +--------+--------+ 230 | pNFS Client |----------+ | | | Block storage | 231 | |-------------+ | +-----------------+ 232 +------+------+ SCSI | 233 ^ | 234 | | 235 | | 236 +------+------+ | 237 | Application | | 238 +-------------+ | 239 Figure 2: Data Reduction Domains for pNFS over NVMe or SCSI 241 The filehandle for the named attributes is a directory object 242 accessible by LOOKUP or READDIR and contains files whose names 243 represent the named attributes and whose data bytes are the value 244 of the attribute. The current situation is that data reduction done 245 in the block domain lacks critical information that could be 246 provided by the applications in order to improve efficiency of data 247 compression and deduplication. 249 Figure 2 shows another scenario with a pNFS Server and a block pNFS 250 Client that accesses Block storage using either NVMe or SCSI 251 over a network. In this scenario the pNFS Client could send data 252 reduction attributes directly to the reduction engine above the 253 Block storage layer if the block storage protocol (NVMe or SCSI in 254 the figure) supports doing so. The assumption is that the 255 application has additional information related to files types and 256 typical compression and deduplication parameters associated to 257 different file types, e.g., see the above discussion of MPEG-4 258 content. The application can convey this information to the 259 reduction engine to improve the reduction engine efficiency. If the 260 application does not do so, then the user can also add data 261 reduction characteristics for individual files towards improving 262 data reduction efficiency without needing to change the storage 263 array configuration. 265 For this pNFS scenario the application enables sending 266 data reduction parameters to the Block Device using extensions to 267 the SCSI or NVMe protocols. The pNFS Client still needs to pass the 268 data reduction named attributes to the pNFS Server because the pNFS 269 Client is always allowed to fall back from a pNFS write to an NFS 270 write via the NFS Server; this fallback is similar to the previous 271 case where the NFS Server stores the data reduction named 272 attributes in hidden directories of attributes associated with 273 each file and directory. 275 For example a video application knows whether a file consists of 276 compressed data or uncompressed data. The application writing the 277 data to the pNFS client can set a named attribute that will indicate 278 that a file is uncompressed and hence it is likely to be productive 279 for the data reduction engine to reduce the file's size. The pNFS 280 client passes that information via a hidden named attribute that 281 hints that the file is compressible. The pNFS server will change 282 or add a new data reduction named attribute and will transmit the 283 data bytes, that are the value of the named attribute, to the 284 Block Storage as a hint that the data is uncompressed. The pNFS 285 client will stream the video using the pNFS NVMe data protocol and 286 the compression engine in the Block Storage will compress the data 287 blocks as long as the uncompressed hint is set in NVMe writes from 288 the pNFS Client. If the named attribute data bytes are changed 289 to indicate that the data has been compressed, the compression 290 engine does not compress the incoming blocks. 292 A second example is related to encrypted files that can be neither 293 compressed nor deduplicated in the absence of file copying. For this 294 specific example we envision a not-deduplicatable hint. In this 295 scenario the NFS client sets the deduplication hint to advise to the 296 data reduction engine that deduplication should be enabled for the 297 file. Alternatively if a new file is being written that is not 298 based on modifying an existing file the deduplication hint is set 299 to indicate that deduplication should be disabled. 301 Another use case involves compressed video files and images that 302 are written by video applications. As such files are already 303 compressed, further attempts to compress them are likely to be 304 pointless, and may negatively impact the performance of the NFS 305 Server. 307 An additional scenario involves metadata at the start (header) of 308 the file; an application that did not generate the file may 309 nonetheless be able to access the metadata section in the file and 310 set the named attributes file based on compression and deduplication 311 found in the file header. The NFS server doesn't have visibility 312 into metadata included in file headers and cannot send file header 313 content to the data reduction engine as separate metadata. Only the 314 user application can access and parse the header and add or update 315 the attribute value when the file is written to the NFS server. 317 Additional examples of known data reduction attributes is 318 implemented in benchmarks such as SPECsfs that is using predefined 319 data reduction attributes. SPECsfs workloads [8] have DR/CR 320 (Deduplication Ratio/Compression Ratio) characteristics that were 321 collected from actual user data. They are as follows: 323 EDA DR/CR=50%/50% 324 SWBUILD DR/CR=0/80% 325 VDI DR/CR=55%/70% 326 DB DR/CR=0/50% 327 VDA DR/CR=0/0 328 IT infrastucture DR/CR=30%/50% 329 Oracle DW DR/CR=15%/70% 330 Oracle OLTP DR/CR=0%/65% 331 Exchange 2010 DR/CR=15%/35% 332 Geoseismic DR/CR=3%/40% 334 Another scenario involves placing files with the same known data 335 reduction characteristics in same directory, where the user or an 336 application sets data reduction named attribute in the directory of 337 attributes associated with the directory that are intended to apply 338 to all files in the directory and possibly also sub-directories. 339 In this case the NFS Server uses the data reduction named attributes 340 of the directory to inform the data reduction engine of the data 341 reduction characteristics of blocks in all files in that directory. 343 3 New Named Attributes 345 Named attributes, [4], are a means to associate a hidden directory 346 of attributes with file system objects, e.g., files and 347 directories. Named attributes are especially useful when they 348 add information that is not, or cannot be, present in the 349 associated object itself. User-space applications can arbitrarily 350 create, read from, and write new attributes of a file in that 351 directory. 353 As named attributes are stored in a hidden directory 354 applications do not need to be concerned about how the attributes 355 are stored internally on the underlying file system. All major 356 operating systems provide various flavors of named attributes. 357 Many user space tools allow named attributes to be included in 358 attributes that need to be preserved when files and directories are 359 updated, moved or copied. The filehandle for named attributes is a 360 directory object accessible by LOOKUP or READDIR and contains files 361 whose names represent the named attributes and whose data bytes are 362 the value of the attribute. 364 The proposed data reduction attributes are opaque to the file 365 system but can be used by the data reduction engines in the Block 366 Storage reduction engine to increase the data reduction and server 367 operations by viewing the named attributes as hints from the 368 client application regarding file compression and deduplication 369 characteristics. The Block Storage will parse these attributes and 370 change the data reduction methods according to these hints with no 371 need for the file system to know about the data reduction methods 372 used. 374 Named attributes are intended for data needed by applications 375 rather than by an NFS client implementation. NFS implementors are 376 strongly encouraged to define the new data re4duction attributes as 377 RECOMMENDED attributes. Named attributes have long been considered 378 unsuitable for portability because they are inadequately defined 379 and not formally documented by any standard (such as POSIX). 380 However, evidence suggests that named attributes are widely 381 deployed and their support in modern disk-based file systems is 382 fairly universal. What is different in the new usecase is that the 383 hidden metadata can be retrieved by the NFS server and 384 understood by the data reduction engines of the Block Devices. 385 The data reductiom named attributes can be 0 or 100 where 0 means 386 "don't do this" hint and 100 is a "do this, but can't predict how 387 much reduction will actually result" hint. They can also take on 388 a percentage value, e.g., from the SPECsfs data shown above. 389 Any regular file or directory may have a set of named attributes, 390 consisting of a hidden file whose names represent the named 391 attributes and whose data bytes are the value of the associated 392 attribute value [4]. 394 As currently specified, the NFS client or server SHOULD interpret 395 the contents of the named attribute files. This document proposed 396 to add special named attributes that will be specifically used for 397 data reduction. The data reduction named attributes can be provided 398 by extended attributes supported by most modern file systems and 399 can be retrieved from the local file systems on the client and 400 added to the NFS new named attributes when files are exported from 401 local file system extended attributes of the files to the named 402 attributes in NFS. 404 4 File System Support 406 In Linux, ext3, ext4, JFS, XFS, Btrfs, among other file systems 407 support extended attributes. The getfattr and setfattr utilities can 408 be used to retrieve and set xattrs. The names of the extended 409 attributes must be prefixed by the name of the category and a dot; 410 hence these categories are generally qualified as name spaces. 411 In the NTFS file system, extended attributes are one of several 412 supported "file streams" [5]. 414 Named attributes can be retrieved and set through system calls, [6], 415 or shell commands and generally supported by user-space tools that 416 preserve other file attributes. For example, the "rsync" remote 417 copy program will correctly preserve extended attributes between 418 Linux/ext4 and OSX/hfs by stripping off the Linux-specific "user." 419 prefix. 421 5 Namespaces 423 Operating systems may define multiple "namespaces" in which named 424 attributes can be set. Namespaces are more than organizational 425 classes; the operating system may enforce different data reduction 426 policies and allow different reduction characteristics depending 427 on the namespace. The namespace for these attributes may be 428 accessed by using the OPENATTR operation. The OPENATTR operation 429 returns a filehandle for a virtual "named attribute directory", 430 and further perusal and modification of the namespace may be done 431 using operations that work on more typical directories. 433 6 Data Reduction Named Attributes 435 RFC5661 defines named attributes as opaque byte streams that are 436 associated with a directory or file and referred to by a string name 437 [4]. Named attributes are intended to be used by client applications 438 as a method to associate application-specific data with a regular 439 file or directory. We will use these named attributes directories 440 to add New Data Reduction attributes similar in concept and 441 use to other named attributes, but there are subtle differences. 443 Named attributes are accessed by NFSv4 OPENATTR operation, which 444 accesses a hidden directory of attributes associated with a file 445 system object. Named attributes are accessible to the 446 application layer using GETATTR and OPENATTR and can be modified 447 by users. File systems typically define individual named attributes 448 using named attributes GETATTR and SETATTR operations. Named 449 attributes generally have size limits ranging from a few bytes to 450 several kilobytes; the maximum supported size is not universally 451 defined and is usually restricted by the file system. 453 There are no clear indications on how named attributes are mapped to 454 any existing recommended or optional file attributes defined in RFC 455 5661 [2]; as a result, most NFS client implementations ignore 456 application-specified named attributes. This results in data loss 457 if one copies, over the NFS protocol, a file with data reduction 458 related named attributes from one file system to another that also 459 supports named attributes. Although different data reduction 460 engines achieve different levels of reduction these attributes are 461 used by the reduction engines to increase the reduction to 462 different levels for different algorithms. 464 While it should be possible to write guidance about how a client can 465 use the named attributes mechanism to act as carving out some 466 namespace and specifying locking primitives to enforce 467 atomicity constraints on individual get/set operations, this is 468 problematic for data reduction attributes that are specific to 469 specific applications and file types and not defined by the user. 470 As such there will be mechanisms that will detect the data 471 reduction attributes from the application or from local file 472 system xattrs [6]. 474 The different implementations of the protocol would have to address 475 these attributes based on additional guidance such as reserving 476 some portion of named attribute namespace for xattr-like [6] 477 functionality. 479 7 Protocol Enhancements 481 This section proposes enhancements to the NFSv4 protocol operations 482 to allow data reduction named attributes to be queried and modified 483 by clients. A new attribute is added to bitmap4 data type to allow 484 data reduction named attributes support to be queried. This follows 485 the guidelines specified in [2] with respect to minor versioning. 486 We propose to add 2 bits that will be passed to the reduction 487 engine and used to activate/deactivate the compression and/or the 488 deduplication operations. For example READDIR may be used to get 489 a list of such named attributes, and LOOKUP and OPEN may select a 490 particular attribute. Creation of a new named attribute may be the 491 result of an OPEN specifying file creation. Once an OPEN is done, 492 named attributes may be examined and changed by normal READ and 493 WRITE operations using the filehandles and stateid returned by OPEN. 495 The protocol detailes will be provided in the next version of the 496 draft. It is RECOMMENDED that servers support arbitrary named 497 attributes. A client should not depend on the ability to store any 498 named attributes in the server's file system. 500 8. IANA Considerations 502 All IANA considerations are covered in [4]. 504 9. Security Considerations 506 The additions to the NFS protocol for supporting data reduction 507 named attributes do not alter the security considerations of the 508 NFSv4.1 protocol [4]. Data reduction hints may enable attacks on 509 Block Storage resources that support the NFS Server. Hinting at 510 more data reduction than is possible may cause excessive data 511 reduction processing, and hinting at less data reduction than is 512 possible, including hinting not to perform any data reduction, may 513 result in consumption of more potentially expensive storage 514 capacity. A future version of this draft will discuss what to do 515 about these possible resource attacks. 517 10. References 519 10.1. Normative References 521 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 522 Levels", BCP 14, RFC 2119, March 1997. 524 [2] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network 525 File System (NFS) Version 4 Minor Version 1 External Data 526 Representation Standard (XDR) Description", RFC 5662, January 527 2010. 529 [4] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network 530 File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, 531 January 2010. 533 10.2 Informative References 535 [3] C. Hellwig, "Using the Parallel NFS (pNFS) SCSI Layout 536 with NVMe", June 2017, 537 https://tools.ietf.org/html/draft-hellwig-nfsv4-scsi-layout- 538 ... nvme-00 540 [5] http://www.freedesktop.org/wiki/CommonExtendedAttributes, 541 "Guidelines for extended attributes". 543 [6] M. Naik, M. Eshel, "File System Extended Attributes in NFSv4" 544 https://datatracker.ietf.org/doc/rfc8276/ 546 [7] ISO/IEC 14496-14 "Information technology - Coding of audio- 547 visual objects - Part 14: MP4 file format" 549 [8] SPEC SFS 2014 SP2 User's Guide, 550 http://spec.org/sfs2014/docs/usersguide.pdf 552 Acknowledgments 554 This draft has attempted to capture the latest industry trends of 555 adding data reduction attributes needed to increase efficiency of 556 newest flash NVMe technology for file servers. New protocols were 557 proposed specific for NVMe media and we were inspired by new drafts 558 proposed by the editor of this draft. 560 Author's Address 562 Sorin Faibish 563 Dell EMC 564 228 South Street 565 Hopkinton, MA 01774 566 United States of America 568 Phone: +1 508-249-5745 569 Email: faibish.sorin@dell.com 571 Philip Shilane 572 Dell EMC 573 228 South Street 574 Hopkinton, MA 01774 575 United States of America 577 Phone: +1 908-286-7977 578 Email: philip.shilane@dell.com 580 David Black 581 DellEMC 582 176 South Street 583 Hopkinton, MA 01748 584 United States of America 586 Phone: +1 774-350-9323 587 Email: david.black@dell.com