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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 1 Oct 2003 06:17:20 -0600

jeffrey.craig,

Just that.  And that an ack needs to be sent if
there is no data.  And a slight description of
how the resyncing is done at the other end  (one
side is explained).

--brian

[email-masked] wrote:                                             (Tue, 30 Sep 2003 17:19:23)
> 
> 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/
> 
> 
> 

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

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

---

From: Tom George <[email-masked]>
Date: Mon, 06 Oct 2003 16:57:46 -0500

I think this is the right way to resolve this issue. I will just have to 
find the 100 places where I said that all LS messages go on stream 0 and 
qualify them.

tomG.

>>So what needs to change in the draft?
   [...]

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
*   I actively disclaim speaking for Alcatel.  I do not purport to    *
*   advertise or represent its position, operations, or activities.   *

---

From: Tom George <[email-masked]>
Date: Thu, 09 Oct 2003 17:49:36 -0500

All,

While working on the revised text, I wrote this example. I am thinking 
about including it in section 5.4. It is more detailed than the other 
examples in section 5, but it might answer some questions.

           A                        B

           User Data FSN=1
           ------------------------->
           User Data FSN=2
           ------------------------->
           User Data FSN=3
           ------------------------->
           User Data FSN=4
           ------------------------->
           User Data FSN=5
           ------------------------->
           User Data FSN=6
           ------------------------->
                     User Data FSN=11
           <-------------------------
                     User Data FSN=12
           <-------------------------
                     User Data FSN=13
           <-------------------------
                     User Data FSN=14
           <-------------------------
                     User Data FSN=15
           <-------------------------
               User Data FSN=16 BSN=3
           <-------------------------

These messages were sent at about the same time, so B did not have
time to process 4-6 yet. A processed 11-13 and was just about to ack
when A detected LPO:

           LS PO FSN=6 BSN=13
           ------------------------->

B can continue acking messages:

               User Data FSN=16 BSN=5
           <-------------------------

A flushes 14-16 (buffer but don't ack) as LPO ends:

           LS PR FSN=6 BSN=13
           ------------------------->

B should not resynch its sequence numbers now and start with
FSN=14. If B sent a message now with FSN=14, A might have trouble
figuring out if it was 14 before the resynch or 14 after the resynch.

A should discard any incoming acks at this point. They could be left
over from before the LS PR. And there is no harm, because A will get
the ack from a later message.

B never got around to processing message 6 so it decides to flush it
from its Receive Buffer. There has to be a way of notifying A of this,
so we use the LS Ready:

                LS Ready FSN=16 BSN=5
           <-------------------------

Now A knows to resynch his FSN to start with 6. He also knows that B
is expecting a resynch-ed sequence number.

B should discard any incoming acks at this point, since it is hard to
know if they were sent before or after B's LS Ready.

           LS Ready FSN=5 BSN=13
           ------------------------->

Now B can resynch his FSN to start with 14. And off we go:

           User Data FSN=6 BSN=13
           ------------------------->
               User Data FSN=14 BSN=5
           <-------------------------

etc.