Hi,
could you share some data on how much of a performance impact we're
talking about here? I was under the (maybe naive) impression that
checksum offloading was practically ubiquitous these days.
One of the problems with IPv6 is that is so similar to IPv4 but
different enough to cause pain for implementations. So since we can
use 0 UDP checksums for IPv4 in UDP in IPv4, we would want to build
(or use existing hardware) that does IPv6-or-IPv4 in UDP in IPv6.
if the existing hardware sends UDP packets over IPv6 with checksum
zero, it is not compliant to the RFCs. If you're building new
hardware, you will have to sacrifice some gates to do a UDP checksum
calculation. Alternatively, you could pick a different encapsulation
or change the IETF consensus on using UDP in IPv6.
Existing hardware has no case of encapsulating in UDP-IPv6. So this is
a new *feature*.
I already told the list the cost of "sacrificing some gates". It's a
non-starter. We cannot pick another encapsulation for the reasons I
said before, LAGs.
Let's do this the right way. We have to make IPv6 stuff *easier* to
implement rather than creating more barriers to entry.
Sorry, but we want to build practical products. If you don't build
practical standards, vendors will violate them.
Let me be blunt: If you are going to ignore IETF consensus, why are
you here?
I am not ignoring IETF consensus. I am trying to convince you, and
would urge the IETF to be practical. This is not a big issue, should
have been resolved but has been argued since Vancouver IETF.
If you want to change that consensus, please convince the IETF to do
so. Ignoring the consensus and the process by which we arrive at it
is not an option.
Why do you think we are ignoring the consensus. Marhsall Eubanks (and
the MBONED working group) has been trying to close this issue for AMT
for around 2 years now. I have been helping him with it. We are being
proactive.
So I am not sure why you have this defensive tone.
There are no practical reasons to use outer header UDP checksums
regardless of the 4 combinations of packet types (v4-in-v4, v6-in-
v6,
v6-in-v4, or v4-or-v6) being forwarded by LISP routers.
I hear you, but is there any quantifiable downside to just compute
the checksums, esp. if it can be done in hardware?
A hardware forwarding engine is not going to compute a pseudo-header
checksum and compute every byte of a packet. It's just not going to
happen.
I freely admit I'm not a hardware guy, but a hardware checksum was
cheaply doable at (then) high-performance in 1995. See RFC1936.
Header checksums have been in hardware for decades. That is not what
we are talking about here. When you require a forwarder to do an
entire packet checksum which must be added into a pseudo header
checksum of some fields which are not in contiguous memory, it
requires more RTL, additional buffer and memory usage and a lot of
time to add in every byte (that increases forwarding latency which
users do not like). Entire packet checksums has *never* be done in any
shipping router product.
IP header checksums, adds up 20 bytes which are contiguous and at a
fixed location in a packet. Modifying checksums are easy too. But to
ask a router to checksum every byte of a packet while encapsulating
(when the checksum is not placed in a trailer) requires a lot of
unnecessary complex logic when the packet is already protected at each
link hop with CRCs.
There has never been a requirement to do this before. My guess is you
can slow performance by 20%.
There hasn't been a requirement for IPv4 because there is an IP
header checksum. As to the performance numbers, my guess would be
different, which is why I asked if you had data.
We have really good CRCs on data links today. Requiring a UDP checksum
in an encapsulating header is chasing a problem that doesn't exist.
Dino
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
