Re: (M2PA) Initial version of M2PA IG is Now Available

Jeffrey,

Craig, Jeffrey wrote:                          (Sat, 27 May 2006 14:45:54)
> 
> Brian, are you saying that it is obvious that M2PA implementers should
> mark received LSR during proving? Please cite the section of the
> applicable standard that mandates for MTP2 the equivalent procedure
> during proving. Hopefully, your citation will apply to implementations
> for which FISU is not sent continuously (as is the case for M2PA LSR).

MTP2 does not send Link Status Ready.  It has no such message.  RFC 4165
states that Link Status Ready is used by each side to indicate alignment
instead of the FISU [or MSU].  What it does _not_ say is to ignore Link
Status Ready when T4 is running.  Doing so is simply someone's mishappen
invention or just a bug of an implementation.

Such a misbehaving implementation would not even align reliably with
itself.

> One issue is that the M2PA RFC does not mandate that LSR be sent more
> than once.

It is not an issue, once is sufficient for other than broken
implementations that can't even align with themselves.  Anyone can
think of hundreds of other ways that a implementation could be
wrongly implemented.  It is not the place of the protocol specification
to describe nor warn againsst all incorrect behaviour.

> Another issue is that the RFC does not mandate a rate to send LSR, if
> the implementer chooses to send it periodically. An optimally
> interoperable M2PA implementation, therefore, should send LSRs
> periodically and should handle a peer that sends only one LSR (which
> may arrive during proving). The IG says this.

It is a poor recomendation to suggest that an implementation should
accomodate a broken implementation that cannot align with itself.  It
is a better SS7 network policy to fail alignment with links that present
obvious interoperability problems.

> 
> Brian stated:
> > Experience with SS7 makes me disagee.  Forcing a link to fail is bad, the
> > result being increased message loss in the network.
> > ...
> > This later is because failing the link before changeover will
> > result in message loss.
> > ...
> > I think that, asside from excessive delay of acknowledgement of actual
> > MSUs, MTP3 should decide when to fail a blocked link.
> 
> Un-bounded protocol waits are bad.

The wait is not unbounded: it is bounded by MTP3 T1.

> Sometimes it is necessary for M2PA to fail the link, and not receiving
> LSR(1) for seconds after sending LSPR is one of those times.

MTP3 will fail the link in T1 (2 seconds).

> As Brian suggests, for the scenario to happen, something serious must
> go wrong.  So why keep the link aligned when something has gone
> seriously wrong?

I did not say that something was seriously wrong: I said that the only
reason for a delay from a validated implementation was a transport
delay.  As LSPR is sent in the data stream, this could simply be
because of HOL blocking on user Data messages already queued for
delivery to the peer by SCTP with a closed cwnd, not anything serious.

Whether the blockage of the link is "of long duration" is an MTP 3
concept already address by Q.704 with the T1 timer.

> Brian, are you saying that the scenario can't happen or are you saying
> it can only happen for contrived test cases (of which I have at least
> one)?

I'm saying that failing in the link at MTP 2 is not proper SS7 engineering
because it causes MTP 3 to unnecessarily discard messages.  MTP 3 must
be allowed to decide whether to clear buffers or resume the link so that
buffered messages can be properly treated at each end with minimal
message loss.  This invented procedure at MTP 2 stands to impair MTP's
ability to provide an expected grade of service to its users.

If you fail the link any time before MTP 3 T1 when the link could have
recovered within T1, you will cause a changeover where none was
necessary.  An increased number of changeovers increases the number of
lost, duplicated and missequenced messages.  ANSI T1.111.4/Q.704
explicity warn about this.  So, by failing the link before T1, the
opposite of the desired effect results.

If you wait until after T1, MTP 3 will complete changeover anyway whether
the link is later failed or not.

> Brian, please explain in more detail why this form of 'failing the
> link' results in more message loss than other forms of 'failing the
> link', such as association failure.

It doesn't.  What contributes increased message loss and missequencing
is the fact that failing the link when it was not necessary to do so
increases the number of changeovers which increases message loss and
missequencing.  By not adding this procedure, MTP 3 is fully in control
of when it performs a changeover on a blocked link and will properly
handle the disposition of buffers (i.e. can resume without changeover).

> Please explain why M2PA should not fail a blocked link when the
> association fails. Citing applicable standards text would be a good
> start.

I did not say that M2PA should not fail a link when the association
fails.  The proposed standard RFC 4165 section 4.1.7 addresses link
failure due to SCTP Communication Lost notification to M2PA.

> 
> Brian stated:
> > I believe transport grade of service should be dealt with at the
> network 
> > and transport levels and is largely an operational consideration.
> 
> Perhaps I am misunderstanding what you are trying to say, but
> I know of a few large operators who disagree with it as written.

Yes, I would expect that "operators" would be concerned with
"operational considerations", but they have little place in IETF
protocol specifications.

> M2PA should have an awareness of its transport and implement error rate
> monitors, somewhat like MTP2 and ATM, to ensure that the quality of the
> transport is sufficient to sustain an in-service signaling link. T7
> expiry is not the best mechanism for achieving this.

Funny you should mention ATM.  Q.2210 does not replace the Q.703
AERM/SUERM with an extra mechanism in MTP3b: SSCOP performs error
detection and receives indications from AAL5.  In a similar way under
M2PA, SCTP performs error detection and receives indications from IP.
Neither in MTP3b nor in M2PA are separate error mechanisms instituted
beyond T7.  When developing the RFC we agreed by consensus to follow
closely the already tried and true model of Q.2210.

Also, any method you can imaging will not be applicable to all IP
network scenarios.  This is best addressed at the network and SCTP
levels.  SCTP parameters can be adjusted to acheive just about whatever
objectives an operator has.  IP is so flexible that it can be closely
constrained if desired: an operator can run MPOA or CLIP over a CBR VC
over ATM AAL5 if they want.  Or they could run a priority VLAN on IP
running directly over SONET.

Understand that it is outside the scope of the SIGTRAN WG to come up
with new QOS protocols or procedures.  There are ample protocols,
mechanisms and procedures available to operators as provided by the
IETF in other transport area working groups.

This _is_ the rationale and consensus that the WG took during the
development of the M2PA protocol and approved by the WG when the
RFC was issued.  I don't know why you would want to undermine that
consensus now.

--brian

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