Re: [Rtg-dt-encap-considerations] draft-rtg-dt-encap-02 for review

[Tom Herbert <[e-mail]>]

On Wed, May 20, 2015 at 3:34 PM, Larry Kreeger (kreeger)
<[e-mail]> wrote:
> Hi Tom,
>
> Why do you see it as a problem for a device that can't support UDP
> checksum checking to ignore the non-zero checksum rather than requiring
> the sender to explicitly set the checksum to zero.  The biggest problem I
> see with requiring dropping of non-zero checksum is when multicast is
> being used in the underlay because packets may be delivered to tunnel
> endpoints where some can check the checksum and some cannot.  It also
> means that every encapsulator must know the capability of the receiver.
>
Hi Larry,

Here are some points:

1) The requirements around UDP checksum are more than twenty years
old. The fact that UDP non-zero UDP checksums are validated is an
invariant in deployed networks. There is no easy way to distinguish
VXLAN from other UDP traffic in order to carve out exceptions.
2) We still see checksum errors in large networks so it is not true
that they have been obsoleted by Ethernet CRC.
3) If a transmitter sets a non-zero UDP checksum it does so with the
full expectation that the receiver will check it. So if the receiver
ignores the checksum:
  a) it misses errors that are hopefully caught somewhere else.
  b) may make debugging network issues more difficult since we lost
one level of verification.
  c) the transmitter wasted resources/power in computing the checksum.
  d) disregards the fact that the transmitter might have knowledge
that the path could be lossy and hence checksums are warranted.
4) In my network, I would much prefer that devices drop packets that
they can't verify, rather than allow packets through that are
potentially suspect. For instance, it is much easier to debug when a
device is consistently dropping packets because of misconfiguration
(i.e. sending non-zero checksums to a device that can't handle them)
rather than trying to tracked down some intermittent corruption of end
user data.

Tom

>  - Larry
>
> On 5/20/15 3:28 PM, "Tom Herbert" <[e-mail]> wrote:
>
>>>> Would change "Avoid full packet checksums in encapsulation if
>>>> possible" to "Avoid full packet checksums in cases where necessary
>>>> devices cannot support them"
>>>
>>> I don't know what others think, but that seems to be confusing. It
>>>seems to
>>> imply that some devices are sub-standard and can be fixed, when in fact
>>>it
>>> is impossible to do a full packet checksum, where the checksum is
>>>placed in
>>> the header, in a low-latency cut-through device.
>>>
>>Note this only applies to devices terminating encapsulation, not to
>>other middleboxes or switches in the underlay path. Also, w.r.t. UDP
>>encapsulation we already have several protocols that provide the
>>answer: UDP checksums on TX are optional for IPv4 and optional for
>>IPv6 only under the requirements of RFC6935 and RFC6936. This allows
>>for hardware that does not support UDP checksum to be deployed, but
>>hopefully with awareness by an administrator as to the tradeoffs of
>>disabling checksums. There are no provisions to ignore checksums on
>>receive, so if a device does not support UDP checksums sees a non-zero
>>checksum it should drop the packet (IMO VXLAN allowing RX checksums to
>>be ignored is not correct).
>>
>>_______________________________________________
>>Rtg-dt-encap-considerations mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations
>