Subject: Re: [Sigtran] M2PA T7 timer again

From: "TOLGA ASVEREN" <[email-masked]>
Date: Wed, 9 Apr 2003 17:53:37 +0300

Brian,

Tolga,

Tolga Asveren wrote:
(Tue, 08 Apr 2003 13:32:57)
> Brian,
>
> [..snip..]
> > > [TOLGA]What I see from Q.704 12.2.1.2 is until
> > there
> > > is manual intervention, every T17+T2(MTP2), a new
> > link
> > > restoration attempt will be done.
> > > Also, don't we need to monitor the delay on SCTP
> > > association -by adjusting SCTP parameters to
> > proper
> > > values- so that we can know that T17 is greater
> > than
> > > the actuasl loop delay, as indicated in Q.704?
> >
> > See T1.111.4.
> >
> > Q.704 does not measure loop delay, although it is
> > variable in the traditional case as well.
> [TOLGA]But it is variable between very tight bounds
> assured by physicall characteristics of the medium.

Not for satellite.
[TOLGA]I think also for satellite variability is not drasticall and known
in advance.
Based on Q.706 Annex A:
Ds(max) - Ds(min) = 2*r*Dp

where r=6370 km and Dp=0.0033 ms/km.
This gives a difference of 42ms for the maximum loop difference, which is
preknown. So, one can choose a T17 value considering the maximum loop delay
Ds(max).

[..snip..]
> [TOLGA]Let me try. In 4.2.1 we have:
> "M2PA SHOULD follow the criterion of Q.703 [Q.703],
> section 5.3.1 for
> incorrect BSNs: If any two BSNs in three consecutively
> received User
> Data messages are not the same as the previous one or
> any of the FSNs
> of the User Data messages in the M2PA transmit buffer
> at the time they
> are received, then MTP3 SHOULD be informed that the
> link is faulty."
> Now, isn't it possible that after link is dropped and
> put again in service, SCTP messages belonging to the
> old link context arrive and that they have different
> BSN values from each other, which are not the same to
> FSN of any messages in the transmit buffer of the
> receiving M2PA? In such a case, link will be put again
> out of service. IMO, dropping SCTP association when
> link failure is detected, will prevent this.

So what?  The connection is faulty.
[TOLGA]No, the association *was* faulty. IMO, this does not mean that it
*is* still faulty.

With ANSI T1.111.4 the link will be put on suspension for
as long as 5 minutes before another attempt is made to
align the link.

With PR-SCTP the sender of these "stuck" MSUs could
recall them with an FSN.

Stuck packets was a reason to keep the 2 out of 3 rule.
It is not reason to drop the SCTP association.  Quite
the opposite: if the SCTP association were to be dropped,
M2PA could not detect such a "stuck packet" situation
and would assume that a SCTP association of good quality
exists where it indeed does not.
[TOLGA]If those packets have BSN different from each other, will 2 out of 3
rule really help?
If SCTP association is dropped, I don't see how M2PA can consider a
non-existing SCTP association as a healthy one. For 2 out of 3 rule, the
argument was that there is no reason to declare the link faulty for these
stuck packets. But now as far as I understand you advocate the opposite(?).
Those packets belong to the previous link context and already necessary
action is taken because of the anomally in the SCTP association -link is
declared faulty-. Why should we react twice? BTW, T7 might expire also
because of lack of responses from M2PA rather than a serious "stuck packet"
problem. And let's consider that some MSU sent for the old link context
arrives after link is realigned (not because of a fatal problem, for
example just one packet is dropped on its way to the peer and the rest is
waiting for that message to arrive before being delivered to M2PA). If SCTP
association is not dropped, the link will fail again, and where there is no
anomally on SCTP level.
I personally prefer to rely on SCTP mechanisms to detect and deal with SCTP
problems -for "serious stuck packet problems"-, but still IMO dropping
association when T7 expires is a better alternative -for example for the
cases where T7 expires because of lack of response from M2PA-.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran