Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-04.txt

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 3 Apr 2002 04:05:23 -0600

Jonathan,

Why do you want to restrict me from calculating the checksum
in a mathematically-equivalent fashion?  (I have no outboard
accelerators.)

--brian

On Sat, 30 Mar 2002, Jonathan Stone wrote:

> 
> Here's an excerpt, slightly edited from an off-list email.
> Apologies to those who (like Brian) have seen it twice.
> 
> 
> My concern here is that for high-end SCTP implementations
> (gigabit, 10gigabit, and upward), outboard accelerators will be
> commonplace. Outboard accelerators make the check less end-to-end.
> The available data suggests that errors -- e.g., bits flipped in
> address registers in DMA engines, due to transient hardware errors --
> is a signficant source of errors.  They really *do* happen in the
> field, and at worrisome rates: on the order of 1 in 10,000 overall,
> and *much* higher for specific broken hosts.
> 
> Specification of the CRC computation should consider the issue of
> failure in outboard hardware acceleration of what is supposed to be an
> end-to-end error check.[*]  My take is that such consideration falls
> squarely under the "potential for causing harm" clause of RFC2119,
> section 6, not under the interoperability clause.
> 
> 
> I think that explicitly granting complete and utter freedom is a very
> poor engineering choice. I much prefer the current wording.  The most
> ``weaking'' of that tight specification I'd live with is two clauses:
> 
>         1. a MUST compute "AS IF" (i.e., must be mathematically
>            equivalent to) the current text
> 
>         2. a SHOULD NOT compute in some other mathematically-equivalent
>            way, since the mathematically-equivalent alternatives raised
>            in discussion are weaker when (for example) faced with errors
>            in outboard accelerators.
> 
> The argument I've seen presented against the MUST in the current
> draft, seems implicitly assumes that all computation is being done
> inside the end-host -- that is, using the end-host CPU and end-host
> buffers. That may be a valid assumption from the perspective of a
> pure-software implementation and implementor. But making that
> assumption misses the point behind the words, which is aimed at
> implementations where the ``end-to-end'' check is being done outboard.
> (If you like, consider Michael Tuexen's source code again, with the
> assumption that the address-manipulation is being done in outboard
> hardware, where the address arithmetic may  occasionally mess up.)
> 
> 
> I don't find applications like pretty-printing packet traces a
> convincing case. The pretty-printer can easily save the relevant 32
> bits before the CRC-check, and then restore them afterward.  It's not
> like packet pretty-printing is an actual protocol implementation :).

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg