Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Fri, 4 Oct 2002 13:36:25 -0400

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 11:01 AM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> Tolga,
> 
>   RTO.Max = 150 ms.
>   Path.MaxRetrans = 2
>   Assoc.MaxRetrans = 4
> 
>   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. 
Furthermore for this scenario, I think T7 timer -as it is now, not per
message- is good enough for M2PA case. 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. 
> 
>   Q.E.D.
> 
>   Therefore, M2PA needs to use T7 to guarantee same.
> 
> --brian
> 
> Tolga Asveren wrote:                                          
>                        (Fri, 04 Oct 2002 10:37:32)
> > Brian,
> > 
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Friday, October 04, 2002 10:31 AM
> > > To: [email-masked]'
> > > Subject: RE: [Sigtran] M2PA V6: T7
> > > 
> > > 
> > > Brian,
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Friday, October 04, 2002 9:29 AM
> > > > To: Tolga Asveren
> > > > Cc: [email-masked]'
> > > > Subject: Re: [Sigtran] M2PA V6: T7
> > > > 
> > > > 
> > > > Tolga,
> > > > 
> > > > RTO.min does nothing to limit the maximum amount of 
> time that SCTP
> > > > will wait for an acknowledgement.  I think you mean RTO.max.
> > > [TOLGA] Yes, you are rigth, for the calculation of the 
> > > maximum time, one has
> > > to consider RTO.max.
> > > > 
> > > > Regardless, what values of RTO.min, RTO.max, Path.MaxRetrans and
> > > > Association.MaxRetrans do you propose be used to effect the same
> > > > as T7 of, say, 1 second?
> > [TOLGA]Just to clarify, I wouldn't consider those values to 
> be used to have
> > the same affect like T7 in MTP2, but to ensure that 
> propogation delay is
> > below some value, IMO T7 is not used to monitor propogation 
> delay for MTP2
> > case.
> > > [TOLGA] I would say  RTO.min = {A value, which is not too 
> low for the
> > > underlying IP network} RTO.max = 150ms
> > > Path.MaxRetrans = 2   Association.MAxRetrans = 4   
> > > (multihoming with two IP
> > > addresses)
> > > > 
> > > > (Bear in mind that a successful SCTP HEARTBEAT clears the peg
> > > > counters and increases the delay without bound.)
> > > > 
> > > > --brian
> > > > 
> > > > Tolga Asveren wrote:                            (Fri, 04 Oct 
> > > > 2002 08:37:20)
> > > > > > 
> > > > > > So how do you propose to do this with SCTP?
> > > > > [TOLGA] With RTO.min, Path.MaxRetrans and 
> > > > Association.MaxRetrans. IMO, layer
> > > > > n+1 sets some requirements on layer n, but does not monitor 
> > > > it. It is every
> > > > > layers own responsibility, to guarantee that it meets its 
> > > > requirements.
> > > > > > 
> > > > 
> > > > -- 
> > > > Brian F. G. Bidulock
> > > > [email-masked]
> > > > http://www.openss7.org/
> > > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> 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 12:58:56 -0600

Tolga,

Tolga Asveren wrote:                              (Fri, 04 Oct 2002 13:36:25)
> solution is not provided by having T7 per message for MTP2, but by another

This cannot happen in the MTP2 case.  T7 expires.  In MTP2 delay
cannot grow without bound.  This has already been demonstrated.

> 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

But not quickly enough when on other than a per-message basis, as already
discussed on this thread.

--brian