Subject: Re: [Sigtran] Re: M3UA Congestion Procedures

From: [email-masked]
Date: Wed, 26 Mar 2003 19:00:25 +0530

Srini
   You don't have to inform the receive buffer occupancy at M3UA SGP to NIF.
SCON from SGP will be send on received data message if M3UA at SGP is
experiencing  local receive congestion.So when SCON with say congestion level 3
reaches ASP, congestion status of affected pointcode gets updated and congestion
timer will be used to supervise the congestion status of affected point
code.When ASP side sends DAUD for the affected point code to SGP, ASP will
receive DAVA message back from SGP since congestion is local to SGP.Now when
congestion timer expires without receiving any SCON message from peer SGP , ASP
will decrement the congestion status of the affected point code till congestion
status of affected point code reaches 0 i.e congestion abatement of affected
point code and mtp3 users can be notified of change in congestion status.
Regards
Kamesh
Hughes Software system

ksrinivas <[email-masked]> on 03/26/2003 03:42:50 PM

To:   Kamesh Kaul/HSS@HSS
cc:   [email-masked]

Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures

Kamesh,

  Suppose that the ASP has received the SCON message from the M3UA of SGP in
response to a Data message sent due to receive buffer occupancy at SGP. The M3UA
at
ASP may initiate the DAUD procedures. If the M3UA at SGP receives the DAUD
message,
the M3UA informs the arrival of DAUD message to NIF/MTP3 (as suggested by you to
avoid the redundancy ...). The status of the destination maintained at the
NIF/MTP3
will be returned back to the M3UA of SGP through the MTP-STATUS primitive.

The status of the destination at NIF/MTP3 may not reflect the proper congestion
status if the NIF/MTP3 was not informed about receive buffer occupancy while
sending
the first SCON message to ASP.

So, Do we have to inform the receive buffer occupancy at M3UA of SGP for the
particular destination to NIF/MTP3 while sending the first SCON message to ASP?.

--Srini

[email-masked] wrote:

> Srini
> If after sending SCON message to ASP (once), no data message is received on
the
> congested association (involving SGP and ASP) and local(receive) congestion at
> M3UA SGP changes (due to decreasing receive buffer occupancy) peer ASP can use
> congestion timer to supervise the congestion reported to ASP by SCON message
> received once.Yes I will add Generation of SCON message subsection in section
3
> of the draft.
>
> Regards
> Kamesh
> Hughes Software Systems
>
> ksrinivas <[email-masked]> on 03/26/2003 02:34:19 PM
>
> To:   Kamesh Kaul/HSS@HSS
> cc:   [email-masked]
>
> Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures
>
> Kamesh,
>
> How does the M3UA at ASP or SGP inform the change in the receive buffer
> occupancy(later after sending the SCON once) with the peer?.
>
> --Srini
>
> [email-masked] wrote:
>
> > Srini
> > Yes you are right the point is not clearly mentioned. I will add few lines
in
> > section 3.1 of the draft to make it clear in the next release.M3UA at ASP
> > handles the incoming SCON message as any other SCON message.
> >
> > Regards
> > Kamesh
> > Hughes Software System
> >
> > ksrinivas <[email-masked]> on 03/26/2003 02:17:42 PM
> >
> > To:   Kamesh Kaul/HSS@HSS
> > cc:   [email-masked]
> >
> > Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures
> >
> > Kamesh,
> >
> >    So if receive buffers are occupied M3UA at SGP should respond with the
SCON
> > message. This
> > point is not made clear in your congestion procedure draft.
> >
> > >> It can send SCON message whenever data message is received from ASP
> > corresponding
> > to the
> > >> congested association with affected point code being the destination
point
> > code
> > in the received
> > >> data message.
> >
> > So the ASs served by that ASP do not generate traffic to that particular
> > destination
> > only. Am I right?.
> >
> > How does the M3UA at ASP or SGP inform the change in the receive buffer
> > occupancy
> > with the
> > peer?.
> >
> > --Srini
> >
> > [email-masked] wrote:
> >
> > > Srini
> > > When M3UA at SGP determines that it is suffering local congestion (due to
> > > current receive buffer occupancy). It can send SCON message whenever data
> > > message is received from ASP corresponding to the congested association
with
> > > affected point code being the destination point code in the received data
> > > message.Basically the point is that M3UA at SGP is congested by traffic
from
> > the
> > > ASP, so you have to indicate the sender of traffic that i am not able to
> > handle
> > > more data from you that is why it is appropriate to send SCON message to
> > > generator of traffic so that it can take some immediate action before
> > situation
> > > gets worst.
> > >
> > > Regards
> > > Kamesh
> > > Hughes Software Systems
> > >
> > > ksrinivas <[email-masked]> on 03/26/2003 12:48:59 PM
> > >
> > > To:   Kamesh Kaul/HSS@HSS
> > > cc:   [email-masked]
> > >
> > > Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures
> > >
> > > Kamesh,
> > >
> > >     Can you please tell me what action has to be taken when an M3UA at SGP
> > > determines that the receive buffer congestion is encountered?.
> > >
> > > --Srini
> > >
> > > [email-masked] wrote:
> > >
> > > > Srini
> > > > If an SG has only one SGP, then congestion status of affected SPMC can
be
> > > > maintained at M3UA (SGP) and any change in the congestion status can be
> > > reported
> > > > to NIF. But in case SG is configured to have more than one SGP's
> cumulative
> > > > congestion status of affected SPMC has to be maintained at the
> interworking
> > > > function some were above M3UA at SGP , it may require some inter SGP
> > > > communication and totally depends on implementer implementing the SG.
> > > >
> > > > Regards
> > > > Kamesh
> > > > Hughes Software Systems
> > > >
> > > > ksrinivas <[email-masked]> on 03/26/2003 09:58:25 AM
> > > >
> > > > To:   Kamesh Kaul/HSS@HSS
> > > > cc:   [email-masked]
> > > >
> > > > Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures
> > > >
> > > > Kamesh,
> > > >
> > > > In section 3.2.2 of "draft-kamesh-m3ua-congestion-procedures-00.txt",
the
> > > > follwoing
> > > > text is provided:
> > > >
> > > > .....M3UA at SGP may update the change in congestion status of affected
> SPMC
> > > > configured at SGP......
> > > >
> > > > Since you have said may, does that mean, maintaining the congestion
status
> > of
> > > > affected SPMC at M3UA of SGP is implementation dependent?.
> > > >
> > > > --Srini
> > > >
> > > > [email-masked] wrote:
> > > >
> > > > > Srini
> > > > > Interface between M3UA (at SGP) and NIF is not standardized  so it is
> > > > basically
> > > > > implementation dependent, and nice implementation would not like to
keep
> > > > > redundant point code status information both at MTP3 and M3UA, that is
> why
> > i
> > > > > have not mentioned it in my draft.But no doubt flexibility should be
> > > provided
> > > > > for all implementations, I can add a point on that in the next release
> of
> > > the
> > > > > draft.
> > > > > Regards
> > > > > Kamesh
> > > > > Hughes Software Systems
> > > > >
> > > > > ksrinivas <[email-masked]> on 03/21/2003 05:31:59
PM
> > > > >
> > > > > To:   Kamesh Kaul/HSS@HSS
> > > > > cc:   [email-masked]
> > > > >
> > > > > Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures
> > > > >
> > > > > Kamesh,
> > > > >
> > > > >     So IMO, M3UA at SGP should maintain the status of the destination
> > point
> > > > > codes.
> > > > >
> > > > > --Srini
> > > > >
> > > > > [email-masked] wrote:
> > > > >
> > > > > > Srini
> > > > > >  In M3UA RFC no such primitive is given
> > > > > >
> > > > > > ksrinivas <[email-masked]> on 03/21/2003
05:07:10
> PM
> > > > > >
> > > > > > To:   Kamesh Kaul/HSS@HSS
> > > > > > cc:   [email-masked]
> > > > > >
> > > > > > Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures
> > > > > >
> > > > > > Kamesh,
> > > > > >
> > > > > >   Is there any primitive defined by the M3UA RFC for informing NIF
of
> > the
> > > > > > arrival of
> > > > > > DAUD message in order to get the status of the destination point
> code?.
> > > > > >
> > > > > > --Srini
> > > > > >
> > > > > > [email-masked] wrote:
> > > > > >
> > > > > > > Srini
> > > > > > >
> > > > > > > In this case also MTP3 and NIF coordinating together will respond
to
> > > audit
> > > > > > > request by indicating M3UA at SGP with appropriate mtp3 pause if
> point
> > > > code
> > > > > > > status is down,mtp3 resume if point code status is UP and mtp3
> status
> > if
> > > > > point
> > > > > > > code status is restricted or congested . M3UA in turn sends
> > > corresponding
> > > > > > > DUNA,DAVA,SCON and DRST to concerned AS list.
> > > > > > >
> > > > > > > Regards
> > > > > > > Kamesh
> > > > > > > Hughus Software Systems
> > > > > > >
> > > > > > > ksrinivas <[email-masked]> on 03/21/2003
> 04:25:17
> > PM
> > > > > > >
> > > > > > > To:   Kamesh Kaul/HSS@HSS
> > > > > > > cc:   [email-masked]
> > > > > > >
> > > > > > > Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures
> > > > > > >
> > > > > > > Kamesh,
> > > > > > >
> > > > > > > [email-masked] wrote:
> > > > > > >
> > > > > > > > Srini
> > > > > > > >
> > > > > > > > M3UA at SGP on receiving DATA message from ASP for congested DPC
> > > > notifies
> > > > > > NIF
> > > > > > > > with mtp3 transfer primitive. As point code status is maintained
> by
> > > MTP3
> > > > > > layer
> > > > > > > > so it will be redundant for M3UA at SGP to maintain point code
> > status.
> > > > > > >
> > > > > > > If the M3UA at SGP is not maintaining the point code status, How
> will
> > it
> > > > > > respond
> > > > > > > to
> > > > > > > the DAUD message.
> > > > > > >
> > > > > > > --Srini
> > > > > > >
> > > > > > > > It will
> > > > > > > > be the responsibility of MTP3 and NIF combined to give mtp3
status
> > > > > > indication
> > > > > > > to
> > > > > > > > M3UA with cause point code congested on receiving data message
for
> > > > > congested
> > > > > > > > pointcode.M3UA in turn on receiving mtp3 status indication from
> NIF
> > > > sends
> > > > > an
> > > > > > > > SCON message to concerned AS( ASP's serving it) list. It is
> covered
> > in
> > > > the
> > > > > > > draft
> > > > > > > > from this perspective in example section 4.1, as handling of
mtp3
> > > status
> > > > > > > > primitive at SGP is clearly mentioned in RFC 3332 (sec 1.4.3.2)
.
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > Kamesh
> > > > > > > > Hughus Software Systems
> > > > > > > >
> > > > > > > > ksrinivas <[email-masked]> on 03/21/2003
> > 02:49:51
> > > PM
> > > > > > > >
> > > > > > > > To:   Kamesh Kaul/HSS@HSS
> > > > > > > > cc:   [email-masked]
> > > > > > > >
> > > > > > > > Subject:  M3UA Congestion Procedures
> > > > > > > >
> > > > > > > > Kamesh,
> > > > > > > >
> > > > > > > >     Section 3.4.4 of RFC 3332 says:
> > > > > > > >
> > > > > > > > "The SCON message can be sent from an SGP to all concerned ASPs
to
> > > > > > > > indicate that an SG has determined that there is congestion in
the
> > SS7
> > > > > > > > network to one or more destinations, or to an ASP in response to
a
> > > DATA
> > > > > > > > or DAUD message as appropriate." ...
> > > > > > > >
> > > > > > > > But your "draft-kamesh-m3ua-congestion-procedures-00.txt" does
not
> > > talk
> > > > > > > > about SGP sending a SCON message in response to a Data Message
> > > received
> > > > > > > > from ASP. Why?.
> > > > > > > >
> > > > > > > > --Srini
> > > > > > > >
> > > > > > > >
> > > > ------------------------------------------------------------------------
> > > > > > > >                   Name: att1.htm
> > > > > > > >    att1.htm       Type: Hypertext Markup Language (text/html)
> > > > > > > >               Encoding: base64
> > > > > > > >            Description: Internet HTML
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > > >
------------------------------------------------------------------------
> > > >                   Name: att1.htm
> > > >    att1.htm       Type: Hypertext Markup Language (text/html)
> > > >               Encoding: base64
> > > >            Description: Internet HTML
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >   ------------------------------------------------------------------------
> >                   Name: att1.htm
> >    att1.htm       Type: Hypertext Markup Language (text/html)
> >               Encoding: base64
> >            Description: Internet HTML
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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

---

From: ksrinivas <[email-masked]>
Date: Thu, 27 Mar 2003 17:40:30 +0530

Brian,

   In M3UA RFC, section 1.4.2.4, the following text is provided

.....The list of ASPs in an AS is assumed to be dynamic, taking into
   account the availability, traffic handling capability and congestion
   status of the individual ASPs in the list, as well as configuration
   changes and possible failover mechanisms......

Suppose the SGP has received the MTP3-User message from the SS7 network. The SGP
determines the correct AS using the distribution function. Now when it has to select
the ASP, should it look at the congestion status of the individual ASP(as suggested
by the above text) apart from Up/Down/Active/Inactive?. If so, Congestion status at
SGP should be maintained based on the ASP. I do not think what the RFC says is
proper. IMO, the congestion status should be maintained based on the AS/SPMC.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Mar 2003 15:41:19 -0700

ksrinivas,

ksrinivas wrote:                                                                 (Thu, 27 Mar 2003 17:40:30)
>    Suppose  the  SGP  has  received  the  MTP3-User  message from the SS7
>    network.  The  SGP  determines  the  correct AS using the distribution
>    function.  Now  when  it  has to select the ASP, should it look at the
>    congestion  status  of  the  individual  ASP(as suggested by the above
>    text) apart from Up/Down/Active/Inactive?. If so, Congestion status at
>    SGP should be maintained based on the ASP. I do not think what the RFC
>    says  is proper. IMO, the congestion status should be maintained based
>    on the AS/SPMC.

Read the next paragraph in the RFC.

--brian

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

---

From: ksrinivas <[email-masked]>
Date: Fri, 28 Mar 2003 09:42:52 +0530

Brian,

In M3UA RFC section 1.6.3, the following text is provided:

M-RK_REG indication
   Direction: M3UA -> LM
   Purpose: M3UA informs LM that it has successfully processed an incoming REG REQ message.

In the above text, Does the term "processed" implies, M3UA of SGP should maintain the Routing Key table. If YES,
the list of ASPs corresponding to the AS(RK) should also be maintained at the M3UA of SGP. In other words, the
congestion status of ASPs should be maintained at M3UA of SGP itself. My questions are:

Why the M3UA is forced to maintain the congestion status?.
Why we have to maintain the congestion status per ASP(as per the text in section 1.4.2.4)?.

See also the comments below

--Srini

> Read the next paragraph in the RFC.

The next paragraph does not talk about congestion.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 28 Mar 2003 01:39:44 -0700

ksrinivas,

ksrinivas wrote:                                                                 (Fri, 28 Mar 2003 09:42:52)
>    In  the  above  text,  Does  the term "processed" implies, M3UA of SGP
>    should  maintain  the  Routing  Key  table.  If  YES, the list of ASPs
>    corresponding  to  the AS(RK) should also be maintained at the M3UA of
>    SGP.  In  other  words,  the  congestion  status  of  ASPs  should  be
>    maintained at M3UA of SGP itself. My questions are:
> 

Section 1.4.2.4 does not require maintaining congestion status of ASPs.

[snip]
>    The next paragraph does not talk about congestion.

Precisely.  ASP are chosen on the basis of whether or not they are ASP-ACTIVE
for the AS and congestion has nothing to do with it.

--brian

---

From: ksrinivas <[email-masked]>
Date: Fri, 28 Mar 2003 15:19:14 +0530

Brian,

> for the AS and congestion has nothing to do with it.

IMO, the congestion mentioned in the following paragraph of section 1.4.2.4 implies congestion status has to be
maintained per ASP?.

The list of ASPs in an AS is assumed to be dynamic, taking into account the availability, traffic handling
capability and congestion status of the individual ASPs in the list, as well as configuration changes and
possible failover mechanisms.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 28 Mar 2003 03:39:10 -0700

ksrinivas,

ksrinivas wrote:                                (Fri, 28 Mar 2003 15:19:14)

> 
>    IMO,  the  congestion  mentioned in the following paragraph of section
>    1.4.2.4 implies congestion status has to be maintained per ASP?.
> 
>    The  list  of  ASPs  in  an  AS  is assumed to be dynamic, taking into
>    changes and possible failover mechanisms.

There are no RFC keywords in this sentence.  It places no requirements on
the implementation.  In fact the last 5 paragraphs in section 1.4.2.4 are
only for illustration.

I suggest you read past the overview.  In particuar, read section 4.1.1:

" 4.1.1 Receipt of Primitives from the M3UA-User
" 
"    On receiving an MTP-TRANSFER request primitive from an upper layer at
"    an ASP/IPSP, or the nodal interworking function at an SGP, the M3UA
"    layer sends a corresponding DATA message (see Section 3) to its M3UA
"    peer.  The M3UA peer receiving the DATA message sends an MTP-TRANSFER
"    indication primitive to the upper layer.
" 
"    The M3UA message distribution function (see Section 1.4.2.1)
"    determines the Application Server (AS) based on comparing the
"    information in the MTP-TRANSFER request primitive with a provisioned
"    Routing Key.
" 
"    From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE
"    state is selected and a DATA message is constructed and issued on the
"    corresponding SCTP association.  If more than one ASP is in the ASP-
"    ACTIVE state (i.e., traffic is to be loadshared across more than one
"    ASP), one of the ASPs in the ASP-ACTIVE state is selected from the
"    list.  If the ASPs are in Broadcast Mode, all active ASPs will be
"    selected and the message sent to each of the active ASPs.  The
"    selection algorithm is implementation dependent but could, for
"    example, be round robin or based on the SLS or ISUP CIC.  The
"    appropriate selection algorithm must be chosen carefully as it is
"    dependent on application assumptions and understanding of the degree
"    of state coordination between the ASP-ACTIVE ASPs in the AS.
" 
"    In addition, the message needs to be sent on the appropriate SCTP
"    stream, again taking care to meet the message sequencing needs of the
"    signalling application. DATA messages MUST be sent on an SCTP stream
"    other than stream '0'.
" 
"    When there is no Routing Key match, or only a partial match, for an
"    incoming SS7 message, a default treatment MAY be specified.  Possible
"    solutions are to provide a default Application Server at the SGP that
"    directs all unallocated traffic to a (set of) default ASP(s), or to
"    drop the message and provide a notification to Layer Management in an
"    M-ERROR indication primitive.  The treatment of unallocated traffic
"    is implementation dependent.

Do you see anything that talks about congestion used as a basis for
selecting an ASP in section 4.1.1?

--brian