headers
Brian F. G. Bidulock | 3 Apr 2002 08:45
Favicon

Re: delayed SACK when sender is retransmitting

Venkat,

On Mon, 01 Apr 2002, venkat venkatsubra wrote:

> Dear All,
> 
> When a receiver receives a retransmitted DATA chunk that advances
> the cumulative TSN Ack number, isn't it good to send the SACK
> immediately
> instead of delaying it ? Otherwise what we see is the sender when
> retransmitting stalling waiting for this SACK before it can proceed
> further.

Why is your retransmitting sender stalling waiting to
receive a SACK?  Normally RTO.Min >> max SACK delay,
so a retransmit means that either a packet was lost
or the SACK was lost.

I don't understand what problem you are seeing...

--brian

> Since the rfc (2960) requires you to SACK immediately on receiving
> the first DATA chunk, a similar rule could help in case of receiving
> retransmitted DATA chunks i.e. on receiving a DATA chunk that fills a
> hole and advances the cumulative TSN Ack.  Or,  is this left to the
> implementation ?
> Thanks!
> 
> Venkat
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian F. G. Bidulock | 3 Apr 2002 12:05
Favicon

Re: I-D ACTION:draft-ietf-tsvwg-sctpcsum-04.txt

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.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian F. G. Bidulock | 3 Apr 2002 12:11
Favicon

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

Randall,

Please see comments below...

On Mon, 01 Apr 2002, Randall Stewart wrote:

> Hmm..
> 
> Since this did not go to the working group in my reply-all
> and my second forward also failed (I think due to anti-spamming)
> I will retry.... forwarding to my home email first :>
> 
> More comments on the wonderful sctpcsum issue :>
> 
> R
> 
> 
> Randall Stewart at work wrote:
> > 
> > I have just looked over the whole thread... and I see both points
> > of view on this matter... I must agree Jonathan's arguments are (as
> > usual)
> > quite persuasive.
> > 
> > Now another thought I had ...  Where did this wording come from?
> > 
> > So I went back to RFC2960 and what do I find?
> > 
> > "
> >    When an SCTP packet is received, the receiver MUST first check the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Randall Stewart | 3 Apr 2002 14:56
Picon
Picon

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

"Brian F. G. Bidulock" wrote:
> > Randall Stewart at work wrote:
> > > "
> > >     After the packet is constructed (containing the SCTP common header and
> > >     one or more control or DATA chunks), the transmitter MUST do the
> > >     following:
> > >
> > >     1) Fill in the proper Verification Tag in the SCTP common header and
> > >        initialize the Checksum field to 0's.
> 
> Do you see the problem with this text????  Why does 1) say to fill in
> the proper verification tag and initialize the checksum to 0 when the
> paragraph aboves says that the packet already contains an SCTP common
> header??  What was in the SCTP common header to begin with?  Random bits?
> 

Well lets see if we do NOT have a MUST here I could fill it with
anything I like 32, 64 or maybe 5,260  and still be completely compliant
with the wording. And yes even randon bits would be ok in the common
header if the MUST was not specified...

> > >
> > >     2) Calculate the CRC-32c of the whole packet, including the SCTP common
> > >        header and all the chunks.
> > >
> > >     3) Put the resultant value into the Checksum field in the common header,
> > >        and leave the rest of the bits unchanged.
> > >
> > >     When an SCTP packet is received, the receiver MUST perform the checksum
> > >     algorithm. It SHOULD perform this algorithm using the following procedure:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ivan.Arias-Rodriguez | 3 Apr 2002 15:57
Picon

RE: I-D ACTION:draft-ietf-tsvwg-sctpcsum-04.txt]

	Hi all!

	Please, see some comments below...

> > As Johnathan has not substantiate any of his statements 
> regarding the
> > exact procedure after several requests for explanation, I 
> propose that
> > you strike the following sentence and go with the modified 
> text above.
> > 
> 
> Well, so far I have not seen an overwhelming consensus for
> change... I will leave this to Scott and Allision to judge. I have
> submitted an -05 version with typo's fixed but this left the same
> i.e. not the above text that you commented on but the original.
> 
> I just don't see it as a problem Phil as convinced me 
> off-line that with
> a bit of sideways looking at it even the original wording will allow
> Michaels code...

	Why don't simply leaving things as they are and adding some note or something stating, for example: "Any
other way of calculating the CRC that always leads to exactly the same result as the procedure stated above
is also valid"?

	In my opinion, Brian made a good point. Especially when you are sending datagrams, you always know that
those datagrams going to a specific association will always have the same port numbers, verification
tag, and initial value of CRC (all 0s), i.e., same common header. Because of that, you can always skip the
calculation of the CRC for the common header bytes since it will always lead to the same value (the only
(Continue reading)

Permalink | Reply | 9 comments |
headers
Douglas Otis | 3 Apr 2002 20:36

RE: I-D ACTION:draft-ietf-tsvwg-sctpcsum-04.txt]

Ivan,

The draft makes no statement about the packet being in contagious memory nor
that the calculation be done simultaneously across the entire packet.  It
provides only the sequence of the calculation.  Once you take that
perspective, then Michael Tuexen and Brian Bidulock's schemes can be done
without altering procedures described within this draft.

Doug

On April 3, 2002 5:57 AM Ivan Arias-Rodriguez
(Ivan.Arias-Rodriguez <at> nokia.com) wrote:
>
> 	Hi all!
>
> 	Please, see some comments below...
>
> > > As Johnathan has not substantiate any of his statements
> > regarding the
> > > exact procedure after several requests for explanation, I
> > propose that
> > > you strike the following sentence and go with the modified
> > text above.
> > >
> >
> > Well, so far I have not seen an overwhelming consensus for
> > change... I will leave this to Scott and Allision to judge. I have
> > submitted an -05 version with typo's fixed but this left the same
> > i.e. not the above text that you commented on but the original.
> >
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jacob Heitz | 3 Apr 2002 20:47
Picon
Favicon

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

Douglas Otis wrote:
> The draft makes no statement about the packet being in contagious memory
                                                         ^^^^^^^^^^
Does this mean it has a virus ? :-)
Permalink | Reply | 1 comment |
headers
Douglas Otis | 3 Apr 2002 20:58

RE: I-D ACTION:draft-ietf-tsvwg-sctpcsum-04.txt]

Jacob,

Opps, contiguous memory.

>
> Douglas Otis wrote:
> > The draft makes no statement about the packet being in contagious memory
>                                                          ^^^^^^^^^^
> Does this mean it has a virus ? :-)
Permalink | Reply | 0 comments |
headers
Brian F. G. Bidulock | 3 Apr 2002 21:07
Favicon

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

Douglas,

Then why the objection to mathematically equivalent procedures?  If
the draft clearly stated your interpretation: that the MUST applies to
the "calculation" and not the "method," there would not be a problem.

On the contrary, others have expressed that this interpretation is
not true.  Which is it?  Can we clarify the text (perhaps with a note)
so that one interpretation can be taken.

--brian

On Wed, 03 Apr 2002, Douglas Otis wrote:

> Ivan,
> 
> The draft makes no statement about the packet being in contagious memory nor
> that the calculation be done simultaneously across the entire packet.  It
> provides only the sequence of the calculation.  Once you take that
> perspective, then Michael Tuexen and Brian Bidulock's schemes can be done
> without altering procedures described within this draft.
> 
> Doug
> 
> On April 3, 2002 5:57 AM Ivan Arias-Rodriguez
> (Ivan.Arias-Rodriguez <at> nokia.com) wrote:
> >
> > 	Hi all!
> >
> > 	Please, see some comments below...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Douglas Otis | 3 Apr 2002 21:30

RE: I-D ACTION:draft-ietf-tsvwg-sctpcsum-04.txt]

Brian,

Is it within the draft or Jonathan's statements you are objecting to?

The draft already indicates optional methods to calculate the CRC as
explanation with regard to initialization, as example.

The draft also indicates that the code is informative.  This leaves an
abstract calculation to be derived and implemented in whatever fashion
desired.  The draft also indicates there are many ways this can be done.
Beyond inventing a new algorithm, what is excluded by the draft?

Doug

On April 3, 2002 11:08 AM Brian F. G. Bidulock (bidulock <at> openss7.org) wrote:
> Douglas,
>
> Then why the objection to mathematically equivalent procedures?  If
> the draft clearly stated your interpretation: that the MUST applies to
> the "calculation" and not the "method," there would not be a problem.
>
> On the contrary, others have expressed that this interpretation is
> not true.  Which is it?  Can we clarify the text (perhaps with a note)
> so that one interpretation can be taken.
>
> --brian
>
>
> On Wed, 03 Apr 2002, Douglas Otis wrote:
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane