Subject: [Tsvwg] Fast Retransmit on continuos CRC failure

From: Tolga Asveren <[email-masked]>
Date: Fri, 4 Oct 2002 16:10:46 -0400

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

---

From: Randall Stewart <[email-masked]>
Date: Fri, 04 Oct 2002 15:36:37 -0500

Tolga:

My 2cents..

1) One can always turn on Nagle to get bundling to occur.. if it is
    desired
2) It sounds like from your description your hardware has been frapped,
    is this what you mean?
3) It seems outside the odds of which a transport protocol can protect
    you from... after all this is a hardware issue.. if I read you right
    and more to the point every CRC has some number of errors that
    CAN slip by... What are the odds of this thing happening ??
4) One can always abort an association if one so desires. There is
    nothing said in RFC2960 preventing an implementation from putting
    an utter retransmission ceiling on chunks and if it exceeds that
    ceiling.. dump the association.

R

Tolga Asveren wrote:
> 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
> 
> 

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

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

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 04 Oct 2002 15:37:35 -0500

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?

-Qiaobing

Tolga Asveren wrote:
>   report for TSN 231 and performs a fast-retransmit on the TSN.T3-rtx
> after certain number of fast-retransmits for the same message, giving
> an indication to SCTP user after CRC errors, forcing bundling for