Subject: Re: [lisp] Suggested UDP checksum text

From: [email-masked] (Noel Chiappa)
Date: Tue, 1 Sep 2009 10:57:49 -0400 (EDT)

> From: Sam Hartman <[email-masked]>

    > I think we need to at least say that for LISP data plane packets, an
    > ITR MAY send a 0 checksum.

We may want to upgrade that to a "SHOULD"; my reasoning for this is a
cost-benefit analysis. Furthermore, depending on how we word the rest of the
statement (i.e. covering reception processing), it may actually be very
desirable to suppress generation of checksums.

One has to start with the recognition that this non-end-end checksum buys us
very little, simply because it's non-end-end. (In fact, if we have
applications which have an actual use for damaged packets, it will have a
_negative_ impact, as it will cause such packets to be discarded.) Since it
buys us little/no benefit, if it has any cost at all, it's going to fail a
cost-benefit analysis.

This alone would have pushed me toward tossing the checksum altogether (i.e.
MUST), but I understand that there are some boxes on which that would present
real difficulties, so I can see that that is not a feasible choice.

As to the costs, one cannot fully work out them out unless one knows exactly
what the ETRs will be doing (and will be mandated to do), but here are some
points.

On an ETR which is doing checksums in software, _iff_ it checksums all
non-zero-checkum UDP packets, that overhead will slow down packet processing,
and reduce potential throughput. Whether this is significant is in the eye of
the beholder, I suspect.

More seriously, potentially, we've also been informed that there are boxes on
which it is expensive (or even impossible), to calculate checksums - e.g.
because the box doesn't normally have access to the entire packet. I would
_assume_ that this holds true for _checking_ checksums too. Were we to
mandate (or even just 'SHOULD' checking checksums), that could prove
problematic for those boxes - and moreso if a high percentage of the packets
they receive have checksums set.

    > receivers SHOULD verify checksums 

Same analysis, basically.

A non end-end checksum buys one very little, it anything at all - especially
since link-level-checksums _already_ filter out most damaged packets. So I
fail entirely to see that the benefits of checking them are worth the costs
involved in so doing.

Sure, if it's difficult to _suppress_ on any particular box, let it check
them. But IMO we shouldn't encourage useless (i.e. wasted) processing in the
spec.

	Noel

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Sep 2009 12:08:01 -0400

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    >> From: Sam Hartman <[email-masked]> I think we need to at
    >> least say that for LISP data plane packets, an ITR MAY send a 0
    >> checksum.

    Noel> We may want to upgrade that to a "SHOULD"; my reasoning for
    Noel> this is a cost-benefit analysis. Furthermore, depending on
    Noel> how we word the rest of the statement (i.e. covering
    Noel> reception processing), it may actually be very desirable to
    Noel> suppress generation of checksums.

    Noel> One has to start with the recognition that this non-end-end
    Noel> checksum buys us very little, simply because it's
    Noel> non-end-end. (In fact, if we have applications which have an
    Noel> actual use for damaged packets, it will have a _negative_
    Noel> impact, as it will cause such packets to be discarded.)

I think that if I thought about it  enough I'd find the above compelling
and end up at:

* senders SHOULD NOT send a checksum
* Receivers SHOULD check a checksum if present

I'd be using your reasoning on the send side.  My reasoning on the
receive side is that changing the UDP handling seems problematic to me
and unjustified especially if we are recommending that senders not
send checksums.

However, if we can all live with MAY/MAY, I think we'll be mostly done
with this issue, so while I'm happy to continue circling if people
really want to,  we could just declare victory on MAY/MAY.

The SHOULD NOT/SHOULD comment is my personal opinion.  However I
believe we're close to consensus on MAY/MAY as a chair.  Also, as a
chair, I'm not seeing any new information added to this discussion at
this point.