Subject: RE: [Tsvwg] sctp error check

From: [email-masked]
Date: Sat, 23 Jun 2001 21:18:29 +0300

> I did say to use high bit of VT, not high bit of checksum,
> didn't I ?

	Ooops! You are right, I just read what I wanted... :-/ So we agree
100% then, I really like your idea :-)

> >         We could even use more than one bit, so more 
> checksums can be
> > chosen, for example two bits and so we could include 
> Adler-32, modified
> 
> I was hoping nobody would say that. Bugger.

	The Spanish translation of "bugger" that I read in my dictionary is
quite "interesting", I imagine you didn't wanted to say the first meaning
that appears there... :-> I wonder how didn't I manage to learn that word
before :-)

	I don't really think we need more than two options, (modified)
Adler-32 or CRC-32, that's enough.

	BR Iván Arias Rodríguez

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

---

From: Jacob Heitz <[email-masked]>
Date: Sat, 23 Jun 2001 11:36:49 -0700

> that appears there... :-> I wonder how didn't I manage to learn that word

It is an exclamation of annoyance, like "damn it".
I meant it in a light hearted way. The dictionary translation looks
quite offensive. Sorry.

---

From: "Douglas Otis" <[email-masked]>
Date: Sun, 24 Jun 2001 12:49:10 -0700

Jacob,

Although stealing a few bits away from the verification tag is not as
extensible as a chunk with respect allowing a variation in length, but two
bits encoded would provide four options.  These four options might encode
as:

0) No Error Check
1) Simple Error Check
2) CRC Error Check
3) Reserved

Although this offers options that appear as an anathema, doing so with a
leading chunk of a known type also allows preservation of prior code and
opens the entire checksum field for future options.  That would be double
bugger for those left to defend this standard.  The few option flags used
and the few remaining in TCP have been seen as a means of innovation for
those wishing change and frustration for those keeping their finger in the
dyke.  Perhaps to reduce the number of bits and to improve processing of the
packet, when a special chunk is included, the lower bits of the now unused
checksum could then indicate the overall length of the packet.  This would
improve the integrity of error checking in that it would preclude undetected
truncation.

If a system was composed of 128 128-Mbit memory chips for total of 2GB of
memory or 16 chips per side on 4 sticks.  If this system were used as a
router or firewall, it is possible that staging overwrites the MAC, IP
header and ports in a damaged packet or, if not, this error becomes limited
to a population of 1 out of a thousand the clients.  It would then be
possible for parsing to detect a damaged packet that would hopefully be done
prior to acknowledgement where perhaps 25% of those damaged remains
undetected if in the less dynamic upper bits.  If one of these chips had a
weak driver causing half of either ones or zeros to be incorrectly asserted
perhaps depending on the data pattern and once up to temperature, a
Fletcher-16 error check as example could miss 1% of these errors.  Such a
system would still provided good performance but introduce an undetected
error once every 50,000 packets if using these simple error checks for these
unfortunate clients.

There would be few indications that there was even a problem as most packets
would be fine.  The link error rate could be negligible and the software and
other related system hardware could be perfect.  Injected format errors will
make the transport less robust as parsing is likely beyond acknowledgement.

Doug

---

From: Jacob Heitz <[email-masked]>
Date: Sun, 24 Jun 2001 13:15:36 -0700

The reason I was hoping nobody would suggest more bits
was simply that it would drag the discussion on and
I see no need for more bits. I really have no other
objection to using two bits.

What I see as the impasse is that there are those that
walk in the lands of Randall's cliffs and others that
walk the city streets where the largest cliff is a kerb
and do not want to carry the parachute.

These two peoples will never agree. If one or two bits
in the VT will settle it, then that's great.

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 25 Jun 2001 13:09:51 -0500

Jacob,

As a matter of fact, I don't even see this as an impasse. 

Rather, this is just a common case of "no enough consensus and/or
justification to change a status quo." Until that consensus or
justification of change can be formed (in 2 months, or 2 decades)
nothing is broken and nothing will need to be fixed.

-Qiaobing