Re: DATA msg in response to ASP-INACTIVE msg - accept or discard it?

Ambika,

Well, it is worse than that.  If the SGP sends the ASP Inactive Ack on a
stream other than the stream on which data is sent, or if data is sent to the
ASP on more than one stream for the AS, the ASP Inactive Ack could overtake
the DATA.  The ASP may then see DATA _after_ ASP Inactive Ack.

The SGP can avoid this by using the procedures in
draft-bidulock-sigtran-corid-05.txt which provide for withholding data (from
the NIF as you say) then sending BEAT messages on each of the DATA streams for
the AS and receiving a response to each BEAT before responding with ASP
Inactive Ack.  An alternate procedure would be to stop data from the NIF,
start a timer set to say, the SRTT currently experienced by SCTP, and wait
until the timer expires before sending ASP Inactive Ack.

The same problem occurs in the reverse direction.  If the ASP sends ASP
Inactive on a stream other than the stream on which data is sent, or if data
is sent to the SGP on more than one stream for the AS, the ASP Inactive could
overtake the DATA.  The SGP may then see DATA _after_ ASP Inactive.

The ASP too can avoid this by using the procedures in
draft-bidulock-sigtran-corid-05.txt

But, yes, the ASP should process DATA received between sending ASP Inactive
and receiving ASP Inactive Ack if it is able.  In fact it should process DATA
received after receiving ASP Inactive Ack if it is able.

The same is true for the SGP, it should process DATA received after receiving
ASP Inactive if it is able.  If at least the SGP uses the procedures of
draft-bidulock-sigtran-corid-05.txt half the problem in both directions can be
avoided.

--brian


Ambika Tripathy wrote:                                 (Thu, 19 Apr 2007 16:20:24)
> 
>    Hi ,
> 
> 
> 
>       My understanding is when ASP send ASp-INACTIVE The state of the ASP
>    should   not  changed  to  Inactive  and  it  should able  to  process
>    incoming data  message  from  SGP  till  SGP  respond ASP-INACTIVE-ACK
>    message.  After  receiving  the ASP-INACTIVE-ACK from SGP the ASP will
>    change the state to inactive.
> 
> 
> 
>      SGP                 ASP
> 
>    --------------------------
> 
>       <----ASPINACTIVE-------
> 
>    <If  there  is  some  data  to send from SGP to ASP, SG should process
>    those  before  sending  ASPINACTIVEACK. And Should not accept any data
>    from NIF after receiving ASPINACTIVE>
> 
>       ----ASPINACTIVEACK--->
> 
>                          state changed to INACTIVE at SGP for the ASP
> 
> 
> 
>    --
>    Br,
>    Ambika Prasad Tripathy
>    Nethawk Networks
>    Cell: +91-94375 47730
> 
> 
> 
>    On 4/19/07, Ilie Glib <[1][email protected]> wrote:
> 
>      Hello Mahantesh,
>      I assume you refer to M3UA. I think that in case the ASP is still
>      capable of processing the message (it depends on the state of the
>      application),  it  shall  accept  it.  IMHO  it  is  implementation
>      dependent,
>      in majority of cases the application is not able to process and
>      incoming message when it has requested the inactive state.
>      /Ilie
>      On 4/19/07, Mahantesh <[2][email protected]> wrote:
>      > Hi there,
>      >
>      > My query is,
>      >
>      >  When ASP-INACTIVE message is sent form ASP to SGP, the state ASP
>      will be
>      > INACTIVE?
>      >   OR,   it  will  be  in  ACTIVE  until  an  ASP-INACTIVE-ACK  is
>      received  from SGP.
>      >
>      > Before the receipt of ASP-INACTIVE-ACK is a DATA message from SGP
>      is sent to
>      > ASP, What ASP should do? accept or Discard the DATA message.
>      >
>      >
>      > -^-
>      > Rgds,
>      > Mahantesh
>      > "Silence is a source of great strength"
>      > _______________________________________________
>      > Sigtran mailing list
>      > [3][email protected]
>      > [4]https://www1.ietf.org/mailman/listinfo/sigtran
>      >
>      >
>      --
>      Ilie
>      _______________________________________________
>      Sigtran mailing list
>      [5][email protected]
>      [6]https://www1.ietf.org/mailman/listinfo/sigtran
> 
> References
> 
>    1. mailto:[email protected]
>    2. mailto:[email protected]
>    3. mailto:[email protected]
>    4. https://www1.ietf.org/mailman/listinfo/sigtran
>    5. mailto:[email protected]
>    6. https://www1.ietf.org/mailman/listinfo/sigtran

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


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