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

From: Tom George <[email-masked]>
Date: Tue, 04 Mar 2003 17:45:00 -0600

Andrew and others,

I sought guidance from MTP. 

Q.704 section 5.4.2 avoids the issue: 
"- the forward sequence number of the last message signal unit accepted
from the unavailable signaling link." 

>From what I can tell Q.703 does not address this directly.  In Figure 14
(sheet 3 of 7), the BSNR and BIBR are sent RC -> TXC, which means that
the message will be acknowledged when TXC sends its next signal unit.
Then we continue over to sheet 5, where the Received message is sent RC
-> L3.

>From the way it is written, it looks like it is a race as to whether the
ack will be sent before or after the message is delivered to MTP3. 

I don't think it is a good idea for M2PA to be delaying acks. 

As for the way to word the requirement in M2PA, we could go with Q.704's
use of a non-specific word. I don't really care for that approach. I
would prefer to keep it the way I have it now. If there is a problem
caused by a delay in the ack, IMHO we should discourage such delays.

tomG.

Andrew Booth wrote:
> 
> Tom, Brian,
> 
> Is M2PA also allowed to withhold acknowledgements briefly? i.e. can't I
> have delivered a message to MTP3 but not yet sent the acknowledgement?
>  Perhaps
> 
>    M2PA determines the Forward Sequence Number of the last User Data message
>    received from the peer which has been marked for acknowledgement i.e. which
>    is guaranteed to be delivered to MTP3.
> 
> Andrew
> 
> Tom George wrote:
> 
> >Brian,
> >
> >Good point. Now it says:
> >
> >M2PA
> >determines the Forward Sequence Number of the last User Data message
> >received from the peer for which an acknowledgement was sent.
> >
> >tomG.
> >
> >
> >"Brian F. G. Bidulock" wrote:
> >
> >
> >>Tom,
> >>
> >>Well....
> >>
> >>MTP2 is allowed to acknowledge messages which have not actually been
> >>delivered to MTP3.  It would be better to say that "the BSNT is the
> >>FSN of the last User Data message received for which an acknowledgement
> >>was sent."  The timing of actual deliveries to MTP3 is implementation
> >>dependent.
> >>
> >>--brian
> >  [...]

-- 
* 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Mar 2003 17:16:37 -0700

Tom,

> > >received from the peer for which an acknowledgement was sent.

Tom George wrote:                                   (Tue, 04 Mar 2003 17:45:00)
> ack will be sent before or after the message is delivered to MTP3. 

You will find many races that makes Q.703 SDLs fail to operate properly
it they are viewed as asynchronous.  If you consider that events do not
occur until after the SDL exists in its new state, there are no races.

Even still, delivery to L3 (RC->L3) does not mean that the MSU does not
enter a queue.  For changeover procedures, it does not matter whether an
MSU was actually delivered to MTP3 or not.  Passing the BSNT as FSNC is
meant to address messages which were acknowledged by the peer but for
which the acknowledgement failed to arrive.  This is why I prefer your
wording above, "for which an acknowledgement was sent".

--brian

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

---

From: Andrew Booth <[email-masked]>
Date: Thu, 06 Mar 2003 11:17:16 -0500

Tom, Brian,

Comments below.

>>Then we continue over to sheet 5, where the Received message is sent RC
In q.703 figure 15 (sheet 5) we get the chain: "Received Message 
RC->L3", "FSNX := FSNX+1", "FSNX value RC->TXC" (assuming no congestion).
When MTP3 sends a "Retrieve BSNT" then by the functional block diagram 
(q.703, figure 7) the message goes to Reception Control and returns FSNX 
-1; the Retrieve BSNT request does not go to Transmission Control.

My interpretation is that it is the FSN of the last message sent to MTP3 
that is returned on a Retrieve BSNT request.  The acknowledgment of a 
message is not sent by MTP2 until TXC receives the updated FSNX and then 
sends it's next MSU or FISU, hence a delay between when the FSNX is 
updated at RC and when the acknowledgment is sent by TXC.

>occur until after the SDL exists in its new state, there are no races.
My understanding of SDLs may be incorrect, but I think I mostly agree 
with both of you.

Within a state transition (i.e. while processing an event) the 
functional block does not process additional inputs and hence there are 
no races.
In this case the signals "Received message RC->L3" and "FSNX value 
RC->TXC" are sent to different functional blocks and will be processed 
in some unknown order.  So I think that there is a race between whether 
the ack is sent before the message is __processed__ by MTP3.  My 
interpretation though is that the message is __delivered__ to MTP3 as 
soon as the signal "Received Message RC->L3" is sent, and this signal is 
always sent before the ack is sent (again by figure 14 sheet 5).

>wording above, "for which an acknowledgement was sent".
I don't understand your reasoning here.  My impression is that 
changeover procedures allow messages to be diverted to alternate links 
with no message loss or missequencing.  To avoid message loss and 
missequencing then the messages that the remote MTP retransmits should 
be exactly those that the local MTP is not going to process without a 
retransmission, and that's what should determine the BSNT.

>>I don't think it is a good idea for M2PA to be delaying acks. 
What I had in mind is an implementation similar to my understanding of 
MTP2: when a message is delivered to MTP3 then the FSNX is updated 
accordingly.  The next time a User Data message is sent it could carry 
the acknowledgment; if there is no User Data message to send within a 
configured period (say 10ms) then an ack is generated and sent.  If you 
happen to be sending a large MSU in MTP2 when you update the FSNX then 
you could get a similar delay in acknowledgment.

>>caused by a delay in the ack, IMHO we should discourage such delays.
I still like "the BSNT is the FSN of the last message that has been sent 
to MTP3".  It's not overly precise but it is simple and may be clear enough.

Andrew

-- 
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.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Mar 2003 09:36:54 -0700

Andrew,

Andrew Booth wrote:                                                                 (Thu, 06 Mar 2003 11:17:16)
> updated at RC and when the acknowledgment is sent by TXC.

But M2PA does not have to wait to send acknowledgement, so Tom's wording
above still works.

> always sent before the ack is sent (again by figure 14 sheet 5).

But there is no text requiring this, so the SDL's don't matter there.
There are illustrative only.  Some implementations queue, some don't.
Some ack before, some ack after.  Some implementations ack after L3
removes the MSU from the queue, some ack before.  I was working on an
implementation that didn't ack on in incoming link until it received
an ack on the outgoing link (or from the L3 API): a kindof zero-loss
STP if you will.

> with no message loss or missequencing.

BSNT does not do anything for missequencing.  It does address message loss
and duplication, but duplication is far worse than message loss.  So it is
better to lose some message in between L2 and L3 than to duplicate (by
not indicating acknowledged a message that was "delivered" to L3.)

> To avoid message loss and missequencing then the messages that the remote
> MTP retransmits should be exactly those that the local MTP is not going to
> process without a retransmission, and that's what should determine the BSNT.

The only messages that can be retransmitted are those for which no
acknowledgement has yet been sent.  BSNT is the sequence number of the
last message for which an acknowledgement was sent.

> you could get a similar delay in acknowledgment.

MTP2 does not delay acks.  The worst case is the remainder of the emission
time of the current SU for which the BSN/BIB,FSN/FIB have already been sent.
Intentionally delaying acks seriously impairs the queueing performance of
the link.  Why would you delay anyway?  An SN is sent with each frame.
Nothing can be saved by not updating it immediately.

> to MTP3".  It's not overly precise but it is simple and may be clear enough.

"Sent to MTP3" is internal to an implementation and cannot be tested
with a protocol tester or observed by a peer.

"For which an acknowlegment was sent" is external to an implementation an
can be tested with a protocol tester and observed by a peer.

--brian

---

From: Tom George <[email-masked]>
Date: Thu, 06 Mar 2003 14:32:04 -0600

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. 

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. 

But IMHO the right way to deal with this is to send the ack right away. 

tomG.

---

From: Andrew Booth <[email-masked]>
Date: Fri, 07 Mar 2003 16:06:53 -0500

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.

>for which the ack was sent. 
Agreed.

>would retransmit beginning with 35 and there could be a duplication. And
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

---

From: Tom George <[email-masked]>
Date: Fri, 07 Mar 2003 16:23:12 -0600

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.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Mar 2003 17:46:58 -0700

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)

---

From: Andrew Booth <[email-masked]>
Date: Fri, 07 Mar 2003 20:25:42 -0500

Brian,

>But M2PA does not have to wait to send acknowledgement, so Tom's wording
It only works if the M2PA implementation actually does send messages 
immediately, which is not specified in the current draft.  For the M2PA 
draft 7 wording to be accurate in all cases we should add the following:
1) An M2PA implementation MUST send acks immediately immediately after 
sending to MTP3
2) Clearly define when an ack has been "sent"
3) If there is any chance that "sending" an ack could fail or be delayed 
then there should be procedures for what BSNT to use for a retrieve BSNT 
response while you're waiting to send the ack.  The solution to this 
point will probably be that you have to reply with the last FSN which 
has been marked for acknowledgment, which should be the last FSN sent to 
MTP3, and we're back where we started.

All this is a reasonable amount of text to add, and it assumes that we 
even want to require implementations to send acks immediately.  I don't 
feel like this is a reasonable constraint to place on an implementation.

>an ack on the outgoing link (or from the L3 API): a kindof zero-loss
My understanding is that Tom went to MTP2 for guidance, not for a 
binding decision.  In particular, the MTP2 SDLs do give an example of 
how to decide on the BSNT to use when replying to a retrieve BSNT 
request.  They use the FSN of the last message delivered to MTP3 by RC, 
not the BSN last sent by TXC as is currently the text in M2PA.

I'm not claiming that we have to do things the way the MTP2 SDLs do,  I 
just don't see why we'd want to do things differently in this case.

>not indicating acknowledged a message that was "delivered" to L3.)
Agreed, my comment was poorly worded.  However, there is no reason why 
you should have to lose or duplicate messages.  The BSNT should be 
chosen to represent exactly the messages that have been delivered to MTP3.

>last message for which an acknowledgement was sent.
What do you mean by "sent"?  Sent to SCTP or marked for acknowledgment?

>Nothing can be saved by not updating it immediately.
In MTP2 the emission time of the current SU may be substantial, possibly 
as high as 30-40ms for a 273B message on a 56kb/s link.  Until that SU 
clears you can't "send" any further acknowledgments, you can just mark 
messages for acknowledgment to be acked with the next SU.  So while MTP2 
doesn't explicitly delay acks there are limits to how fast we can send 
these acks.  This is the "delay" I was referring to.

The end result: if you introduce a small delay before you send an M2PA 
ack you should still get comparable response times as compared to MTP2. 
 Even a 30B message in MTP2 would take about 4ms in propagation time.

>can be tested with a protocol tester and observed by a peer.
I don't think the current M2PA draft 7 text really helps us test this 
piece of M2PA functionality better than the proposed alternative.

I think what you're saying is that the text as it stands allows the M2PA 
layer to be tested by a protocol tester that doesn't know anything about 
the M2PA implementation.  I don't know if this is possible to do, and I 
don't see the test you've proposed as an adequate one.

To validate that the M2PA layer is performing Retrieve BSNT correctly 
the key thing to check is that the BSNT it returns from a Retrieve BSNT 
request agrees with the FSN of the last message received by MTP3.  If 
M2PA passes this check in all code paths, race conditions, etc then it 
is performing it function correctly; if it doesn't then it is flawed.

What you are proposing to test, that the BSNT value sent to the upper 
layer and the BSNT value sent in the last User Data acks agree, is not 
the crucial point.  In fact it would be easy to "fake" this test even if 
the M2PA layer never passed a single message to MTP3.

There are two ways that I can think of to properly test the M2PA 
changeover behaviour:
1) Hook into the upper boundary somehow, say by adding some logging to 
MTP3.  Then we can directly check that the number of messages received 
on a link corresponds with the received BSNT.  This is the easiest way 
but is not generic, and is ideally suited to a test stub that takes the 
place of MTP3 during unit testing.  If we do use a test stub then we 
still haven't tested that the MTP3 and MTP2 are compatible in the way 
the interface is interpreted.
2) Test changeover completely, including MTP3 functionality.  This test 
is generic.  To do this in automated fashion you could do something like 
the following:
- Use an MTP3 to drive the M2PA layer of the System Under Test (SUT)
- Align two linksets between the tester and the SUT.  One linkset should 
have at least 2 links so that changeover is possible (or set up a 
combined linkset).
- Have the protocol tester send messages to itself, out one linkset and 
back on the other.  Include some information in the MTP3 user data of 
the messages so that message loss or duplication can be detected when 
the messages are received by the tester.
- Have the tester take a link out of service and check that the BSNT in 
the COO correctly reflects the messsages received by the tester at the 
destination.

Performing either or both of these test several times with various 
traffic loads should give a high degree of confidence that the M2PA 
layer is performing correctly and also that the MTP3 and M2PA are 
working together correctly.  The second test is generic and has a high 
probability of detecting issues, but does require you to test the MTP3 
as well as M2PA.

In either case it could be very hard to check that you have hit all the 
race conditions and code paths in an implementation, especially if 
you're using a generic tester that knows nothing about the 
implementation that it is testing.

To summarize: testing well is probably going to be hard no matter what. 
 It will be easiest if you can use specific knowledge about the 
implementation.  The current M2PA draft 7 text doesn't helps us test 
this piece of M2PA functionality better than the proposed alternative.

Andrew

---

From: Andrew Booth <[email-masked]>
Date: Fri, 07 Mar 2003 21:37:12 -0500

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Mar 2003 22:21:06 -0700

Andrew,

Works for me.

--brian

Andrew Booth wrote:                                                                 (Fri, 07 Mar 2003 21:37:12)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Mar 2003 23:30:52 -0700

Andrew,

Andrew Booth wrote:                                                                 (Fri, 07 Mar 2003 20:25:42)
> MTP3, and we're back where we started.

Not really, an MSU can be acknowledged without delivering it to MTP3 (yet).
See below.

> feel like this is a reasonable constraint to place on an implementation.

I do agree that some imperatives in the text would be a good thing.

> just don't see why we'd want to do things differently in this case.

The MTP2 SDLs are not so clear on this point so I would agree with you.
The MTP2 SDL system diagrams include a receive buffer (with messages in
it and implementation dependent receive congestion functions), however,
the State diagrams themselves never refer to the RB except when MTP3
request that it be cleared.

> >>with no message loss or missequencing.

Read the Clause 5 of Q.704.  Actually sequenced changeover procedures allow
messages to be diverted quickly.  Time-controlled changeover procedures are
recommended in some configurations to avoid message missequencing that
would result from sequenced changeover.  Some installations always perform
time-controlled changeover to avoid mis-sequencing (and it is permitted by
many protocol variants).  The very reason that message loss from
time-controlled changeover is acceptable is that MTP2 does not delay acks.
At engineered traffic levels, very few messages will be in the retransmission
buffer at changeover.  Delaying acks will increase the number of messages
in the retransmission buffer at changeover and will increase the number
of messages lost due to time-controlled changeover procedures.  As MTP3
is permitted to alwasy use time-controlled changeover procedures, delaying
acks in M2PA would have a negative effect not present in current MTP2
implementations.  That would be bad.  I don't have a problem saying that
M2PA MUST NOT delay acknowledgements.  They particularly MUST NOT try to
delay them for the misplaced purpose of piggybacking them on outgoing DATA
messages.

> chosen to represent exactly the messages that have been delivered to MTP3.

It is a little bit more than that.  I have always used the word "deliverable".
This is because if MTP2/M2PA has internally buffered received messages in the
Receive Buffer (RB) [and, yes, one exists in Q.703] and those message have not
yet been delivered to MTP3, but will shortly, then the BSNT had better include
those as well.  If the MTP2 is going to clear the RB without delivering these
messages to MTP3 (not "deliverable") then it would appear that they need not
be included in the BSNT, but that is the wrong thing to do (making the distant
SP retransmit them when they can be delivered to MTP3).  Also, if they are
living in the RB, an acknowledgement should have been sent for them (otherwise
the implementation is delaying acks, which it must not).

> What do you mean by "sent"?  Sent to SCTP or marked for acknowledgment?

Do you understand?  Sending acks immediately is necessary.  What "immediately"
means in terms of time intervals should be very short and is of course
dependent on processor scheduling and queueing within the driver or within
M2PA, however, the implementation must initiate acknowledgement and send such
acknowledgement at the next available opportunity.

By "sent" I mean that the implementation has initiated acknowledgement and
such acknowledgment MUST NOT be delayed as above.

>  Even a 30B message in MTP2 would take about 4ms in propagation time.

Don't introduce any delay.  M2PA will likely be held to ATM or Annex A
performance requirements (not 56kb/s links), unless maybe you were
intending on running your M2PA links over PPP on a dialup ;)

> >with a protocol tester or observed by a peer.

You see the real problem I have with this statement is that, even for
Q.703, there can be MSUs that are in a receive buffer that have been
not been "Sent to MTP3", but have been "accepted for" MTP3, where
"accepted for" means that they have been acknowledged or an acknowledgement
has been initiated that cannot or will not be retracted.

The Q.704 statement says "accepted from", which really implies that
MTP3 will not accept any further messages from MTP2.  This is really
problematic if you view the RB in MTP2.

The queueing model for MTP2/MTP3 deviates from the OSI/ISO queueing
model.  (You don't see it mentioned in the MTP2/MTP3 specifications
because the MTP2/MTP3 work predated OSI/ISO.)  The MTP model is as
follows:

            |                          |
            |          MTP3            |
            |                          |
            |__________________________|
                  |             ^       
                  |             |       
                  |             |       
                  |             |       
                  |             |       
                  |             |       
             _____V_____________|______ 
            |  |     |       |     |   |
            |  | TB  | MTP2  | RB  |   |
            |  |_____|       |_____|   |
            |                          |
            |                          |

Consider the Clear_Buffers and Flush_Buffers signals in the SDLs actually
clear the RB.

Now, when MTP2 acknowledges a message and places it in the RB, it
had better deliver it to MTP3 (or from the MTP3 perspective, MTP3
had better accept it) otherwise messages will be acknolwedged that
will be lost on changeover.  That is what I mean by MTP2 knows that
the message is "deliverable".  I.e, on link failure MTP3 will indeed
read the contents of the RB.

If MTP2 waits for delivery of the message to MTP3 before acknowledging
it, that had better be immediate.  Otherwise, MTP2 should invoke receive
congestion (i.e., Send SIB or LSB) to let the peer know that it is delaying
acknowledgements.  (Oh, by the way, many operators forbid sending SIB
even at 1 Erlang of traffic).

> piece of M2PA functionality better than the proposed alternative.

See Q.782 3.1.  This test requires no message loss, missequencing or
duplication.  So when M2PA serves up a BSNT it better not include
messages that have--and this is important--or will be delivered to MTP3.
BSNT cannot be for a message not yet sent by the peer and cannot be
for a message previous to the last message acknowledged to the peer
(otherwise the "Unreasonable BSNT" protocol error of Q.704 will result).

> don't see the test you've proposed as an adequate one.

Many operators have requirements more stringent that Q.781/782.  For Q.703
if you place a BSNT/FSNC in the COO that was not the last ack emitted as an
acknolwedgement on the link you might fail acceptance tests.  The same
rigor could be applied to M2PA.

> is performing it function correctly; if it doesn't then it is flawed.

Actually, there is a third way to state it.  Directly from the SDLs and
Tom's analysis of them.  BSNT is FSNX-1.  FSNX is the expected FSN (the
FSN of the next new MSU).  Therefore, according to the Q.703 SDLs, the
BSNT value is the FSN of the last new MSU (DATA) received.  This is
verifiable on the wire.

We could say that the BSNT is the FSN of the last valid DATA message
(it doesn't have to be new data for M2PA because data is not retransmitted
on the same association) received by M2PA.  This is the message that
M2PA should acknowledge without delay, and this is the message that is
last delivered to MTP3 (meaning that MTP3 MUST read the entire RB).

> the M2PA layer never passed a single message to MTP3.

The above paragraph is testable.  The BSNT is the FSN of the last
valid message received by M2PA before the link was put out of service.
It does not rely on ferry-clipping MTP3.

> the interface is interpreted.

That's ferry clip testing.  It is not considered valid by network operators.

> the COO correctly reflects the messsages received by the tester at the 

Q.782 3.1.  Some operators are more stringent than this, particularly
for STPs.

> probability of detecting issues, but does require you to test the MTP3 

Let's say its the FSN of the last valid data message received by M2PA
before the link was put out of service.  Then it can be tested without
ferry clip.  I send some DATA messages, then send LS OOS, then send COO
and if COA does not have the FSN of the last received message as a FSNC
then the implementation is in error.

Otherwise, the implementation will be filling the RTB at the sender causing
problems with congestion based on TB/RTB occupancy, losing an unnecessary
number of messages on time-controlled changeover (which some implementations
always do), etc.

> this piece of M2PA functionality better than the proposed alternative.

Consider my third alternative.

--brian

---

From: Tom George <[email-masked]>
Date: Tue, 11 Mar 2003 14:47:12 -0600

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.

---

From: Andrew Booth <[email-masked]>
Date: Tue, 11 Mar 2003 16:08:16 -0500

Tom,

Sounds good to me. :)

Andrew

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Mar 2003 00:40:48 -0700

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:

 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)