Subject: Re: [Sigtran] M2PA Flush Buffers

From: "TOLGA ASVEREN" <[email-masked]>
Date: Wed, 5 Feb 2003 08:25:56 +0200

Tom,
--- Tom George <[email-masked]> wrote:
> Andrew,
>
> Thanks for the comments. I will gladly defer to
> those with more SS7
> smarts, but I think there is no case where the
> receiver has to know the
> order in which LS and User Data messages were sent.
> MTP2 itself has
> LSSUs jumping to the head of the line when they are
> transmitted.
>
> So what do we do with User Data messages that are
> received after a LS
> PO? We can't just copy MTP2, since the same
> situation does not occur. In
> MTP2, receiving an MSU ends the RPO condition.
>
> The current M2PA does not say exactly what to do,
> which I would
> interpret (if I may "interpret" my own writing) that
> the receiver should
> go ahead and process the User Data messages. The
> presumption would be
> that they are valid messages sent before the RPO
> occurred.
[TOLGA]IMO it is better to mention this in the document. I have some more
questions though:
I assume even after receiving LS(PO) from the peer, M2PA continues to
acknowledge received messages(?)
Similarliy I assume during local processor outage, based on received
acknowledgements buffers are updated(?) IMO, it might be good to clarify
this in the text(if this is the case)
What about T7 on the peer experiencing local processor outage? Will it be
stopped or not? If the above is true, I would think it shouldn´t be
stopped.
In 4.1.4 there is a sentence
"Alternatively, MTP3 may perform data retrieval as part of a changeover
procedure."
Are the described procedures in that sentence and flushing buffers really
alternatives to each other?
>
> Does anyone see a problem with this?
>
> tomG.
>
>
> Andrew Booth wrote:
> >
> > Hi Tom,
> >
> > I'm not an M2PA expert, so I'm not sure how
> important this issue is.  In
> > case it makes things easier, here are some
> thoughts on quick solutions.
> >
> > Problem statement:
> > ==============
> > It looks like there are a few cases in M2PA where
> it would be nice to
> > know the relative order in which a LS and a User
> Data message were sent.
> >  Also, it would be nice if LS messages were
> delivered "as quickly as
> > possible".
> >
> > Solution 1:
> > ========
> > If the issue is to decide where in the User Data
> sequence an LS message
> > fits, why not use the FSN field to indicate it?
> Since the FSN field in
> > a LS message is no longer used for
> acknowledgements, you could just fill
> > the FSN of the LS message with the FSN of the last
> transmitted User Data
> > message.  This would let you have the logical
> ordering you get on a wire
> > while reducing head of line blocking for LS
> messages.  There is still
> > the possiblity that User Data sent after a LS
> message could arrive at
> > the receiver first.
> >
> > Solution 2:
> > ========
> > Alternatively, LS messages could get sent on both
> streams and we could
> > use the reserved space in the M2PA header to
> eliminate duplicates.  This
> > approach involves slightly more complicated
> procedures than the first
> > proposal, but would ensure that an LS message
> arrives before any data
> > that is sent chronologically after it.
> >
> > In either case, the procedures would be very
> restricted in scope and
> > would allow statements like "If a User Data is
> received that was sent
> > after the PO message then...".  Is this worth
> anything?
> >
> > Thoughts?
> > Andrew
> >
> > Tom George wrote:
> >
> > >I think we had this dicussion at the M2PA Interop
> and probably talked
> > >about it on the list long ago. 8-)
> > >
> > >Putting the LS and Data messages on the same
> stream does make it easy to
> > >decide in which order they were sent.
> > >
> > >The thing I have never liked about putting them
> on the same stream is
> > >that a LS message could get stuck in a queue
> behind many User Data
> > >messages.
> > >
> > >MTP2 does not have this problem. It puts LSSUs
> ahead of MSUs in its
> > >transmission buffer.
> > >
> > >If SCTP had an option to put an outgoing message
> at the head of the
> > >queue, it would be OK to send LS and User Data on
> the same stream.
> > >
> > >tomG.
> > >
> > >"Brian F. G. Bidulock" wrote:
> > >  [...]
> > >
> > >
> > >>IMO LS should be sent in same stream as DATA.
> > >>
> > >>In that case DATA received after LS PO is cause
> to place the link out of
> > >>service.
> > >>
> > >>--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Feb 2003 01:03:15 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Wed, 05 Feb 2003 08:25:56)
> alternatives to each other?

To avoid mis-sequencing of messages, neither end should send or
acknowledge messages during LPO.

The receiver of RPO must not acknowledge any messages after the
receipt of RPO to remain consistent with Q.703 and interactions
with Q.704 (time-controlled changeover procedure).  The MTP
Level 3 suffering LPO must know that when LPO begins that
message transmission has ceased so that the time-controlled
changeover procedure time duration is correctly referenced
against the last message transmitted on the blocked link.

To remain consistent with ANSI T1.111.3, both the sender and
the receiver of RPO should re-synchronize sequence numbers
(acknowlege received messages awaiting ack) and cease
transmission of DATA.

Again, just as the side experiencing LPO must reference its
time-controlled changeover at Level 3 against the last message
sent on the blocked link, so must the side detecting RPO
reference its time-controlled changeover procedure against the
last message transmitted peer in RPO.

The peer sending RPO must stop its T7 timer as it cannot expect
an acknowledgement for any messages during RPO (see test case
3.4.1 in draft-bidulock-sigtran-m2pa-test-02.txt).  Both sides
also stop T6 and cease any busy condition (sends BUSY-ENDED if
BUSY was sent previously).

To summarize:

- any data received by an M2PA peer experiencing LPO after an RPO
  has been sent MUST be discarded and MUST NOT be acknowledged.

- the M2PA peer experiencing LPO MUST NOT send any data messages
  between sending PROCESSOR-OUTAGE and PROCESSOR-OUTAGE-ENDED

- the M2PA peer sending PROCESSOR-OUTAGE SHOULD resynchornize
  sequence numbers by acknowledging all outstanding received
  data.

- any data received by an M2PA after receiving PROCESSOR-OUTAGE
  and before receiving PROCESSOR-OUTAGE-ENDED from the peer
  MUST be discarded and MUST NOT be acknowledged.

- the M2PA peer receiving PROCESSOR-OUTAGE MUST NOT send any
  data until receiving PROCESSOR-OUTAGE-ENDED.

- the M2PA peer receiving PROCESSOR-OUTAGE SHOULD resynchronize
  sequence numbers by acknowledging all outstanding data
  received before receiving PROCESSOR-OUTAGE.

This is completely consistent with Q.703/T1.111.3 and has the
benefit that harmful interactions with MTP Level 3 will not be
caused by introducing unexpected behavior (i.e. sending messages
for seconds after MTP Level 3 expects that the link has blocked).

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 5 Feb 2003 02:37:20 -0800 (PST)

Brian,
>   MUST be discarded and MUST NOT be acknowledged.
[TOLGA] In that case, what happens with messages sent
before LS(PO)and arrive after LS(PO)? Similarly what
will happen with messages, which are sent after LS(PE)
but arrive before it?
> for seconds after MTP Level 3 expects that the link

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Feb 2003 14:40:22 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 05 Feb 2003 02:37:20)
> will happen with messages, which are sent after LS(PE)

Will Jeff's correction ("buffer rather than discard",
doh!):

They are treated according to order of arrival not
transmission.  Messages which were actually sent before
LS PO will not be acknowledged until after LS PE.
Messages sent after LS PE that arrive bfore LS PE will
not be acknowledged until the LS PE is actulally
received.  That's what you get by putting LS PO/PE on
stream "0".  I would prefer that the implemnetation be
allowed to decide which stream to place LS on.