Subject: Re: [Sigtran] Repost - More M2PA 7 questions]

From: [email-masked]
Date: Wed, 12 Mar 2003 07:47:46 -0500

Hello All,

 >"The BSNT is the Forward Sequence Number of the last User Data message
 >received from the peer."

 I agree with this wording. The phrase "accepted by" cannot be applied,
 since MTP3 lacks a primitive to ack receipt to L2.

 Regards,

 Jeff

                      "Brian F. G.                                                                                                
                      Bidulock"                To:      Tom George <[email-masked]>                                       
                      <bidulock@openss         cc:      [email-masked]                                                          
                      7.org>                   Subject: Re: [Sigtran] Repost - More M2PA 7 questions]                             
                      Sent by:                                                                                                    
                      sigtran-admin@ie                                                                                            
                      tf.org                                                                                                      

                      03/12/03 02:40                                                                                              
                      AM                                                                                                          
                      Please respond                                                                                              
                      to bidulock                                                                                                 

Tom,

MTP3 does not accept some messages and not accept others.  MTP3 has no
choice but to accept the last (valid) User Data message received from
the peer (unless it is in processor outage, in which case it won't be
retrieving BSNTs).  Whether it accepts it before or after an ack is
initiated makes no difference.  I would strike the "and accepted by..."
as is adds nothing and actually confuses the reader into thinking that
MTP3 might not accept some received messages.

Go with:

 "The BSNT is the Forward Sequence Number of the last User Data message
 received from the peer."

I wish Q.702 had the foresight to say this in the first place.

--brian

Tom George wrote:
(Tue, 11 Mar 2003 14:47:12)
> I will go with this unless (need I say it? 8-) ) there are objections:
>
> "The BSNT is the Forward Sequence Number of the last User Data message
> received from the peer and accepted by the upper layer MTP3."
>
> At first I thought the use of "accepted" in Q.704 was just weasel
> wording. But our discussion indicates that this wording is really
> necessary to cover the different possible orders for acking and getting
> the message to MTP3.
>
> tomG.
>
>
> "Brian F. G. Bidulock" wrote:
> >
> > Andrew,
> >
> > Works for me.
> >
> > --brian
> >
> > Andrew Booth wrote:
(Fri, 07 Mar 2003 21:37:12)
> > > Brian, Tom,
> > >
> > > Sounds good.  If we're using q.704 text rather than q.703 text then
> > > should we make it clear that it represents the MTP3 perspective?
Perhaps
> > > "- the forward sequence number of the last message signal unit
accepted
> > > (by MTP3) from the unavailable signaling link."
> > >
> > > Andrew
> > >
> > >
> > > Brian F. G. Bidulock wrote:
> > >
> > > >Tom,
> > > >
> > > >Well then, just use the Q.704 text.  Certainly noone can disagree
> > > >with it.
> > > >
> > > >--brian
> > > >
> > > >Tom George wrote:
(Fri, 07 Mar 2003 16:23:12)
> > > >
> > > >
> > > >>I am beginning to understand why Q.704 section 5.4.2 words it like
it
> > > >>does:
> > > >>"- the forward sequence number of the last message signal unit
accepted
> > > >>from the unavailable signaling link."
> > > >>
> > > >>I can imagine that long ago, a discussion just like this one took
place
> > > >>at an ITU meeting. At the end, they agreed to use the vague term
> > > >>"accepted" and call it a day. 8-)
> > > >>
> > > >>tomG.
> > > >>
> > > >>
> > > >>Andrew Booth wrote:
> > > >>
> > > >>
> > > >>>Tom, Brian, others
> > > >>>
> > > >>>Comments below.  I've tried to keep the responses short, I'm
composing
> > > >>>some responses to Brian's earlier post as we speak.
> > > >>>
> > > >>>Tom George wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>>>Andrew, Brian, and others,
> > > >>>>
> > > >>>>IF M2PA delays acking a data message, and then gets a Retrieve
BSNT,
> > > >>>>there would be a problem with returning the number of the last
message
> > > >>>>for which the ack was sent.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>Agreed.
> > > >>>
> > > >>>
> > > >>>
> > > >>>>For example, say messages up to number 35 have been received and
> > > >>>>delivered to MTP3 (where they may or may not be queued). But the
acks
> > > >>>>have been sent out up to number 34. For some reason, M2PA is
delaying
> > > >>>>the ack of number 35. Now if M2PA receives a Retrieve BSNT from
MTP3. If
> > > >>>>M2PA returns the number of the last message acked (34), the other
end
> > > >>>>would retransmit beginning with 35 and there could be a
duplication. And
> > > >>>>duplication is very bad.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>Agreed, this would be bad.
> > > >>>
> > > >>>
> > > >>>
> > > >>>>But IMHO the right way to deal with this is to send the ack right
away.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>I think the question of whether to send acks immediately is a
separate
> > > >>>question from how the BSNT should be determined during a Retrieve
BSNT
> > > >>>request; so I disagree with the last statement for some
philosophical
> > > >>>and some practical reasons.
> > > >>>
> > > >>>Philosophically the procedures in M2PA draft 7 to support BSNT
retrieval
> > > >>>try to tie together two procedures that have largely different
purposes:
> > > >>>--- Changeover procedures exists so the remote end knows which
messages
> > > >>>to retransmit.
> > > >>>--- Message acknowledgments help the peer manage it's retransmit
buffer.
> > > >>>I don't understand philosophically why we are trying to phrase the
> > > >>>procedures for changeover in terms of message acknowledgments,
they just
> > > >>>aren't that tightly coupled.  It's because of this artificial
coupling
> > > >>>that we need to start adding other procedures to M2PA that
constrain an
> > > >>>implementation i.e. that you must send acknowledgments
immediately.
> > > >>>
> > > >>>Practically:
> > > >>>1) At what point have we "sent" an ack?  When it's been marked for
> > > >>>acknowledgment?  When the message is passed to SCTP?
> > > >>>2) Depending on the definition chosen for "sending", I see many
> > > >>>potential restrictions on an implementation if it is forced to
send acks
> > > >>>"right away": the receive thread of an app may have to coordinate
with a
> > > >>>sending thread, we may generate extra acknowledgments on every
incoming
> > > >>>message, the SCTP transmit buffer may be full so we can't send
> > > >>>immediately even if we want to, etc.  All these are operational
and/or
> > > >>>implementation considerations that may be better addressed by an
> > > >>>implementation in a particular deployment than in M2PA.
> > > >>>
> > > >>>Andrew
> > > >>>
> > > >>>
> > > >>>
> > > >>>>tomG.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>--
> > > >>* Tom George       PB7-24001 (near B-21)
[email-masked]  *
> > > >>* 972-519-3168   Intranet:
http://www.ssd.usa.alcatel.com/~tgeorge/  *
> > > >>* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas
75075  *
> > > >>* I actively disclaim speaking for Alcatel USA, Inc. I do not
purport *
> > > >>* to advertise or represent its position,  operations, or
activities. *
> > > >>_______________________________________________
> > > >>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.
> > >
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
>
> --
> * Tom George       PB7-24001 (near B-21)      [email-masked]  *
> * 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
> * Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
> * I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
> * to advertise or represent its position,  operations, or activities. *
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

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

---

From: Andrew Booth <[email-masked]>
Date: Wed, 12 Mar 2003 09:59:19 -0500

Hi All,

I'll change my opinion and agree that "accepted by MTP" may be confusing.

The thing that concerns me with Brian's proposed wording is that we seem 
to use "received from the peer" inconsistently. For example, in 
processor outage section,
"Any User Data message received from the peer MUST NOT be acknowledged 
and MUST be buffered"
implies that received from the peer means read from SCTP, rather than 
"deliverable to MTP3". This seems to conflict with the intended use in 
the Changeover section.

Also, are we sure that retirieve BSNT won't happen while in processor 
outage? Note that the q.703 SDLs do allow for a received BSNT request 
while in the processor outage state (Figure 8, sheet 12 of 14), although 
the circumstances where this could arise are unclear. Are there other 
cases where we could have messages in receive buffers at M2PA that may 
not be deliverable to MTP3?

In analogue to L2 detecting errors on the link we could ask what to do 
if an SCTP association goes down while we're in the processor outage 
state with a bunch of messages in M2PA receive buffers. Should we 
deliver these messages immediately to MTP3 or discard them? Depending on 
the decision we need to decide on a different value for the BSNT.

I think that "The BSNT is the FSN of the last User Data message 
deliverable to MTP3" or "The BSNT is the FSN of the last User Data 
message received by MTP3" applies in all cases, but "received from the 
peer" might not always be correct.

Andrew

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