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

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

Randall, 

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 4:37 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Tsvwg] Fast Retransmit on continuos CRC failure
> 
> 
> 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?
[TOLGA] Yes.
> 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 ??
[TOLGA] Not every CRC has error. Just receiver hardware has problem with a
specific CRC. So, whenever the problem message is retransmitted -which by
chance has that specifi CRC value-, it is silently dropped, and sender again
tries to fast-retransmit it, after 4 SACKs with gap..
> 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.
[TOLGA] I think that might be a solution for that situation. So, one could
-if she/he wishes-  drop the association after certain number of
fast-retransmits for the same message.
> 
> R
> 
> 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
> > 
> > 
> 
> 
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 4 Oct 2002 18:22:37 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 6:02 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Tolga,
> On Fri, 04 Oct 2002, Tolga Asveren wrote:
> > > 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.
> 
> But M2PA cannot require this of all SCTP implementations and thus
> it needs its own T7 timer.
[TOLGA] Yes, that might be a problem. It could be nice, if somehow this was
addressed in a SCTP document.
> 
> 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.
[TOLGA] One can turn-off heartbeats or can use a big interval for them.
> 
> 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.
[TOLGA] T7 is currently not used as you described. Currently T7 is not a per
message timer for M2PA. But I think, this part of discussion belongs to
SIGTRAN WG.
> 
> 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 ¦
>

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 4 Oct 2002 18:32:56 -0400

Dave,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 5:32 PM
> To: Tolga Asveren
> Cc: [email-masked]'; [email-masked]
> Subject: RE: [Tsvwg] Fast Retransmit on continuos CRC failure
> 
> 
> 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>
[TOLGA] I missed that one, you are right.
> If this is implemented, it *might* be that T3 will time out 
> max.retransmission times and take down the association in 
> your example 
> scenario.
[TOLGA] I would think this to happen as a low possibility.
> 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!
[TOLGA] My idea was not counting CRC errors for a specific message, but any
CRC error. And decreasing it based on a rule, which requires some carefull
thinking. (or notifying CRC errors to SCTP user and implementing CRC error
handling logic -when to drop an association and when not- there)
> 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,
> 
> > From: Qiaobing Xie [mailto:[email-masked]]
> > Sent: Friday, October 04, 2002 4:38 PM
> > To: Tolga Asveren
> > Cc: [email-masked]
> > 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
> 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:
> > > 
> > > -----------------
> > TSN.T3-rtx
> > message, giving
> > > an indication to SCTP user after CRC errors, forcing bundling for

---

From: [email-masked]
Date: Fri, 4 Oct 2002 18:25:31 -0400

Tolga,
I agree, this should be on SIGTRAN, but let me just say that even though 
T7 isn't per message, this type of error blocks the entire stream from 
reaching the peer M2PA, even though they make it to the peer SCTP's 
receiver wait queue.  Any T7 implementation should catch this...
DaveS.

 10/04/2002 06:22 PM

Brian,

> it needs its own T7 timer.
[TOLGA] Yes, that might be a problem. It could be nice, if somehow this 
was
addressed in a SCTP document.
> beyond M2PA to run a timer (T7) to ensure that no message 
[TOLGA] T7 is currently not used as you described. Currently T7 is not a 
per
message timer for M2PA. But I think, this part of discussion belongs to
SIGTRAN WG.

---

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

> Sent: Friday, October 04, 2002 7:48 PM
> To: Tolga Asveren
> Cc: [email-masked]
> ....
> > [TOLGA] This is not a problem specific to M2PA, this 
> problem would be there
> > for any SCTP user. 
> 
> .. and would be there for any transport protocol. Essentially we are
> talking about running a transport protocol over a partially impaired
> media pipe.
[TOLGA]Whether a procedure to deal with this problem is necessary for SCTP
or not is certainly a different issue but if there is a protocol, which is
SCTP+drop the association after certain CRC error rule, wouldn't it be
qualified to be called a transport protocol? But I agree with your initial
comment, that it is possbile to invent cases, which are not handled by a
transport protocol; my point is just that this problem seems addressable by
SCTP.
> 
> -Qiaobing
> 
> > And again as a side info, T7 as it is used now in M2PA
> > (which is not a per message timer) can catch it.
>

---

From: [email-masked]
Date: Sun, 6 Oct 2002 11:14:10 -0400

Randall,
I apologize.  I should have gone back and looked at your original
suggestion instead of commenting on an interpretation of it!
As far as the original problem, it seems that we have a legal way for an
implementation to protected against the strange case of having a particular
chunk which never makes it through the network while, other chunks make it
through just fine.  However, as Brian has pointed out, it is unwise for an
SCTP user to count on this behavior.
DaveS.

                      Randall Stewart                                                                                                         
                      <[email-masked]        To:       [email-masked]                                                         
                      cago.il.us>                 cc:       Tolga Asveren <[email-masked]>, "[email-masked]'" <[email-masked]>,       
                                                   [email-masked]                                                                       
                       10/05/02 09:24 AM          Subject:  Re: [Tsvwg] Fast Retransmit on continuos CRC failure                              

[email-masked] wrote:
> Tolga,
> Per the implementors guide (2.8, Issues with Fast Retransmit), you only
fast retransmit a chunk once
> max.retransmission times and take down the association in your example
> scenario.

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

> 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

> 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

> [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
> implementation can count CRC errors or number of fast-retransmits for the
>>>association after certain number of CRC errors, dropping association