Subject: [Tsvwg] sctp error check

From: "Lyndon Ong" <[email-masked]>
Date: Thu, 21 Jun 2001 14:56:15 -0700

Folks,

It's a bit worrying that we are not reaching more of a consensus, as time goes on revising the spec will have greater impact.  

The main alternatives are (1) keeping the present checksum and possibly introducing an optional CRC chunk or (2) changing to CRC.

I support Randy's view that there's no advantage to adding a negotiation process to this, compared to adding an optional CRC chunk that can be discarded by implementations not using CRC.

The issue that seems to be holding this up is disagreement on how bad the problem is with the current checksum, some folks with the view that since there is a known flaw in the Adler-32 we should not put this into a new transport protocol and some folks with the view that it hasn't been established whether the flaw has real impact.

Any suggestions on how to get past this?

Lyndon

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 21 Jun 2001 17:47:57 -0500

> Any suggestions on how to get past this?

Can we say that the "burden of proof" is on the side who wants to change
the "status quo" :-)

-Qiaobing

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 21 Jun 2001 16:39:18 -0700

Lyndon,

From my reading of the consensus, CRC has been decided.

Perhaps the next issue becomes how:
A) Modified Common Header and Digest Chunk at the beginning (akin to my
proposal).
B) Same Common Header where the Checksum is Null or reserved if Digest Chunk
is present.
C) Modified Common Header with Digest alone placed at the end of the packet.
D) Same Common Header where the Checksum is replaced with CRC.

The digest chunk and modified common header that I proposed would easily
allow:
1) No checking
2) Simple checking
3) CRC-32

The overhead would entail the added word containing the chunk type, digest
type, and length.  As this chunk would always be placed first within the
packet, its processing could switch based on digest type.  No negotiations.
This initial chunk type could also act as a future means of identifying
differences to make up for a lack of any reserved fields.  This digest list
could be shortened to just:
1) No checking
2) CRC-32

I do not think the amount of the code found in these options would be a
burden to have two included however but would forestall debate as to which
simple scheme to use.

Adding a digest chunk and still keeping a simple checking will burden the
CRC implementation with an extra word of overhead.  Even if the normal
checksum location was nulled if a digest chunk was present at the beginning
of the packet, an additional overhead of two words is added with an
identical amount of checking.  This added overhead could only be justified
if to support legacy.  Perhaps in the event of a digest chunk at the
beginning rather than just nulling the checksum, this could be defined as a
reserved field for future options.

If highly confident in a single error scheme, then placing this check at the
end of the packet has advantages with respect to processing.

Doug

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 21 Jun 2001 17:17:44 -0700 (PDT)

> From my reading of the consensus, CRC has been decided.

While I don't think that we have a consensus, but I believe adding
a Digest chunk is the wrong thing to do.  If you want to have a
better check, use IPsec.  If your app wants to have a special digest
capability, add it to your app protocol.  The transport is the last
place for this.  SCTP is extensible does not mean that it has to be
bloated.  And it should not be the place to add all the things that
any apps want.  This is a no no.

And whatever the integrity checking algorithm the WG picks at last,
this has nothing to do with the Digest chunk.  They should be separated.
And IMHO, adding the Digest chunk is the wrong thing.  People will
then ask for compression chunk, encryption chunk, whatever app useful
chunk...  This WG should very carefully consider a request of adding any 
new chucks, especially at this point of SCTP development.

							K. Poon.
							[email-masked]

---

From: Ian Rytina <[email-masked]>
Date: Fri, 22 Jun 2001 10:32:57 +1000

> Can we say that the "burden of proof" is on the side who wants to change

Absolutely agree. I see from Craig's (11/06) and Jonathon's (12/06)
postings that they are making attempts to do this.

/Ian

---

From: Ian Rytina <[email-masked]>
Date: Fri, 22 Jun 2001 10:41:11 +1000

> >From my reading of the consensus, CRC has been decided.

You must have a different understanding of the meaning of "consensus"
than I have. I thought Lyndon's summary was spot-on.

/Ian

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 21 Jun 2001 17:52:02 -0700

Kacheong,

I am not sure how you have arrived at that conclusion.  A simple problem
with adding checking at the application is that there will never be a
standard method for doing so and hence no standards.  I doubt that CRC will
be allowed as a security digest?  Allowing extensibility is not a bad thing
if such extensions find use by many and not a few.  Already there are those
wishing for no checking as well as those wishing for better. To allow a
standard means of communication together with integrity flexibility, a
digest chunk does this well at the transport.  The alternative is a plethora
of variations of acknowledgement and retry within applications on top of
identical code within the transport.

I did not rule out not using a digest however.  I would assume you would
vote for D when the time comes.

A) Modified Common Header and Digest Chunk at the beginning.

Doug

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 21 Jun 2001 18:11:51 -0700 (PDT)

> standard method for doing so and hence no standards.  I doubt that CRC will

Different apps require different things.  Standardisation for the sack of
standardisation is the wrong thing to do.  How do we know what future
apps want?  As a matter of fact, standardize this at the transport level
is very wrong.  It seems that you are trying to force every apps to adopt
the same scheme...

> be allowed as a security digest?  Allowing extensibility is not a bad thing

Are you saying that we should throw away IPsec?

> identical code within the transport.

So is your design decision based on the fact that apps should be very
simple and everything should be done by the transport?  SCTP is a 
transport protocol, not an architecture...

> D) Same Common Header where the Checksum is replaced with CRC.

Why D?  I still don't see a consensus here in the WG.  BTW, I don't believe
I have seen any mails in the list about coupling the decision of the
integrity check with digest chunk except yours.  Correct me on this if I 
missed some mails.  So the above choices are definitely the choices from
this WG.  No one will vote on them.

							K. Poon.
							[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 21 Jun 2001 19:17:52 -0700

Kacheong,

A reliable transport takes on the responsibility of moving data between
systems.  The transport itself provides the standards for doing so.
Applications do not need to concern themselves with the details of this
transport function if the application can trust the transport to perform.  A
level of integrity is not a wide open issue.  If you think it should be only
one level, fine.  UDP supports two.  Such a single level includes both
option C & D.  If so, then this level should satisfy widely or there is no
standard means of communication beyond an unsatisfactory level of integrity.
Only the transport can provide this level of standardization.
Standardization is not bad and it can be only one level.  If you worry about
future requirements, then it would seem you are arguing for a chunk for such
extensibility but that is not the case.  I am only suggesting that
applications use the transport without duplicating their own layer of check
acknowledgement and retries.  You suggested that if you want integrity, use
IPSec or the like.  These do not support CRC as a digest and add a fair
amount of complexity many would wish to avoid if it is just for integrity.
That does not conclude what should be used for SCTP either.

Error checking is not something foreign to the transport.  Yes, I added
choices that included my proposal.  I also attempted to add a range of
choices that were not.  I was attempting to get the ball rolling as how to
incorporate CRC.  If I missed some methods, please indicate how you would
wish to see it done.  The choice D would be a minimalist approach and
perhaps the most obvious.  If limited to a single solution, I would prefer C
myself.  I tried to give a run down of pros and cons to get people thinking
about the trade-offs.  If you feel you wish to still debate the merits of
various algorithms, that too is your option.  I am not trying to dictate nor
limit the choices.  To make it clear, I changed to the term CRC rather than
Digest.

How would you wish to incorporate CRC?

A) Modified Common Header and CRC Chunk at the beginning.
   (Extensible.)
B) Same Common Header where the Checksum is Null or reserved if
   CRC Chunk is present.
   (Supports legacy with additional word overhead.)
C) Modified Common Header with CRC alone placed at the end
   of the packet.
   (Reduces the number of passes for processing.)
D) Same Common Header where the Checksum is replaced with CRC.
   (Small amount of language changed in the specification.)
E) Continue discussion on algorithms. :(
   (Stalls any decision.)
F)?

Doug

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Jun 2001 11:12:53 -0500

> Can we say that the "burden of proof" is on the side who wants to change

Some would say a mathmatical proof like Jonathan and Craig have offered
is enough.. After all, I CAN prove that if I jump off the top of
the sears tower, the law of gravity will most likely be my demise.
I don't want to test this...

I think the proof is there if you are willing to open your eyes.
So what this comes down to is not a "burden of proof" but instead
what is "proof". Do we need to fall off a cliff before there
is a problem?

Lyndon, what is your preference.. in the last summary did I
have you in the right class?

R

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

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Jun 2001 11:23:19 -0500

> any apps want.  This is a no no.

I agree with you Kacheong :) No way do we have ANY consensus to
add a digest chunk. This can be a seperate draft... I also do
not think we have reached consensus on CRC anything...

R

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Jun 2001 11:25:18 -0500

Doug:

The only one that I can tell has talked about something
other than (D) below is you. I think other things
can be looked at seperately from (D). If you want
to propose a "digest-chunk" draft. Thats cool, lets
just do it seperate from the change of CRC i.e. D...

R

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 22 Jun 2001 10:44:45 -0700

Randall,

What can be done to move this discussion forward if plurality is not enough?
In the past there have been problems with swapped blocks within an ATM
interface that I suspect haunts DSL in some form thwarting a simple
summation.  The shift to ECC from parity also increases the risks of bus
related errors also thwarting simple summation.  Adler-32 for small packets
is the same as simple summation.  CRC for small packets becomes much
stronger however.
I understand a CRC polynomial with greater code separation affords improved
protection for jumbo frames as well.  The general syndrome randomness of CRC
affords protection for most hardware failure especially those exhibiting a
pattern where summations are weak.  For packets randomly changed, the
differences between summation and CRC diminish but those areas where there
may be random disturbance, such as serial links, are also very likely to use
CRC at these links.  This moves the transport into the realm of detecting
mostly hardware related errors.

I am less concerned about errors that happen due to bad code or hardware at
the end points.  Problems at these locations can be dealt with by the client
through certification.  My greater concern is handling problems that are
outside the control of the client.  I would hate to think business
transaction will need to accommodate weak links using non-standard
application level checks, acknowledgments are retries.  This added
complexity will place IP at a disadvantage to those transports that offer
integrity.

I can draw up another draft that moves the CRC field to the end of the
packet rather than within the Common Header.  That may be something that
will find acceptance.  In the meantime, ignore the digest draft.

Doug

> Digest Chunk

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 22 Jun 2001 12:35:18 -0700

Randy,

Maybe I'm being stubborn, but I still like my original alternative (2) of 
using a modified Adler with the optional CRC chunk.  To me that rectifies 
the main concern that people have with the original Adler with a fairly 
minor change, and at the same time it allows applications like iSCSI to add 
a more rigorous error check at the transport layer.

Unfortunately, most people seem to prefer to either not change at all, or 
change completely.

Lyndon

At 11:12 AM 6/22/2001 -0500, Randall Stewart wrote:
>Qiaobing Xie wrote:
> >
> > Lyndon Ong wrote:
> > >
> > > Folks,
> > >
> > > It's a bit worrying that we are not reaching more of a consensus, as 
> time goes on revising the spec will have greater impact.
> > >
> > > The main alternatives are (1) keeping the present checksum and 
> possibly introducing an optional CRC chunk or (2) changing to CRC.
> > >
> > > I support Randy's view that there's no advantage to adding a 
> negotiation process to this, compared to adding an optional CRC chunk 
> that can be discarded by implementations not using CRC.
> > >
> > > The issue that seems to be holding this up is disagreement on how bad 
> the problem is with the current checksum, some folks with the view that 
> since there is a known flaw in the Adler-32 we should not put this into a 
> new transport protocol and some folks with the view that it hasn't been 
> established whether the flaw has real impact.
> > >

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 22 Jun 2001 17:06:24 -0700 (PDT)

> systems.  The transport itself provides the standards for doing so.

No, it is not a standard.  There are more than 1 transport protocol.  Apps
can use TCP, for example, as their transport.  Different transports provide
different things.  That's why we need to have more than 1.

> transport function if the application can trust the transport to perform.  A

The above statement suggests that everything should be put into the
transport.  This is obviously the wrong thing to do.  As this has been
pointed out many times but you still don't want to believe is that if
a "claimed to be reliable" app believes that transport provides all the
reliability, it is not a reliable app.  I don't want to rehash this anymore...

> one level, fine.  UDP supports two.  Such a single level includes both

That's exactly why this has to be done in the app level!  Different apps
want different things.  I think all of us believe this.  It is wrong
to put this in the transport...  There cannot be a standard!

> acknowledgement and retries.  You suggested that if you want integrity, use

No checking is duplicated!  App A won't duplicate app B's effort if they
require different checking methods.  On the other hand, if we put it in the
transport, both app A and app B need to duplicate the effort in the 
transport because they are not satisified with what the tranport provides!
It is exactly the other way around.

> How would you wish to incorporate CRC?

As a lot of people have said, the WG has not yet picked CRC is the integrity
checking algorithm for SCTP.  Why do you keep on insisting that it is
already chosen?

							K. Poon.
							[email-masked]

---

From: Jacob Heitz <[email-masked]>
Date: Fri, 22 Jun 2001 20:19:23 -0700

The impasse remains. zzzzz.

Another idea:

Sacrifice the high bit of the Verification Tag.
If it's 0, then Checksum is Adler32
If it's 1, then Checksum is CRC32

Simple. No extra chunk. No negotiation.
31 bits should be enough for the Verification Tag.

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 23 Jun 2001 07:23:13 -0700

Kacheong,

> can use TCP, for example, as their transport.  Different transports
> provide different things.  That's why we need to have more than 1.

How many similar versions of SCTP should there be?  There is a trade-off
between options and introducing a new protocol as well as similar
considerations in the level of error checking employed.  Some applications
would be fine with unchecked packets, others with one in so many million
packets containing an undetected error, while others expect this undetected
error rate to be a rare event in a life time.  The difference in algorithms
and related processing to obtain the latter turns out to be small to allow
SCTP to server a greater range of applications beyond the original PSTN.

> > transport function if the application can trust the transport
> > to perform.
>

To extend your logic, then no error checking should be placed within the
transport and all error checks should be left to the application.  You would
be outraged if the transport required your application to implement error
checking acknowledgment and retries.  This outrage would be based on the
increased resources required together with the commensurate reduction in
performance due to greatly increased latency.  Added to this, the time to
get this working in the market place will be extended by this error checking
aspect of the transport moved into thousands of applications.  In a
competitive market place, transports that provide the needed level of
integrity will replace those that don't because there will not be a suitable
solution that places error checking into the applications.  Greater
performance and conformity will always be found with integrity provided by
the transport.  No philosophy will change that.

> > level of integrity is not a wide open issue.  If you think it
> > should be only one level, fine.  UDP supports two.
>

Here is an example of the integrity level being an option within the
transport.  If you are arguing against an integrity level option, then
should there be either no error checking or the higher level of error
checking?  Are you saying that TCP or SCTP are not standards used for
communication?  Are you saying there can be no level of error checking
within the transport?  Are you saying that your application has been
satisfied and you are being recalcitrant by arguing against standards?  I do
not understand your statement.

> > If so, then this level should satisfy widely or there
> > is no standard means of communication beyond an
> > unsatisfactory level of integrity.  Only the transport
> > can provide this level of standardization.
> > Standardization is not bad and it can be only one level.
> > If you worry about future requirements, then it would
> > seem you are arguing for a chunk for such extensibility
> > but that is not the case.  I am only suggesting that
> > applications use the transport without duplicating their
> > own layer of check acknowledgement and retries.  You
> > suggested that if you want integrity, use
>
> No checking is duplicated!  App A won't duplicate app B's effort
> if they require different checking methods.  On the other hand,
> if we put it in the transport, both app A and app B need to
> duplicate the effort in the transport because they are not
> satisified with what the tranport provides! It is exactly the
> other way around.

It is fantastic to suggest that error checking in the application is not
duplicating error checking already being done in the transport.  A great
deal of the work done by the transport is related to ensuring data is
retained at the source pending satisfactory reception based on completion of
transport error checks.  There is a small difference in overall processing
between mediocre and excellent error checking in the transport.  An
excellent level will allow applications to not replicate the error checking
done in the transport.  There can be no standard method of error checking
within the application as the market place will demand this checking be done
in the transport for performance and conformity.  In preventing either the
transport integrity option or not employing the higher level of checking,
there will need for yet another transport to satisfy the market place.

> > amount of complexity many would wish to avoid if it is just for
> > integrity. That does not conclude what should be used for SCTP either.
> >
> > choices that were not.  I was attempting to get the ball rolling as how
> > to incorporate CRC.  If I missed some methods, please indicate how
> > you would wish to see it done.  The choice D would be a minimalist
> > approach and perhaps the most obvious.  If limited to a single solution,
> > I would prefer C myself.  I tried to give a run down of pros and cons to
> > get people thinking about the trade-offs.  If you feel you wish to still
> > debate the merits of various algorithms, that too is your option.  I am
> > not trying to dictate nor limit the choices.  To make it clear, I
> > changed to the term CRC rather than Digest.
> >
> As a lot of people have said, the WG has not yet picked CRC is
> the integrity checking algorithm for SCTP.  Why do you keep on
> insisting that it is already chosen?

I am not the one to indicate when CRC has been decided.  I have noted a much
greater level of support for CRC over other types of error checking.  I
wanted to explore a few options open when making this change.  Forgive my
attempts at exploring these additional considerations if premature but it
has been informative based on the few reactions.  Thank you for your input.

Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 23 Jun 2001 07:29:37 -0700

Jacob,

Can you explain what you see as an impasse.  It is not from the lack of
support unless unanimity is a requirement.  I would be happy to see just CRC
used.  If to support legacy Adler-32, then a CRC chunk placed at the
beginning of the packet below the common header would make more sense.

Doug

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Jun 2001 09:08:43 -0500

Lyndon:

A question/Commnet..

> Unfortunately, most people seem to prefer to either not change at all, or

How is selecting (2) NOT a change completely? You are not keeping
Adler-32,
Modified Adler-32 is still a selection of a different sum! It makes
no difference if you pick (2) or (3)... you are still making a
COMPLETE change...

I have NEVER had any problem with an optional CRC chunk. But this is
NOT something for the base spec... I see this more has something for
an extension draft, seperate from anything we do (2) or (3)....

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Jun 2001 09:52:55 -0500

Jacob:

I STRONGLY object to any such thing. If we take this
approach we WEAKEN a KEY defense by removing one bit
of randomness from SCTP. 

This would be a CATASTROPHIC mistake in my mind..

R

---

From: Jacob Heitz <[email-masked]>
Date: Mon, 25 Jun 2001 08:19:02 -0700

How many bits do you REALLY need for the V-Tag and why ?
Why is 32 the right number ? Why not maybe 33 ? or 64 ?
or 24 ?

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Jun 2001 11:03:09 -0500

Jacob:

The V-Tag provides a number of nice things. One most notable
in my mind is the protection against blind attacks. Now if
you weaken this you open yourself more and more to blind
attack.

I can much more ask the same question of the CRC. Why not
put the TCP checksum in, and put the upper 16 bits of
the current field has flags. Then you get:

A) Current EXACT protection that TCP offers by default.
B) Ability to have all the flags you want to turn on
   - trailing checksums
   - checksum chunks
   - alternate checksums

Make the upper bit of the flags turn on a 31-bit CRC :)
or anything your heart desires.. but DO NOT mess with the
V-TAG. You are spreading the proposed problem that Jonathan
and Craig have put forward into other areas of the protocol.
Something I can NOT support...

Has I said.. I am almost now leaning into the why should
we change camp... I understand the mathmatical issue. And
I have no problem with just adopting CRC-32. But if we are
going to open up the whole protocol to change.. Forget it
I drop into the (1) camp.. real fast!

R

---

From: Jacob Heitz <[email-masked]>
Date: Mon, 25 Jun 2001 09:07:34 -0700

So, how many bits do you need ?

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Jun 2001 11:16:39 -0500

Jacob:

I think this issue was answered way back... 32 bits... 
just have a look at RFC2960 :)

Please do NOT try to solve a problem with the CRC by
messing with the other fields...

The one and ONLY concensus that we used to have was
that the existing format and useages remain the same
EXCEPT the CRC field. I can NOT see messing with other
fields... this just spread the chaos around and makes
things worse NOT better.

If you want to sacrifise a bit do it from the CRC field
itself don't mess with the V-Tag or other fields !!

R

---

From: Jacob Heitz <[email-masked]>
Date: Mon, 25 Jun 2001 09:39:59 -0700

I see nothing in RFC2960 that discusses the reason
for 32 bits.

-- 
// Jacob Heitz Tel:510-747-2917 Ext:72917 Home:510-888-9429

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 25 Jun 2001 12:37:07 -0500

> 31 bits should be enough for the Verification Tag.

The problem for this is, you still need to implement both. Otherwise,
you end up either completely unprotected or not interoperable with ~half
of the world.

I think the problem is not "how to support multiple checks". 

-Qiaobing

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 25 Jun 2001 14:07:52 -0700 (PDT)

> SCTP to server a greater range of applications beyond the original PSTN.

There is UDP if an app does not require reliability.  There is TCP
if an app does not require some of the features of SCTP.  No one here
on the list ever mentioned that SCTP was only for sigtran...  I don't
know where you get that idea...

I think your idea has been rehashed many times.  It seems that we have
a fundamental disagreement on the undertanding of how protocold should
be designed.  Having options in a transport protocol causes a lot of
interoperability problems without many benefits.  This is my opinion.
It is apparant that you think the other way.  But I believe many people
on this list whom have actually implemented/maintained a transport
protocol think that your idea is not a good idea.  Well, this is my
opinion.

> the transport.  No philosophy will change that.

I don't understand how you can extend my statement in my previous 
mail in the above way...  The above is definitely not how a transport
protocol should be designed.  There are only a certain set of features
a transport should provide to its user.  Having more does not do any good
except a lot of problems in the real world.  There can never be a complete
set of features that a transport can provide to its user.  It keeps on
evolving.  The best practise is to provide a minimum set so that most of
the requirements can be met.  If an app requires an extra feature, do it
itself.  It is perfectly fine.  Keeping adding features to a transport
will make sure that the transport will never take off as an experiemental
ground.  Is this what you really want?

As I have pointed out many many times and you still do not believe is
that if you call your app reliable and all it does is to rely on the
reliability of the transport, then you are just lying.  You don't need
to rehash your argument.  I think we are just going in circle...

> not understand your statement.

I don't understand your logic about non and all.  There is always something
in the middle.  Your logic is always that algorithm X should be the ultimate
integrity checking method, regardless of any implementation or other
issues.  What I keep on saying is that there cannot be an ultimate checking
method.  And to have multiple methods will create an nightmare that no
one will want to get into.  TCP has been working fine for so many years.
And you are claiming that it does not provide any integrity at all.  I
don't think most people on this list agree with you on this.  And if we
can have a better integrity checking algorithm is SCTP, it is fine.  But
claiming that X must be needed to fit all requirements, it is just a
plain lie.  I think this is what you are trying to suggest to people.
And then you suggest that SCTP should have an option of different algorithm.
I believe what you are trying to creat is a lot of future problems when SCTP
is deployed.  

> there will need for yet another transport to satisfy the market place.

Is it hard to understand that different apps require different things?
Can you prove that all apps require only one method of integrity checking?
If you cannot prove that, please do not repeat the same argument again
and again.  Show us the proof and we can see if your proof is correct
or not.

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 25 Jun 2001 14:10:43 -0700 (PDT)

> 31 bits should be enough for the Verification Tag.

Can people state their rationale behind having more than 1 checkings
in SCTP?  I really think that we should state the problem before
jumping in a solution.  I guess I am very slow, but I still don't see
the problem at all that leads us to decide that we should have more
than 1 algorithms.

							K. Poon.
							[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 25 Jun 2001 17:35:04 -0700

Kacheong,

> > considerations in the level of error checking employed.  Some
> > applications would be fine with unchecked packets, others with one in so
> > many million packets containing an undetected error, while others expect
> > this undetected error rate to be a rare event in a life time.  The
> > difference in algorithms and related processing to obtain the latter
> > turns out to be small to allow SCTP to server a greater range of
> > applications beyond the original PSTN.
>

We are not discussing protocol design but rather a level of integrity that
would meet a broad range of applications to avoid either the transport
options that cause consternation, or multiple transports and thwart
acceptance.  The ideal solution would be to adopt a suitable level of
integrity.  My suggestion of transport options was to appease those that may
object to a small increment in effort required to employ CRC.  In my view,
even if the data does not require this level of integrity, the transport
itself does or expect parsing errors.

> > transport and all error checks should be left to the  application.  You
> > would be outraged if the transport required your application to
> > implement error checking acknowledgment and retries.  This outrage would
> > be based on the increased resources required together with the
> > commensurate reduction in performance due to greatly increased latency.
> > Added to this, the time to get this working in the market place will be
> > extended by this error checking aspect of the transport moved into
> > thousands of applications.  In a competitive market place, transports
> > that provide the needed level of integrity will replace those that don't
> > because there will not be a suitable solution that places error checking
> > into the applications.  Greater performance and conformity will always
be
> > found with integrity provided by the transport.  No philosophy will
> > change that.
>

We are not discussing a new feature but rather the level of integrity the
transport is able to obtain.  This level of integrity would be bestowed upon
applications that make use of the transport.  Unless you wish a significant
level of reengineering, applications depend on this level of integrity.
There have been defensive measures taken in some cases to detect those
errors not detected by TCP as when using FTP as example.  These measures are
not standardized and are sporadically applied.  Your only point is you do
not think that the transport should make the effort to ensure anything but a
mediocre level of integrity.  If the application did require better, then
expect everyone writing applications to get into the business of designing
transports to incorporate their own error check acknowledgments and retries.
Is that anyway to design a transport?  I say no.

> > satisfied and you are being recalcitrant by arguing against
> > standards?  I do not understand your statement.
>
> I don't understand your logic about non and all.  There is always
> something in the middle.  Your logic is always that algorithm X
> should be the ultimate integrity checking method, regardless of
> any implementation or other issues.  What I keep on saying is that
> there cannot be an ultimate checking method.  And to have multiple
> methods will create an nightmare that no one will want to get into.
> TCP has been working fine for so many years. And you are claiming
> that it does not provide any integrity at all.  I don't think most
> people on this list agree with you on this.  And if we can have a
> better integrity checking algorithm is SCTP, it is fine.  But
> And then you suggest that SCTP should have an option of different
> algorithm. I believe what you are trying to creat is a lot of future
> problems when SCTP is deployed.

You are repeating your opinion that a low grade error check should be okay.
At the time TCP was created, the ability to do much better was limited.
Today's processors are capable of a higher level of sophistication and have
greatly outpaced memory.  I personally find corrupt files on a regular basis
using my home DSL.  In some respects, this is water under the bridge for
TCP.  As the data rates increase, the need to rely even more heavily on the
error checking will increase nor would I conclude that TCP is the gold
standard for error checking.  To suggest that an error is the fault of the
application and not lax checking is disingenuous with the difficulty imposed
by moving this responsibility into the application.  Only in the extreme
cases should this be required.

> > retained at the source pending satisfactory reception based on
> > completion of transport error checks.  There is a small difference in
> > overall processing between mediocre and excellent error checking in the
> > transport.  An excellent level will allow applications to not replicate
> > the error checking done in the transport.  There can be no standard
> > method of error checking within the application as the market place will
> > demand this checking be done in the transport for performance and
> > conformity.  In preventing either the transport integrity option or not
> > employing the higher level of  checking, there will need for yet another
> > transport to satisfy the market place.
>

Is it hard to understand that it is not practical to set standards where the
application is made responsible for the integrity of transport?  If you
understand that point, it becomes important to then provide integrity within
the transport suitable  for these applications.  Thinking that the transport
can be lax in checking does not help in that much of the hardware is out of
the control of the client where errors may occur within ulterior equipment.

> Can you prove that all apps require only one method of integrity checking?

Those much better at this than I have concluded that a particular CRC-32
polynomial provides an adequate level of protection suitable for storage.
There are papers describing their reasoning on this subject if you are
interested.  At this level of integrity, you would be pressed to find
applications that require better.  I am sure you can think of rare
exceptions that may require additional checks.  Today, storage is fully
handled successfully in hardware so it can be done at a low CPU overhead.  I
am confident that hardware and software can be certified to provide a level
of assurance that would indeed allow the transport to bear this
responsibility.  It is done today for storage, so why should IP be
different?

> and again.  Show us the proof and we can see if your proof is correct

I have demonstrated the weakness of simple summations.  Beyond technical
papers presented on this subject supporting CRC and test cases pointing to
weakness with alternatives, what more do you wish?  Can you prove that other
solutions are better?

Doug