Chronological Thread 

< Chronological >      < Thread >

---

Dear all,
see my comments below.
Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 5 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From: Luca Papotti
> [SMTP:Luca.Papotti AT italtel.it]
> Sent: Tuesday, July 10, 2001 11:37 AM
> To:
> discussion AT sctp.de
> Subject: Re: [SCTP-Discussion] About the SCTP checksum
>
> Hi all,
> i agree with the idea of an ULP digest, but this do not resolves the
> problem (if it is a real problem) of unnecessary chunk(s) retransmission
> at trasport level.
[Tuexen Michael] Well, you can disable bundling, if you want.
> A potential alternative solution is an Adler-32 checksum covering all
> control informations including
>
> 1. SCTP header
> 2. all chunk headers
> 3. All control chunks (SACK ...)
>
> and a distinct checksum 4 every DATA CHUNK.
[Tuexen Michael] Well this seems not appropiate for me, but...
> This sol. has the advantage to remove the probability of unnecessary
> chunks retransmission, at the same computational cost of the overall chksm.
> Obviously with the overhead of a checksum field (4 byte) in every DATA
> header.
> What do You think ??
[Tuexen Michael] Hmm. I think this mailing list is for discussing
the implemenation available at www.sctp.de
The discussion you want should be held on the tsvwg mailing list. See
http://www.ietf.org/html.charters/tsvwg-charter.html
[Tuexen Michael] for general discussion of SCTP modifications.
>
>
>
> P.S. I'm not suggesting to modify the RFC 2960, it's only 4 discussion
> purpos ;)
[Tuexen Michael] Well, so what should be the result of such a
discussion?

> Tuexen Michael ha scritto:
>
> > Dear all,
> >
> > the SCTP checksum provides packet integrity, not DATA chunk integrity.
> > Therefore the SCTP header is included in the checksum calculation.
> > Something you won't have with only checksumming DATA chunks. And what
> > about control chunks?
> >
> > So I think you need a fast checksum (or CRC) for the whole packet. If this
> > is not enough for user data, the ULP can use a digest to provide higher
> > integrity. This has not to be recalculated in case of retransmission.
> > See for example
> > http://www.ietf.org/internet-drafts/draft-tuexen-tsvwg-tls-over-sctp-00.txt
> > Best regards
> > Michael
> >
> > Michael Tuexen Tel.: +49 89 722 47210
> > Siemens AG Fax: +49 89 722 48212
> > ICN WN CS SE 5 E-mail:
> > Michael.Tuexen AT icn.siemens.de
> >
> > > -----Original Message-----
> > > From: Luca Papotti
> > > [SMTP:Luca.Papotti AT italtel.it]
> > > Sent: Monday, July 09, 2001 5:50 PM
> > > To:
> > > discussion AT sctp.de
> > > Subject: [SCTP-Discussion] About the SCTP checksum
> > >
> > > Hi all,
> > > I have a question about the SCTP checksum.
> > > The RFC defines a single checksum covering the entire packet.
> > > This could lead to inefficient behaviour in the case of data
> > > corruption, 'cause an error in a single DATA CHUNK results in the
> > > retransmission
> > > of all other DATA CHUNKS eventually boundled in the same packet.
> > > This, combined whit the need to re-compute the Adler-32 checksum 4 the
> > > entire
> > > packet,
> > > is an overhead, I think.
> > > Do You know the reason of this choice, or what I missunderstand ??
> > > Thank's.
> > >
> > >
> > > _______________________________________________
> > > discussion mailing list
> > > discussion AT sctp.de
> > > http://www.sctp.de/mailman/listinfo/discussion
> > _______________________________________________
> > discussion mailing list
> > discussion AT sctp.de
> > http://www.sctp.de/mailman/listinfo/discussion
>
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

---

• RE: [SCTP-Discussion] About the SCTP checksum, Tuexen Michael, 07/10/2001
  • Re: [SCTP-Discussion] About the SCTP checksum, Luca Papotti, 07/10/2001
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] About the SCTP checksum, Tuexen Michael, 07/10/2001

---

Archive powered by MHonArc 2.6.19+.