Subject: Re: [Sigtran] (M2PA) Please standardize M2PA protocol timer identifiers

From: [email-masked]
Date: Mon, 13 May 2002 13:50:19 -0400

Hello Brian,

Q.703, 9.3:
"The receiving end of a signalling link which detected a congestion
situation,
periodically returns a link status signal unit containing a status
indication 'B'
to the remote transmitting end of the link at interval T5 (see 12.3)."

I am calling a periodic timer a 'rate' timer. Perhaps there is better
terminology
for this. An alternative is 'interval' timer, but even single-pop timers
measure
an interval.

As far as T12 of Q.704 goes.... My understanding is that these are all
L3 timers, not L2 timers. Q.704 T12 is the 'Waiting for Unihibit
Acknowledgement'
Timer. Which is applicable to MTP3 and not to M2PA.  Is there some other
'T12'
in Q.704 to which you are referring?

And since we're talking about Q.704 timers, how about...
T10 Waiting to Repeat Signalling Route Set Test Message (rate timer)
T15 Waiting to Start Route Set Congestion Test (rate timer)

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]> on 05/13/2002 12:04:50 PM

Please respond to [email-masked]

To:   [email-masked]
cc:   [email-masked]
Subject:  Re: [Sigtran] (M2PA) Please standardize M2PA protocol timer
      identifiers

Jeffrey,

Take a look at Q.704.  It defines additional timers on a per-link basis
such as T12 which would conflict with your implementation-depedent timer
labels.

Also, where is there an implementation-dependent timer which is not simply
a rate?  Rates are not timers (there are not started and stopped under
protocol control).

--brian

[email-masked] wrote:                    (Mon, 13 May 2002
08:42:40)
>
> Hello Brian,
>
> We're in general agreement, though there are a couple of details
remaining.
> Your initial comment about Q.703 prompted me to go refresh my memory
> using the latest version of that recommendation.
>
> When I refer to protocol "timers", what I really mean is protocol timeout
> values,
> and not necessarily a particular implementation in enforcing those
> timeouts.
> This jives with Q.703, which in 7.3 reads "Timers defined in this
> Recommendation
> are absolute time values".
>
> The "timers" presented in Q.703 are:
> T1 -- Alignment Ready Timer (this appears to match the current M2PA T3 to
> some degree)
> T2 -- Not Aligned Timer (this appears to match the current M2PA T1 to
some
> degree)
> T3 -- Aligned Timer (this does not appear to have an M2PA equivalent)
> T4N, T4E -- Proving Period Timer(s) (this appears to match the current
M2PA
> T2)
> T5 -- Sending Status Indication Busy Timer (this would be my Busy Rate
> timer)
> T6 -- Remote Congestion Timer (matches M2PA T6)
> T7 -- Excessive Delay of ACK Timer (no M2PA equivalent...yet... could use
> one)
>
> I propose that M2PA be updated to conform to these definitions where
> possible and
> reserve the T1-T10 block of timer identifiers. This would provide for
T11+
> to be
> defined for implementation-dependent purposes (such as my Ready-Rate and
> Processor-Outage-Rate timeouts).
>
> The underlying issue I am trying to address with all of this is to
minimize
> the churn
> in timeout administration for my implementation as M2PA evolves.
>
> Regards,
>
> Jeff
>
>
>
>
>
>
> "Brian F. G. Bidulock" <[email-masked]> on 05/10/2002 06:32:39 PM
>
> Please respond to [email-masked]
>
> To:   [email-masked]
> cc:   [email-masked]
> Subject:  Re: [Sigtran] (M2PA) Please standardize M2PA protocol timer
>       identifiers
>
>
> Jeffrey,
>
> To avoid confusion with Q.704 timers, it might be advisable to
> name M2PA timers that do correspond to a Q.703/704 timer with
> "T1, etc," M2PA timers that do not correspond to a Q.703/704
> timer with a name such as "T-ack," and implementation timers
> with names such as "T-proving-rate".
>
> Come to think of it, all the implementation timers in your
> list describe a "rate" and not a timer at all.  An interval
> timer is only one way of implementing a "rate".  Another
> approach, such as for proving, would be to send P proving
> messages to SCTP and wait an overall interval T-P for all
> proving messages to be acknowledged received by SCTP.  It
> would say that, given the implementation specifics of these
> rates, that naming implementation-dependent timers is of
> little use.
>
> Then all that needs to be done is rename T2 Proving to T4 and
> describe these implementation-dependent things as
> implementation-depenent rates rather than timers.
>
> If you look at the conformance test suite, you will see that
> there is value in describing Q.703 timers T2, T3 and T7 as
> they make the state machine more robust and more compatible
> with Q.703.
>
> --brian
>
> [email-masked] wrote:                    (Fri, 10 May 2002
> 16:57:54)
> >
> > Hello Brian,
> >
> > Having M2PA timers correspond to Q.703 is a good idea.
> >
> > That would mean that the current M2PA timer, T2 Proving, ought to be
T4,
> as
> > per Q.703....
> > Or am I missing something?
> >
> > This would also suggest that M2PA should reserve timers T2, T5, and T7
in
> > addition to
> > the current requirements for T1, T3, and T6.
> >
> > Perhaps implementation-dependent timers should start at T11...
> >
> > Regards,
> >
> > Jeff
> >
> >
> >
> >
> >
> >
> >
> > "Brian F. G. Bidulock" <[email-masked]> on 05/10/2002 04:16:38 PM
> >
> > Please respond to [email-masked]
> >
> > To:   [email-masked]
> > cc:   [email-masked]
> > Subject:  Re: [Sigtran] (M2PA) Please standardize M2PA protocol timer
> >       identifiers
> >
> >
> > Jeffrey,
> >
> > Timer identifiers should correspond to Q.703 where possible.
> >
> > --brian
> >
> > [email-masked] wrote:                    (Fri, 10 May 2002
> > 15:13:22)
> > > Hello All,
> > >
> > > The M2PA v5 draft refers to four specific timer identifiers (T1, T2,
> T3,
> > > and T6) and assigns
> > > specific functional requirements on them. The draft also discusses at
> > least
> > > four more
> > > implementation-dependent timers, such as the 'status_interval' timer.
> > >
> > > I think it would be a good idea for the M2PA specification to reserve
a
> > > block of timer
> > > identifiers (T1, T2,..., T10) for timers having required
functionality
> > and
> > > assign a starting
> > > timer identifier (e.g. T11)  for implementation-dependent timers
(such
> as
> > > Proving Rate).
> > >
> > > This would help reduce confusion as to the purpose of a given
protocol
> > > timer between
> > > different M2PA implementations.
> > >
> > > Having said that,  I would like to see the described
> > > implementation-dependent timers identified in
> > > the draft as follows:
> > >      T4 - proving rate timer (interval between sending LSP messages
> > during
> > > PROVING)
> > >      T5 - ready rate timer (interval between sending LSR messages
> during
> > > READY-ALIGNED)
> > >      T7 - processor outage rate timer (interval between sending LSPO
> > > messages during INS)
> > >      T8 - busy rate timer (interval between sending LSB messages
during
> > > INS)
> > >
> > > Regards,
> > >
> > > Jeff
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> >
> >
> >
> >
> >
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>
>
>
>
>

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

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