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

From: [email-masked]
Date: Wed, 26 Mar 2003 14:20:45 +0530

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

---

From: ksrinivas <[email-masked]>
Date: Wed, 26 Mar 2003 14:34:19 +0530

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

---

From: ksrinivas <[email-masked]>
Date: Wed, 26 Mar 2003 14:39:45 +0530

Kamesh,

   I think you need to add a sub-section "Generation of SCON messages" in section 3
also.

--Srini