Subject: RE: [Tsvwg] Fast Retransmit on continuos CRC failure

From: [email-masked]
Date: Fri, 4 Oct 2002 17:32:19 -0400

Tolga,
Per the implementors guide (2.8, Issues with Fast Retransmit), you only fast retransmit a chunk once
<snip>...Mark the DATA chunk(s) as being fast retransmitted and thus 
ineligible for a subsequent fast retransmit...<snip>
If this is implemented, it *might* be that T3 will time out 
max.retransmission times and take down the association in your example 
scenario.
But, if all other packets can get through but something about that one 
individual can NEVER get through, we are back to your same problem.  But 
Randall's solution doesn't work because you only get one fast RTX.  Maybe 
counting all RTXs would work?
Also, note that the other half of the solution has another problem - you 
can't really count "crc errors for the same message", since the receiver 
has no idea which message was in error, and the sender has no idea that a 
crc error was detected!
DaveS.

Tolga Asveren <[email-masked]>
Sent by: [email-masked]
 10/04/2002 04:51 PM

        To:     "[email-masked]'" <[email-masked]>
        cc: 
        Subject:        RE: [Tsvwg] Fast Retransmit on continuos CRC failure

Qiaobing,

> -----Original Message-----
> From: Qiaobing Xie [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 4:38 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Tsvwg] Fast Retransmit on continuos CRC failure
> 
> 
> Tolga,
> 
> Suppose we've had added the finer degree error reporting to 
> SCTP as you
> suggest below. What if the next cosmic ray hits the link layer (e.g.
> ethernet frame) CRC hardware on the NIC at the receiver?
[TOLGA] In fact mines was more a queestion than a suggestion, but I would
think the case you describe would be a question/problem for the relevant
link layer protocol, not for SCTP itself.
I think solution suggested by Randall is good enough for me, my SCTP
implementation can count CRC errors or number of fast-retransmits for the
same message and based on that it can drop an association without 
violating
the protocol.
> 
> -Qiaobing
> 
> Tolga Asveren wrote:
> > 
> > During some discussions on SIGTRAN WG, the following scenario is
> > presented:
> > 
> > -----------------
> >   A cosmic ray hits the receiver's hardware CRC-32 and 
> burns a junction.
> >   The CRC calculation at the receive now discards every 
> packet with a
> >   CRC of 0x0000ffff.  TSN 231 with a single DATA CHUNK has 
> the fateful CRC.
> >   When TSN 231 is first transmitted, the sender see 4 SACKs 
> with a gap
> > 
> >   report for TSN 231 and performs a fast-retransmit on the 
> TSN.T3-rtx
> >   has not expired, so Path.Max.Retrans is not pegged (neither is
> >   Assoc.Max.Retrans): see Section 8.2 RFC 2960.  As long as 
> TSN 231 is
> > 
> >   sent without bundling, it will have the same fateful CRC. 
>  This can
> >   continue ad infinitum.  No setting of RTO.Max, 
> Path.Max.Retrans and
> >   Assoc.Max.Retrans can allow SCTP to guarantee that a 
> packet will not
> > 
> >   be delayed beyond any given bound.
> > --------------------
> > 
> > Is it possible to address this problem within SCTP (droppoing
> > association after certain number of CRC errors, dropping association
> > after certain number of fast-retransmits for the same 
> message, giving
> > an indication to SCTP user after CRC errors, forcing bundling for
> > fast-retransmitted messages, forcing to use different destination
> > address while fast-retransmitting etc...)or is this in fact not a
> > problem from SCTP point of view?
> > 
> >    Tolga
> 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: Randall Stewart <[email-masked]>
Date: Sat, 05 Oct 2002 08:24:23 -0500

> max.retransmission times and take down the association in your example 

That was NOT my suggestion.. aka fast-retransmits... I was speaking
of just plain retransmits...

In fact I do KNOW of an implementation that does just this. There is
an upper bounds on the number of times ANY data packet can be
retransmitted for ANY reason (fx-rxt or time-out). When that limit
is reached the WHOLE association is torn down.

This is perfectly legal and it has nothing to do with how you
retransmit OR types of errors... i.e. CRC's etc..

R

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 5 Oct 2002 16:02:27 -0600

Randall,

> retransmit OR types of errors... i.e. CRC's etc..

Sure, legal; but not expected.  I would not be a good thing for
M2PA to require that all SCTP implementations do this to work
correctly.  Particularly when it easily has at its disposal the
ability to time acknowledgements itself.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg