When we configure a copyoffload/xcopy migration, if a fully fledged xcopy command, where storage CPU clones the data, fails the process reverts to copyoffload (or xcopy) fall-back method. Where the same vmkfstool clone command is used but xcopy isn't support, the esxi CPU will clone the source disk (vmdk) into the target (RDM) this while slower than xcopy native still happens without network and is faster than vddk.  

Technically the esxi CP command if we're talking about iscsi then the block is R/W over the "iscsi network" which is still a network but not in the sense of vvdk/http method were the esxi CPU reads disk blocks sends the data over network to OCP worker to write the blocks.  In the case of FC well fallback again uses esxi CPU does the disk block R/W copy over "FC network" which like "iscsi network" is segregated/faster that the regular "network". Hence both copyoffload (no FC/iSCSI network used at all) and copyoffload-fallback (FC/ISCSI storage networks used to clone) are faster than VVDK/Method which handles the clone R/W across lets call it the generic "network".

Mentioning the fallback method is critical and I think it's missing from the doc.