Subject: [Sigtran] data receved ahen asp is in inactive state

From: "Nahar,virendra" <[email-masked]>
Date: Wed, 17 Jul 2002 01:07:07 +0530

Hi

what should be done in m3ua if data is received when ASP is in state INACIVE or
INACTIVE_SENT.
1. Should the data be droped & Error UnExpected message be sent to SG.
2 Just silently drop the data .
which one of the above is correct
Thanks
Nahar

--
Virendra Nahar
HCL-Technologies Ltd
Networking Technology Lab
HCL Technologies Ltd.,
Ground Floor, Block - 1, Chandamama Building,
184 to 188,190,192 & 196, NSK Road,
Vadapalani, Chennai - 600 026
Phone office      : +91-44-3728366 extn - 1129
Fax               : +91-44-4806640
mailto:[email-masked]
PUTT' LAW
" TECHNOLOGY is dominated by two types of people
1.Those who unserstand what they do not manage !
2.Those who manage what they do not understand !
############################################################
"He who has a why for life can put with any how."
                             Frederick Nietzsche
############################################################

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 16 Jul 2002 16:08:02 -0400

Nahar,

Just silent discard. BTW, there is no state defined as ASP-INACTIVE-SENT in
the draft.

  Tolga
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Nahar,virendra
> Sent: Tuesday, July 16, 2002 3:37 PM
> To: Sigtran
> Subject: [Sigtran] data receved ahen asp is in inactive state
>
>
> Hi
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Jul 2002 19:57:04 -0600

Nahar,

I differ.  As the ASP is attempting to deactivate the traffic
flow when it has just sent ASP-INACTIVE, it should continue
processing received DATA, if possible, until it receives an ASP
Inactive Ack from the SG.  If the ASP receives DATA after
receiving ASP Inactive Ack from the SG, I would think that it
would depend upon which stream the ASP Inactive Ack is received
with respect to the DATA.  If, as is permitted, ASP Inactive Ack
is sent on the same stream as the received DATA, then the SG has
obviously sent the DATA aftern the inactive ack and the ASP is
fully within its rights either to send unexpected message or to
drop the data or both.  If ASP Inactive Ack was sent on stream
'0' (as is permitted), then it may have jumped ahead of some
DATA and the ASP should process the DATA if possible.  This is
why I preferred to have ASP Inactive/Ack sent on the same stream
as the DATA, but this is not always possible in M3UA because
DATA can be sent on multiple streams whereas ASP Inactive/Ack
can only be sent on one stream (be it one of the DATA streams or
stream '0').

A procedure which can avoid these kinds of difficulties (DATA
delayed behind Inactive Ack) using the BEAT message is possible.
Some procedures are described in draft-bidulock-sigtran-corid-00.txt

In a BEAT procedure, upon receiving an ASP Inactive from the ASP
the SG can send BEAT on all DATA streams and receive BEAT Ack
before sending ASP Inactive Ack.  This would ensure that no DATA
is delayed behind the ASP Inactive Ack resulting in DATA loss.

In general, discarding DATA for no good reason is a bad idea
when transporting SS7.

--brian

Nahar,virendra wrote:                              (Wed, 17 Jul 2002 01:07:07)
> Fax: +91-44-4806640

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 17 Jul 2002 09:54:35 -0400

Brian,

If BEAT procedure is not implemented, I would not send ERROR and just
silently discard DATA (and would rely on upper layers for any problems,
which might arise because of ASPIA-ACK jumps ahead of DATA), because in such
a case, for each DATA received an ERROR will be generated without much
meaning. It might be a good idea, after receiving ASPIA-ACK to start a timer
and when it expires to drop the association assuming that something is wrong
with the SGP. Although not with RFC keywords, silently dropping DATA in this
case is mentioned in the draft in the paragraph explaning "Unexpected
Message" error code on page59.

If BEAT procedure is implemented -which I think is usefull-, after receiving
ASPIA-ACK, if ASP receives DATA , I think association might be dropped
immediately.

   Tolga

> Sent: Tuesday, July 16, 2002 9:57 PM
> To: Nahar,virendra
> Cc: Sigtran
> Subject: Re: [Sigtran] data receved ahen asp is in inactive state
>
>
> Nahar,
>

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 17 Jul 2002 10:03:12 -0400

Small clarification below.

  Tolga
> Tolga Asveren
> Sent: Wednesday, July 17, 2002 9:55 AM
> To: [email-masked]
> Subject: RE: [Sigtran] data receved ahen asp is in inactive state
>
>
> Brian,
>
> with the SGP. Although not with RFC keywords, silently dropping
[TOLGA] When timer expires and still DATA is received for the inactivated
AS, then association might be dropped, assuming SGP can't route properly.
> DATA in this

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Jul 2002 18:01:28 -0600

Tolga,

I wouldn't drop the association.  That is a little drastic IMO.  Particularly
when there may be other AS traffic flows that have no problems associated
with them...

--brian

Tolga Asveren wrote:                                           (Wed, 17 Jul 2002 09:54:35)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 17 Jul 2002 20:39:15 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 17, 2002 8:01 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] My point is, if SGP can't route properly, then it also might be
better not to waste time with discarding messages from it (and assuming that
it has some serious problem and most probably can't route properly also for
other AS). But if the problem is specific for routing to a particular AS,
then this is not a good idea. Afterall I think this is another
implementation decision, rather than being part of the protocol.
But IMO not sending ERROR for DATA received in Inactive state might be
stated with some RFC keywords (perhaps SHOULD NOT), because ERROR messages
in such a case would not have too much meaning (SGP already knows that ASP
is in INACTIVE state for this AS) and will just make the network and ASP/SGP
busy.
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Brian F. G. Bidulock

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Jul 2002 18:59:15 -0600

Tolga,

How will it make the network more busy.  Each message in SS7 normally
has a response message.  If a message is dropped and an ERR returned
there will be no significant increase in traffic in comparison to if
the message were to tbe processed.  If messages are silently dropped
and the upper layer is left to retransmit, it will: this could
significantly (double, triple) the amount of traffic in the forward
direction.  I cannot subscribe to either silent discard (for that
reason), nor can I subscribe to dropping associations (because it is
too drastic a measure for SS7 networks).

--brian

Tolga Asveren wrote:                                           (Wed, 17 Jul 2002 20:39:15)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 18 Jul 2002 09:13:41 -0400

Brian,

> Sent: Wednesday, July 17, 2002 8:59 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] As I stated earlier, I would consider dropping association an
implementation issue. There might be cases where it makes sense and cases
where it does not make sense, but in general personally I would consider a
SGP, which can't route properly in trouble.
IMO, sending or not sending ERR won't change behavior of the upper layer.
The important thing is whether those messages are passed to upper layer or
not. Now when I think for a redundant system, sending ERR seems to have a
benefit. If ASP receives DATA and won't or can't pass it to upper layer, SGP
can try to route the message to another ASP (assuming that DATA is present
in the Diagnostic field of ERR). But if something is really wrong with SGP,
then it might try to route those messages again to the same ASP, hence
dropping association might make sense, otherwise we might find ourselves in
a loop.
So, IMO if ERR is going to be used to reroute the message, it might be
usefull, otherwise it won't help for anyhting and just for every DATA
received in INACTIVE state an ERR will be generated, creating additional
overload.

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Jul 2002 08:25:17 -0400

Brian,

(I replied to this before, but my reply might be lost, so just resending
with minor additions)

[TOLGA] As I stated earlier, I would consider dropping association an
implementation issue. There might be cases where it makes sense and cases
where it does not make sense, but in general personally I would consider a
SGP, which can't route properly in trouble.
IMO, sending or not sending ERR won't change behavior of the upper layer.
The important thing is whether those messages are passed to upper layer or
not. Now when I think for a redundant system, sending ERR seems to have a
benefit. If ASP receives DATA and won't or can't pass it to upper layer, SGP
can try to route the message to another ASP (assuming that DATA is present
in the Diagnostic field of ERR). But if something is really wrong with SGP,
then it might try to route those messages again to the same ASP, hence
dropping association might make sense, otherwise we might find ourselves in
a loop.
For example, if BEAT procedure is implemented, I think after it is in
INACTIVE state, it is better for the ASP not to send ERR, and even to drop
the association, if it receives more DATA for the corresponding AS, because
ASP is sure that SGP should know that ASP is in INACTIVE state before
sending this DATA, and that SGP can't route properly. If BEAT procedure is
not implemented, there is a period, where ASP can't be sure whether the
received DATA is sent before or after SGP sent ASPIA-ACK. During that time,
ASP might send ERR so that SGP can reroute the message.
So, IMO if ERR is going to be used to reroute the message, it might be
usefull, otherwise it won't help for anyhting and just for every DATA
received in INACTIVE state an ERR will be generated, creating additional
overload.