Maybe I have missed something:
4.3 Describes briefly LSO/LRO for GENEVE. The mechanism might lead to invalid LRO operation if a tenant system sends two consecutive IP packets of the same flow which would result in LSO at the sending NVE and the receiving NVE tries to apply LRO: (I assume from the draft, that the NVE prepares a large GENEVE packet and the physical NIC of the NVE performs LSO to send smaller GENEVE packets to the underlying network which will be recombined through LRO at the receiving NVE, avoiding IP fragmentation) The resulting LSOed GENEVE packets would have the same outer IP and UDP header and the same GENEVE header (it will be replicated according to the draft) for both encapsulated packets sent by the tenant. The receiving NVE has no way to distinguish one very large encapsulated packet which was LSOed from two somewhat smaller encapsulated packets sent by the tenant. For a successful LSO/LRO operation an unambiguous mechanism is needed to distinguish LSOed packets from each other. A mechanism similar to the IP fragmentation/reassembly could be a solution, e.g. through a GENEVE option. This option could include a unique value comparable to the Identification in IPv4 or the IPv6 Fragmentation Header and a "More" Flag. I could not identify any draft in the nvo3 WG addressing a mechanism of GENEVE which could be compared to fragmentation on layer 3 or segmentation on layer 4. BTW the described mechanism requires strict in-sequence transport of the underlying network, which can be safely assumed in a modern data center but is not mentioned in the draft. (I'm using "to LSO" as a verb and "LSOed" as an adjective to distinguish it from fragmentation at layer 3 or segmentation resp. TSO at layer 4) Minor stuff, rather cosmetic: 1.2 Terminology defines LSO as "Large Segmentation Offload", I suggest to use "Large Send Offload" which is commonly used e.g. in Linux-Lingo, Microsoft Documentation and many other places. It would also be consistent with LRO. 4.1.1 Mentions TCP MSS clamping as an example, I can't see a way how something similar can be used in the context of GENEVE. Can this sentence be removed or an option similar to MSS be defined? The draft uses the term "data plane", I suggest "forwarding plane" to be consistent with RFC 3654, "Requirements for Separation of IP Control and Forwarding" (I know, "data plane" is a long tradition in Cisco-speak and other places and it's also used quite often in IETF documents, I just like "forwarding plane", maybe because it's new and shiny, and it's from the IETF) Best regards, Michael "MiKa" Kafka (long time lurker, this is my first submission) _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
