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

From: [email-masked]
Date: Wed, 26 Mar 2003 15:02:18 +0530

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

---

From: "Selvam.V" <[email-masked]>
Date: Wed, 26 Mar 2003 15:40:45 +0530

Kamesh,
               Does sending a SCON message for a particular ADPC, stops
traffic
               for all the destination towards that SG. How this SCON is
               differentiated from the normal SCON.

               I think we have to send ASP Inactive Ack to stop the traffic.

               Thanks & Regards,

               selva.

----- Original Message -----
From: <[email-masked]>
To: ksrinivas <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 26, 2003 3:02 PM
Subject: Re: [Sigtran] Re: M3UA Congestion Procedures

> > > > In section 3.2.2 of
"draft-kamesh-m3ua-congestion-procedures-00.txt", the
> > > > > ksrinivas <[email-masked]> on 03/21/2003
05:31:59 PM
> > > > > > ksrinivas <[email-masked]> on 03/21/2003
05:07:10

---

From: ksrinivas <[email-masked]>
Date: Wed, 26 Mar 2003 15:42:50 +0530

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Mar 2003 07:18:41 -0700

kakaul,

You are mistaking MTP/MTP-User interface implementation congestion for
SS7 network congestion.  SCON is only used for SS7 network congestion.

SCON should never be used to indicate SCTP receive buffer occupancy.
SCTP receive buffer occupancy will always translate to SCTP transmit
buffer occupancy at the peer and no M3UA message is necessary for the
sender to determine that the receiver is failing to service its
receive buffer in time.

SCON must be reserved for the indication of SS7 network congestion to
the MTP User in response to MTP-STATUS primitives from MTP.  M3UA at
an SG should never otherwise send SCON.

Please see "M3UA: Route-set congestion" thread from over a year ago.

--brian

[email-masked] wrote:                                                           (Wed, 26 Mar 2003 15:02:18)

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

---

From: ksrinivas <[email-masked]>
Date: Thu, 27 Mar 2003 15:37:52 +0530

Brian,

Please see my comments below

--Srini

> sender to determine that the receiver is failing to service its

Once the M3UA of ASP or SGP encounters the transmit buffer occupancy, Can you please suggest what actions the M3UA
can take?.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Mar 2003 03:28:25 -0700

ksrinivas,

ksrinivas wrote:                                                                 (Thu, 27 Mar 2003 15:37:52)
> Once the M3UA of ASP or SGP encounters the transmit buffer occupancy, Can
> you please suggest what actions the M3UA can take?.

Well that is largely implementation dependent, but an implementation could,
for example, take the same actions that you expected them to take in response
to the misguided SCON.

--brian

---

From: ksrinivas <[email-masked]>
Date: Thu, 27 Mar 2003 16:09:31 +0530

Brian,

> for example, take the same actions that you expected them to take in response

Do you mean to say that, What action the M3UA is supposed to take when an SCON message is received from the
peer, the same action may be taken?.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Mar 2003 04:14:08 -0700

ksrinivas,

ksrinivas wrote:                                    (Thu, 27 Mar 2003 16:09:31)
> Do you mean to say that, What action the M3UA is supposed to take when an
> SCON message is received from the peer, the same action may be taken?.

No, because SCON signals SS7 network congestion, not MTP-User
congestion.

MTP-user congestion is normally handled in SS7 by the upper-layer
protocol.  That is, if it is ISUP, the ISUP starts placing ACL in REL.
If it is SCCP, it uses SSC messages.  TFC and MTP-STATUS(cong) are used
for signalling SS7 network congestion.

A normal MTP-User implementation can always encounter write buffer
capacity limits when writing primitives to MTP.  MTP can always
encounter read buffer capacity limits when indicating primitives to the
MTP-User.  This is different and separate from SS7 network congestion.

How the MTP or MTP-User deals with this is up to the implementation as
it is a matter internal to the node and has no bearing on
interoperability.

To send MTP-STATUS(cong) to the MTP-User at the ASP on the basis of SCTP
buffer capacity, or to send TFC to the SS7 network on the basis of SCTP
buffer capacity: either would fool the MTP-User or SS7 network into
believing that SS7 network congestion exists where it does not.

MTP-STATUS or TFC so abused would largely destroy International
ITU-T/ETSI SS7 congestion algorithms where multiple congestion states
are not used.

This is why SCON is reserved for indicating SS7 network congestion and
not internal implementation dependent buffer capacities.

--brian