Subject: RE: [Sigtran] (M2PA) Initial version of M2PA IG is Now Available

From: "Davidson, Mark" <[email-masked]>
Date: Fri, 26 May 2006 09:22:50 -0500

The waiting occurs after the LSPR is sent (an LSR has not yet been
sent).
I.e., the LPO side waits for the first LSR, but the RPO side does not
need to wait for the second one.  The change you refer to affected
the RPO side.  The wait I'm referring to is on the LPO side.

If Q.703 is followed closely the link will not align.  I think that's
a problem.

-Mark

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Friday, May 26, 2006 10:03 AM
To: Davidson, Mark
Cc: [email-masked]
Subject: Re: [Sigtran] (M2PA) Initial version of M2PA IG is Now
Available

Davidson,,

Davidson, Mark wrote:                                            (Fri,
26 May 2006 08:40:15)

<snip>
> > 
> >> The additional states introduced by the processor outage recovery 
> >> procedure (waiting for an LSR on stream 1) introduces several 
> >> issues that should be clarified (or failing the link should be an 
> >> option as they really aren't worth the effort required to solve
them).
> >
> >That was the change made at 48 hours.  There is no waiting for LSR
> state in the RFC.
> >
> 
> Waiting for the 2nd LSR after LSPR was changed, but NOT waiting for 
> the first one. This text is still there:
> 
> "M2PA SHALL cease transmitting User Data messages after sending the  
> Link Status Processor Recovered message, until it has received the  
> Link Status Ready message ..."

and it continues, ... "(see below)".  And below it says:

   "M2PA SHALL NOT resume transmitting User Data messages until it has
   sent the Link Status Ready message."

The change made at 48 hours.

No waiting.

Also changed at 48 hours was the Example in 5.4, Figure 16, that quite
clearly shows (at the bottom of Page 40 and the top of Page 41) that
after LS Ready is _sent_ messages are accepted for transmission and user
data is transmitted.  The notes in the diagram also states:

  "B has completed synchronization of sequence numbers and has sent
   and LS Ready, so it is able to resume sending data at this point
   with the new sequence numbers (starting with FSN=14)."

No waiting.

Perhaps "received" should be changed to "sent" in the initial passage
that you quote, but that is a far cry from the several pages of text
that the IG suggests be replaced.

> 
> >> 
> >> Some of the issues in the draft WERE discussed on this list (e.g.
> >> alignment bugs in Q.703 SDLs) and satisfactory answers were not 
> >> forthcoming.
> >
> >Which issues where those?  
> >
> >I don't think that bugs in SDLs developed by the ITU are within the
> scope of M2PA.  Do you?
> >
> 
> M2PA says you can base an implementation on Q.703.  If Q.703 has 
> errors that affect operability of M2PA implementations they should be 
> addressed.

Q.703 SDLs are not authorative on their own: where they disagree with
the text of Q.703, the text wins.  You think that M2PA should correct
Q.703 SDLs?

--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, 26 May 2006 10:01:08 -0600

Mark,

Davidson, Mark wrote:                      (Fri, 26 May 2006 09:22:50)
> the RPO side.  The wait I'm referring to is on the LPO side.

Just as the side exiting LPO must wait for a FISU or MSU in ANSI
T1.113.3-2000 Clause 8 (Q.703 has little to say on the matter).
M2PA just uses LSR in this case instead of a FISU or MSU.

I take it back: "receive" in the passage you quoted can stay at
"receive".  No change required.

> If Q.703 is followed closely the link will not align.  I think that's

It doesn't appear that all those Q.703 implementations out there have
any problem aligning.

So you don't think that M2PA should correct Q.703 SDLs?

--brian

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

---

From: Andrew Booth <[email-masked]>
Date: Fri, 26 May 2006 15:01:51 -0400

Hi Brian,

Some comments and questions inline.

>"receive".  No change required.
I agree that the behaviour is similar to MTP2, but the effect on the
network is bad (link congestion or messages queued for arbitrary time). 
I think failing the link after T7 in this case would make the protocol
better.  Do you agree?

>So you don't think that M2PA should correct Q.703 SDLs?
What do you think of section 2.5 of Jeff's document?  Is it a legitimate
concern?

Andrew

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 26 May 2006 15:32:45 -0600

Andrew,

Andrew Booth wrote:                                                 (Fri, 26 May 2006 15:01:51)
> I think failing the link after T7 in this case would make the protocol

Experience with SS7 makes me disagee.  Forcing a link to fail is bad, the
result being increased message loss in the network.

It think that implementations should be validated to behave correctly as
with SS7; therefore, the only thing that could delay the LSR would be the
transport.  I believe transport grade of service should be dealt with at
the network and transport levels and is largely an operational consideration.

For example, we recently discussed a case (on tsvwg) where the SCTP stack
parameters were set so that it took over 3 seconds for a multi-homed SCTP
host to switch from the primary address to the secondary, resulting in link
failure from T7 time expiry whenever the primary failed.

Before failing the link in such a manner, one would need to check that the
LSPR was acknowledged by the other end at the transport and that the current
experienced RTT is not approaching T7, or even that it is beneath T6, and that
MTP3 has already changed over (Q.704-T1 expiry, processor outage is of a long
duration).  This later is because failing the link before changeover will
result in message loss.  But then, if you wait for MTP3 T1 to expire and
changeover to occur, it makes no difference whether you wait or fail the
link because changeover has occured.

I think that, asside from excessive delay of acknowledgement of actual MSUs,
MTP3 should decide when to fail a blocked link.

> What do you think of section 2.5 of Jeff's document?  Is it a legitimate

No, I don't.  I've had running code there for 5 years.

Where does it say RFC 4165 that LS Ready is ignored while T4 is running?

I see where it says that a peer MAY send additional LS Ready messages while
timer T1 is running.  If you are concerned that the other end has sent LS
Ready and is (for some bad reason) ignoring your previous LS Ready messages,
send another in response.  You are permitted by the RFC to do so.  That is
you always MAY send additional LS Ready messages while timer T1 is running.
In fact, you could pace them in the same manner as LS Proving messages from
the moment you send the first one.

I think that the RFC should prescribe the desired behaviour rather than going
to lengths to counter-recommend all undesired behavior.

Again I think that implementations should be validated.  See test case 3.1.5.
Would such a misbehaving implementation even align with itself?  Or would it
fail this test.

--brian

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