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

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

Dave,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 6:26 PM
> To: Tolga Asveren
> Cc: [email-masked]'; [email-masked]
> Subject: RE: [Tsvwg] Fast Retransmit on continuos CRC failure
> 
> 
> 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.
[TOLGA] This is not a problem specific to M2PA, this problem would be there
for any SCTP user. And again as a side info, T7 as it is used now in M2PA
(which is not a per message timer) can catch it.
> 
> 
> 
> 
> 
> 
> Tolga Asveren <[email-masked]>
> Sent by: [email-masked]
>  10/04/2002 06:22 PM
> 
>  
>         To:     "[email-masked]'" <[email-masked]>
>         cc: 
>         Subject:        RE: [Tsvwg] Fast Retransmit on 
> continuos CRC failure
> 
> 
> Brian,
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Friday, October 04, 2002 6:02 PM
> > To: Tolga Asveren
> > Cc: [email-masked]'
> > Subject: Re: [Tsvwg] Fast Retransmit on continuos CRC failure
> > 
> > 
> > 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 ¦
> > 
> _______________________________________________
> 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: Qiaobing Xie <[email-masked]>
Date: Fri, 04 Oct 2002 18:47:53 -0500

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

-Qiaobing

> And again as a side info, T7 as it is used now in M2PA

---

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 07 Oct 2002 09:43:36 +0100

The original "problem" statement was:

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

What are you trying to say?

This seems like an implementation bug to me. If so what do you expect
to happen when this occurs:

1) A performance hit - so it would be nice to have some statistics that
warn there is some sort of problem - then it's a matter of fixing the
broken component, not a protocol design issue.

2) A robustness issue - does the system become messed up and deliver invalid
data, hang unconditionally, or increasingly transmit more packets? - if it's
none of these then the protocol design in OK?

So.... I worry you may be suggesting to embellish the protocol to deal 
with a potentially rare fault...

Gorry Fairhurst 

> talking about running a transport protocol over a partially impaired

Yes, so the key point is the "pipe" needs to be fixed, not the transport protocol.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Oct 2002 03:10:11 -0600

Gorry,

The point of the original example was that SCTP does not guarantee
that a packet will not be delayed beyond any given bound.  Therefore
if the ULP cares about the timeliness of application level acknowledgement,
it should run its own timers.

I believe that Tolga's argument was that SCTP should be "fixed" so that
no application need run such timers.

--brian

---

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 07 Oct 2002 10:30:17 +0100

OK...  

The Internet offers no guarentees of timeley delivery
(examples of when a packet may cease to be delivered 
at all, or is held up by various subnetwork effects, include:

- could use link ARQ and retransmit any number of times,
- an end host / router moves in a mobile case with no/poor connectivity,
- an end host or router discards a packet, e.g. due to overload/congestion).

Agree it seems like the transport protocol needs to handle 
late/no delivery.

Gorry

P.S. I did not like the previous example below, as a part of this argument.

"Brian F. G. Bidulock" wrote:
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Oct 2002 04:02:42 -0600

Gorry,

> Agree it seems like the transport protocol needs to handle 

Did you mean application protocol?  Neither TCP nor SCTP has a
requirement to inform the user of late delivery beyond a bound.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Mon, 07 Oct 2002 11:30:40 -0500

> Agree it seems like the transport protocol needs to handle 

Hmm.. maybe what this application could consider using (once it gets
finished.. which I think it is about there) is PR-SCTP. One could
use the time protocol defined in the draft... then when the
"maximum time to send" expires on say the faulty data chunk.. the
application can use this as the key to say.. something is wrong
a data chunk was not delivered within N seconds.. kill the assocation.

This would yeild a little bit of flexibility as well.. one could
need X occurances of this if one wanted...

That may well make it so an application timer is not needed.. instead
just use the pr-sctp non-delivery event as the timer expiration...

R

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Oct 2002 12:05:00 -0600

Randall,

> just use the pr-sctp non-delivery event as the timer expiration...

Yes, I had considered PR-SCTP.  It seems well suited to M2PA: however,
M2PA would need some additional things from MTP2 at the receiver to
handle the loss of guaranteed in-sequence delivery.

--brian