Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on stream 1 and LSPR used to re-synch resolves PO issue?

From: [email-masked]
Date: Tue, 30 Sep 2003 17:19:23 -0400

Hello Brian,

Okay.
1) LSPO and LSPR should be sent on stream 1.
2) LSPR, data, and ACK are used to re-synch.

So what needs to change in the draft?

Regards,

Jeff

                      "Brian F. G.                                                                                                
                      Bidulock"                To:      [email-masked]                                                 
                      <bidulock@openss         cc:      Andrew Booth <[email-masked]>, [email-masked]                            
                      7.org>                   Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on stream 1 and LSPR used to      
                                               re-synch resolves PO issue?                                                        
                      09/30/03 03:59                                                                                              
                      PM                                                                                                          
                      Please respond                                                                                              
                      to bidulock                                                                                                 

jeffrey.craig,

The problem is, of course, if a DATA is not forthcoming.

I proposed sending DATA ACK immediately, but then LSPR (on
stream "0") and DATA ACK (on stream "1") could be out of
sync with LSPR.  So I proposed LSR on stream "0" instead
of DATA ACK.  If LSPR is on stream 1, I suppose we could
go back to DATA ACK.

Point being is something needs to be sent if DATA is not
available, and it needs to be sent on the same stream as
LSPR.

If LSPR is on stream "1" we can go back to using DATA
ACK.

--brian

[email-masked] wrote:
(Tue, 30 Sep 2003 15:42:54)
>
> Hello Brian,
>
> >It takes two FISUs to complete the flushing and
> >resynchronization.
>
> Not entirely true: FISUs or MSUs.
> M2PA user data and ACK also suffice.
>
> What M2PA text needs to change for this issue?
> Anyone can read the M2PA norm references.
>
> Regards,
>
> Jeff
>
>
>
>
>
>                       "Brian F. G.
>                       Bidulock"                To:
[email-masked]
>                       <bidulock@openss         cc:      Andrew Booth
<[email-masked]>, [email-masked]
>                       7.org>                   Subject: Re: [Sigtran]
(M2PA) LSPO and LSPR sent on stream 1 and
>                                                LSPR used to re-synch
resolves PO issue?
>                       09/30/03 02:20
>                       PM
>                       Please respond
>                       to bidulock
>
>
>
>
>
>
> jeffrey.craig,
>
> See ANSI T1.111.3 Section 8.  It takes two FISUs to complete the flushing
> and
> resynchronization.  It is not a handshake.  The LSPR represents the first
> FISU and the LSR the second.  That is all.
>
> --brian
>
> [email-masked] wrote:
> (Tue, 30 Sep 2003 11:02:40)
> >
> > Hello Andrew,
> >
> > >I think there is still the question of whether the side experiencing
LPO
> > >is supposed to resynchronize sequence numbers after a flush and if so,
> > how.
> >
> > What exactly (in detail) is the problem with M2PA's support of PO?
> > Why is sending LSPR (or ACK) not sufficient to re-synch? (An example
flow
> > diagram with queues and sequence numbers would really help).
> >
> > I see nothing in the Q.703 SDL describing a three-way handshake
> > in order to re-synch. All I see is the side experiencing LPO sending a
> > FISU with updated BSN upon the recovered event, and the Flush/Clear
event
> > triggering entry to In Service (and enabling transmission of MSU/FISU).
> > I see the RPO side exiting to In Service upon receipt of FISU and
> > Clear/Flush.
> >
> > Questions regarding Brian's PO proposal:
> >
> > >Yes.  I propose sending LS Ready response to LSPR to accomplish this.
> > >If LSPR is sent on stream 1, this LS Ready should be sent on stream 1
as
> > >well, as follows:
> > >
> > >all on stream 1:
> > >
> > >   LSPR
> > >   --------------->
> > >   DATA (ACK)
> > >   <---------------
> > >   <---------------
> > >   <---------------
> > >   LSR
> > >   <---------------
> > >   resync
> > >
> > >   DATA ACK
> > >   --------------->
> > >   LSR
> > >   --------------->
> > >   resync
> >
> >
> > Why must LSR be exchanged? (What information is lacking on the LPO side
> > that requires receipt of LSR? Why is the LSPR insufficient to complete
> > the re-synch?)
> >
> > Why must LSR, an alignment primitive, be used rather than an ACK?
> >
> > What does the LPO side do with data for transmit while waiting for LSR?
> >
> > How long should the LPO side wait for LSR?
> >
> > What does the LPO side do if no LSR is received prior to timeout?
> >
> > How long does the non-LPO side wait for a LSR after receiving LSPR?
> >
> > What does the non-LPO side do if no LSR is received after LSPR?
> >
> > What happens after LSPR receipt if non-ack data arrives prior to LSR?
> >
> >
> > Regards,
> >
> > Jeff
> >
> >
> >
> >
> >
> >
> >                       Andrew Booth
> >                       <[email-masked]>          To:
> [email-masked]
> >                                                cc:
[email-masked]
> >                       09/25/03 03:18           Subject: Re: [Sigtran]
> (M2PA) LSPO and LSPR sent on stream 1 and LSPR used to
> >                       PM                       re-synch resolves PO
> issue?
> >
> >
> >
> >
> >
> >
> > Hi Jeff,
> >
> > I think there is still the question of whether the side experiencing
LPO
> > is supposed to resynchronize sequence numbers after a flush and if so,
> how.
> >
> > Andrew
> >
> > [email-masked] wrote:
> >
> > >Hello All,
> > >
> > >I also agree LSPO and LSPR should be sent on stream 1, and that LSPR
> > >should be used to re-synch sequence numbers.
> > >
> > >Does this resolve all of M2PA's outstanding processor outage issues?
> > >
> > >Regards,
> > >
> > >Jeff
> > >
> > >
> > >
> > >
> > >                      David Lehmann
> > >                      <lehmann@ulticom         To:
> > [email-masked]
> > >                      .com>                    cc:
> > [email-masked], Andrew Booth <[email-masked]>, Tom George
> > >                      Sent by:
<[email-masked]>,
> > [email-masked]
> > >                      sigtran-admin@ie         Subject: Re: [Sigtran]
> Misc
> > M2PA questions
> > >                      tf.org
> > >
> > >
> > >                      09/19/03 11:21
> > >                      AM
> > >
> > >
> > >
> > >
> > >
> > >
> > >Brian F. G. Bidulock wrote:
> > >
> > >
> > >>I still think
> > >>that LS PO and LS PR (or maybe just LS PR) should be sent on stream
'1'
> > >>
> > >>
> > >to
> > >
> > >
> > >>avoid problems in the wild.
> > >>
> > >>
> > >
> > >I agree that both LSPO and LSPR should be on the data stream.
> > >Was there any resolution on this matter?
> > >
> > >--
> > >
> > >David Lehmann                          Ulticom, Inc.
> > >AOL/Yahoo IM: davidULCM                1020 Briggs Road
> > >1-856-787-2729                         Mt. Laurel, NJ 08054   USA
> > >
> > >
> > >_______________________________________________
> > >Sigtran mailing list
> > >[email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >Sigtran mailing list
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> >
> > --
> > Andrew Booth, Software Developer
> > Signaling Systems Group, Performance Technologies
> > 613-237-4344
> >
> > Visit www.pt.com/mailing.html to subscribe to our Packets & Signals
> > eLetter.
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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/

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

---

From: Andrew Booth <[email-masked]>
Date: Tue, 30 Sep 2003 18:23:48 -0400

Hi Jeff,

I haven't been ignoring your question, but rather thinking on how to 
clearly write down what I perceive as the outstanding issues...  I'll 
reply soon (probably tomorrow) with some more detail once I've rechecked 
the details and can write things down clearly.  If you're interested in 
the scribbled version, some thoughts are below.

The thoughts below pertain to the side in LPO rather than the side in 
RPO.  In a nutshell:
- The side in LPO should resynch after a flush
- in MTP2 it would use a FISU or DATA
- there is nothing in M2PA draft 9 that indicates how the side in PO 
should sync, so we should use the same approach as in MTP2 or add text 
to the draft.

I think the issue with using data/data ack to resync the side in LPO is 
that its difficult to tell which data acks were sent before the remote 
side entered PO vs after, hence the risk of resynching using the wrong 
BSN.  This is fundamentally a timing issue which should not be an issue 
in MTP2 because FISUs are sent constantly.  The timing issues are made 
worse in M2PA because:
- we're going over IP
- it's not explicit in the draft that we need to fail the SCTP assoc 
within MTP T1 (and this might not be acceptable to the IETF), even 
though legitimate implementations will have to
- we recently allowed the side in LPO to continue sending it's TB.  This 
might have been a mistake and I would not be adverse to removing it.

Also, it is not specified that the side in RPO should periodically send 
(redundant) data acks, so there's no guarantee that a data ack will 
arrive promptly for the side in LPO to synch from.

Andrew

Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter.