Michael Kafka
2018-07-19 10:36:53 UTC
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)
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)