Subject: Re: [Sigtran] M2PA - Flush Buffers

From: Tom George <[email-masked]>
Date: Tue, 27 Aug 2002 18:04:23 -0500

Anshoo,

I finally got around to this one. Comments below.

On Fri, 12 Jul 2002 [email-masked] wrote:
> 
> Hi,
> 
> Draft v5 M2PA says that
> 
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 4.2.4  Flush Buffers, Continue
> 
> The Flush Buffers and Continue commands allow M2PA to resume normal
> operations (i.e., transmission of messages to SCTP and receiving
> messages from SCTP) after a processor outage (local and/or remote)
> ceases.
> 
> If M2PA receives a Flush Buffers command from MTP3, M2PA:
> 
>    (a) shall not transmit any messages to SCTP that are currently
>        waiting to be transmitted to SCTP. These messages shall be
>        discarded.
> 
>    (b) shall discard all messages currently waiting to be passed
>        to MTP3.
> 
> If M2PA receives either a Flush Buffers or Continue command from MTP3,
> and the processor outage condition ceases, M2PA shall resume receiving
> and transmitting messages.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 
> What would be the scenario in which clause (a) would find its use?
> Is M2PA expected to buffer Data for some reason before giving it to SCTP.

This is an implementation matter. If for whatever reason someone is
buffering messages in their M2PA, those messages should be discarded. If
you don't ever buffer them in M2PA then "any messages" is the null set. 

> 
> Moreover, the flush procedure in MTP2 flushes the RTB and TB buffers for the
> Link.
> Should M2PA also not flush the buffers in SCTP Tx Queue.
> Or else M2PA should abort the SCTP Association and setup a new association.
> Otherwise, SCTP would continue transmitting/retransmitting the MSUs even after
> the Flush Buffers API has been invoked by MTP3. This would not be in conformance
>  with
> MTP2 procedures.
  [...]

Unfortunately, SCTP does not provide a mechanism for the upper layer to
tell it to flush its transmit queue. 

In an earlier version of the draft, M2PA would abort the association and
set up a new association under various conditions. I was persuaded to
change that so that the association remained up when possible. This has
the advantage of allowing investigation of an association in case the
link fails. 

I think (b) helps somewhat on this issue. The messages may get
transmitted, but they get discarded at the other end. 

If anyone has an improvement, I am open to suggestions.

tomG. 

-- 
* Tom George          972-519-3168           [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* 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: [email-masked]
Date: Thu, 29 Aug 2002 10:45:17 +0530

Hi Tom,

Better late than never... :) Please see comments.

Regards
Anshoo.

----- Original Message -----
From: "Tom George" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 28, 2002 4:34 AM
Subject: Re: [Sigtran] M2PA - Flush Buffers

> transmitted, but they get discarded at the other end.

The other end will not be able to identify as to which messages are to be
discareded and which ones are to be accepted.
So at the time Flush Buffer is invoked, all messages present in SCTP Transmit
Queue and Retransmit Queue would still be given to MTP3 at the remote end.
IMO this can be prevented only in two ways:
1) SCTP supports the Flushing of RTB and TB which would require a change in SCTP
 Interface as well as the Protocol itself.
2) The other option would be that M2PA closes the SCTP Association and
re-establishes it.
Since the change in SCTP doesn't seem possible, dropping the association should
be the best option.

> If anyone has an improvement, I am open to suggestions.

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.