Subject: RE: [Sigtran] M2PA V6: T7

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

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 2:59 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> Tolga,
> 
> Tolga Asveren wrote:                              (Fri, 04 
> Oct 2002 13:36:25)
> > > 
> > >   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.
> > [TOLGA]I believe your this comment is more related with 
> SCTP rather than
> > with M2PA. The same might happen also for MTP2 case, but 
> there I expect the
> > procedures in Q.703 10.2 to mark the link as failed after 
> some time. So, the
> > solution is not provided by having T7 per message for MTP2, 
> but by another
> > procedure. 
> 
> This cannot happen in the MTP2 case.  T7 expires.  In MTP2 delay
> cannot grow without bound.  This has already been demonstrated.
> 
> > Furthermore for this scenario, I think T7 timer -as it is 
> now, not per
> > message- is good enough for M2PA case.
> 
> No it is not good enough, for reasons already stated on this thread
> (actually in response to the question which started this thread off).
> T7 on other than a per-message basis grows excessively for 
> M2PA whereas
> it does not for MTP2.
> 
> > Because the unlucky 231 won't be
> > received by peer SCTP successfully, no messages with TSN > 
> 231 will be sent
> > to peer SCTP-user , i.e. to peer M2PA, so T7 either on M2PA 
> which sent 231
> > or on the other M2PA will expire and link will fail. 
> 
> But not quickly enough when on other than a per-message 
> basis, as already
> discussed on this thread.
[TOLGA] As I said previously, this corner-case problem is better to be
addressed by SCTP (forcing bundling, trying the other interface while
fast-retransmitting, dropping association after a number of CRC failures,
dropping association after certain fast-retransmit retires for the same
message etc...)
Furthermore, even currently the situation is still not very different than
from MTP2 case. One still needs to wait for the worst case T7+propogation
delay, regardles whether MTP2 or M2PA is used.  
> --brian
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 4 Oct 2002 14:13:50 -0600

Tolga,

Tolga Asveren wrote:                          (Fri, 04 Oct 2002 16:00:35)
> > basis, as already discussed on this thread.

It will be a cold day in June before SCTP addresses this.  I tried for over
a year to get bounded delay into SCTP.  But you are welcome to try on TSVWG.
Until then, M2PA needs T7.

One more thing you will need to change about SCTP is that it must not be
allowed to clear peg counts when a HEARTBEAT ACK is received.  Good luck
at that too.  (Otherwise HEARTBEAT ACKs can indefinitely pospone dropping
the association due to propagation delays on a single message).

The mechanism of SCTP allows a stream to become blocked (even indefinitely)
while allowing other streams to proceed.  The purpose of SCTP was to
address the stringent delay requirements of signalling protocols.  Well, it
doesn't really do that.  Fortunately M2PA has acks and can determine
end-to-end delays itself.  Thus T7.  SCTP cannot even provide M2PA with
ULP acks and flow control, did you think that it was going to somehow monitor
ULP ack delay?

> delay, regardles whether MTP2 or M2PA is used.  

For MTP2: T7 >> PD is always true
For M2PA: T7 << PD is possible and expected

This makes the M2PA case *very* different from the MTP2 case.  
This is why M2PA needs per-message while MTP2 gets away with per-ack.

--brian