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

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 4 Oct 2002 16:01:44 -0600

Tolga,

On Fri, 04 Oct 2002, Tolga Asveren wrote:
> > 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?
>

But M2PA cannot require this of all SCTP implementations and thus
it needs its own T7 timer.

Then there is HEARTBEAT ACKs.  Whenever a HEARTBEAT ACK is received
the peg counts a cleared.  This means that if a TSN is retransmitted
and then a HEARTBEAT ACK is received and the TSN is retransmitted
and then a HEARTBEAT ACK is received...   This can possibly go on
forever.

There is in RFC 2960 the concept of "lifetimes" but that is just a
transmit/retransmit queue lifetime.

M2PA has a ULP-level ack and the pertinent parameter for M2PA is
the amount of time for the M2PA peer to acknowledge a message must
not exceed a threshold (of about 0.5 - 2.0 seconds).  It is not
beyond M2PA to run a timer (T7) to ensure that no message acknowledgement
exceeds this threshold.

When message acknowledgement does exceed this threshold, M2PA does
not want to abort the association.  In fact, M2PA wants to send
link status out of service to the peer and initiate changeover
procedures using another M2PA link.

--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

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 04 Oct 2002 17:04:00 -0500

Tolga Asveren wrote:
....
> > Tolga,
> >
> > Suppose we've had added the finer degree error reporting to SCTP as you

My point is that no matter what we do in SCTP layer for error reporting,
there will always be scenarios where neither the SCTP sender nor
receiver will have a clue to why the data is being dropped.

> same message and based on that it can drop an association without violating

I think it is a good suggestion, too.

-Qiaobing