Subject: Re: [Sigtran] Re: M2PA Clarification

From: [email-masked]
Date: Tue, 28 May 2002 13:25:52 -0400

Hello Brian,

Interesting. I am trying to better understand the implications of a
M2PA that does not stop transmitting when informed of a busy peer.
Here's follows a stream of thoughts. I'd appreciate comments if I've got
anything wrong.

If a node continues transmitting after receiving LSB, then that means
the busy peer (or transport layer) must buffer un-ack'd messages until
the busy condition clears. When the busy condition clears, the no-longer-busy
node sends LSBE and then begins unbuffering and ack'ing the inbound
back-log. This buffering can be implemented at either the M2PA or SCTP
levels. If implemented at SCTP (e.g. no association receives during busy),
then this closes the receive window, causing the sender to begin backing-up.

The point in communicating busy status to the peer  is so that the peer
can start T6. It continues to transmit at a rate that the busy node will not
(currently) accept, and so its retransmit queue backs-up (instead of its
to-be-transmitted queue, when Tx is stopped). If T6 expires, then the node
knows that it was congestion at the peer, and not a problem at the transport
protocol layer or network.

If the busy condition is transitory, then this scheme (not stopping Tx)
eliminates the delay imposed by the wait for busy-ended status and the time
to send the buffered messages. Reduced delay improves the chance for recovery.

If the busy condition is not transitory, then the sender may experience
outbound congestion with T6 running (depending on traffic, buffering capacity,
and timer value). The link will eventually go down, either due to T6 expiry or
MTP3,  and a lot of traffic will have been sent and discarded, only to be
retrieved and rerouted upon change-over. This situation would be rare in
properly engineered networks.

This prompts another thought:
    Since the link can go down and then restart with the association remaining
    established, there can potentially be a large quantity of stale data
    sitting in the association send/receive buffers. M2PA will need to deal
    with the stale data in RETRIEVAL/OOS state.

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]> on 05/28/2002 10:03:05 AM

Please respond to [email-masked]

To:   [email-masked]
cc:   [email-masked]
Subject:  Re: [Sigtran] Re: M2PA Clarification

Jeffrey,

One expects recovery (not failure) from busy.  As a result, sending on data
is not only efficient but reduces delay.

--brian

[email-masked] wrote:                    (Tue, 28 May 2002
08:34:32)
>
> Hello Brian,
>
> A M2PA link may be using shared network resources.  Does it make sense to
> send
> traffic to the peer when the peer must throw it away (not acknowledge
it)?
>
> I agree that the draft need not require that transmit traffic be stopped
> when the peer
> is busy, but continuing to transmit in this situation is an inefficient
use
> of the IP network.
>
> Regards,
>
> Jeff
>
>
>
>
>
> "Brian F. G. Bidulock" <[email-masked]>@ietf.org on 05/24/2002
> 04:56:22 PM
>
> Please respond to [email-masked]
>
> Sent by:  [email-masked]
>
>
> To:   [email-masked]
> cc:   [email-masked], [email-masked]
> Subject:  [Sigtran] Re: M2PA Clarification
>
>
> Anshoo,
>
> You bring up a good point.  Now that there are sequence numbers
> for acknowledging MSUs, there is no longer a need for the sending
> M2PA to withold messages from SCTP.  It should just not expect
> an acknowledgement (BSN) from the other side corresponding to these
> messages during T6, just as in normal SS7 link operation.  Unacknowledged
> messages would then be held at the sending M2PA and be available for
> retrieval under changeover at MTP3.
>
> This previous text was only a workaround for the lack of an M2PA level
> acknowledgment, which is not available using FSN/BSN.
>
> I propose that the related text be updated to reflect normal SS7 link
> operation in this regard.
>
> --brian
>
> [email-masked] wrote:                            (Fri, 24 May 2002
> 18:12:55)
> >
> >
> >
> > Hi Brian/Tom...
> >
> > Can you please clarify the following doubt...
> >
> > >From M2PA Draft 5
> >
> > Section 4.1.5
> >  "The peer M2PA shall cease transmitting messages to SCTP while its
> >   T6 timer is running, i.e., while the other end is Busy."
> >
> > This implies that once T6 Timer is started by M2PA, the data that
> > received from Local MTP3 must be buffered by M2PA till the time either
it
> > receives a Busy End from Peer or T6 Expires.
> > If T6 expires, without receiving a Busy End from Peer M2PA, it  should
> > discard all the of the above buffers and mark the Link Out of Service.
> > Or else, if it receives Busy End from Peer while T6 is running, it
> dispatches
> > all the buffered Messages to the Peer.
> >
> > Is this understanding correct....
> > Can there be some supporting text in the Draft?
> >
> > Thanks and Regards
> > Anshoo.
> >
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: <[email-masked]>
> > Sent: Wednesday, May 22, 2002 7:40 PM
> > Subject: [Sigtran] M2PA Clarification
> >
> >
> > >
> > > Hi,
> > >
> > > Please clarify the following text from the Draft.
> > >
> > > 4.1.5 Level 2 Flow Control
> > >
> > > "The peer M2PA shall cease transmitting messages to SCTP while its
> > > T6 timer is running, i.e., while the other end is Busy."
> > >
> > > Does the above statement imply that M2PA should buffer the new data
> from MTP3
> > > Layer when T6 Timer is running or can M2PA reject all new Data.
> > >
> > > Thanks
> > > Anshoo.
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > DISCLAIMER: This message is proprietary to Hughes Software Systems
> > Limited (HSS) and is intended solely for the use of the individual
> > to whom it is addressed. It may contain  privileged or confidential
> > information  and should not be circulated or used for any purpose other
> > than for what it is intended. If you have received this message in
error,
> > please notify the originator immediately. If you are not the intended
> > recipient, you are notified that you are strictly prohibited from
using,
> > copying, altering, or disclosing the contents of this message. HSS
> accepts
> > no responsibility for loss or damage arising from the use of the
> information
> > transmitted by this email including damage from virus.
> >
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>
> _______________________________________________
> 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 May 2002 13:19:23 -0500

Jeffrey,

Yes.

--brian

[email-masked] wrote:                    (Tue, 28 May 2002 13:25:52)

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