Subject: RE: [Tsvwg] sctp error check

From: Tuexen Michael <[email-masked]>
Date: Mon, 25 Jun 2001 09:05:25 +0200

Dear all,

this describes my feeling...

As I do not see the usage of a per packet change you can use
the INIT/INIT-ACK for setting the checksum algorithm. You could
use a parameter in the INIT/INIT-ACK and can require that this
parameter is the first one. This would mean that you know where
this information is without scanning the whole packet. Please note
that I'm NOT suggesting negotiation here.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Jacob Heitz [SMTP:[email-masked]]
> Sent:	Monday, June 25, 2001 9:00 AM
> To:	Tuexen Michael
> Cc:	[email-masked]
> Subject:	Re: [Tsvwg] sctp error check
> 
> This is what I was afraid of. It's degenerating into a
> heap of good ideas again. Just think, soon we will steal
> 16 bits off the VT for options. Oooh, maybe some for
> header compression, surely SCTP could use some of that.
> Aaaaargh!!!
> 
> Tuexen Michael wrote:
> > 
> > Dear all,
> > 
> > when you say 'stealing away' do you mean:
> > 
> > 1. The highest order two bits describe the checksum for the packet
> > 2. The other 30 bits are the verification tag
> > 
> > This would imply that you could change the checksum algorithm on
> > a per packet base. Is this really needed?
> > 
> > The other possibility is
> > 
> > 1. The highest order two bits describe the checksum for the packet
> > 2. All 32 bits are the verification tag
> > 
> > This would imply that you have to use the same checksum algorithm
> > for all packets of an association.
> > 
> > Thanks for clarification.
> > 
> > Best regards
> > Michael
> > 
> > Michael Tuexen    Tel.:   +49 89 722 47210
> > Siemens AG        Fax:    +49 89 722 48212
> > ICN WN CS SE 5    E-mail: [email-masked]
> > 
> > > -----Original Message-----
> > > From: Douglas Otis [SMTP:[email-masked]]
> > > Sent: Sunday, June 24, 2001 9:49 PM
> > > To:   Jacob Heitz; [email-masked]
> > > Cc:   [email-masked]
> > > Subject:      RE: [Tsvwg] sctp error check
> > >
> > > 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
> > >
> > > > > > 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 :-)
> > > >
> > > > It is an exclamation of annoyance, like "damn it".
> > > > I meant it in a light hearted way. The dictionary translation looks
> > > > quite offensive. Sorry.
> > >
> > >
> > > _______________________________________________>
> > > tsvwg mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Jun 2001 10:06:53 -0500

I think I will go find the draft Chip and I wrote
on this... 

This whole thing sickens me... I would much prefer
such a negotiation method then weakening the whole
SCTP V-Tag. 

I am even more strongly leaning into Ian's camp...

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)