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

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

Selvam
  You need not differentiate the SCON from normal SCON. Ultimately aim is to
regulate traffic from ASP(AS) to SGP, traffic from SGP to ASP(AS) should not be
disturbed, by sending ASP Inactive ack bidirectional traffic for the AS will be
stopped, this is not what we are trying to achieve.

Regards
Kamesh
Hughes Software Systems

"Selvam.V" <[email-masked]> on 03/26/2003 03:40:45 PM

To:   Kamesh Kaul/HSS@HSS, "ksrinivas" <[email-masked]>
cc:   [email-masked]

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

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

>
>
> 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: "Selvam.V" <[email-masked]>
Date: Wed, 26 Mar 2003 20:21:40 +0530

kamesh,
              if there are two ASP's serving for an AS ( ASP1, ASP2).
              They are operating in Load Shared mode. 
              if the association towards ASP1 is congested, can  the traffic 
              be diverted to ASP2.

             Is there will be any use, only if the traffic is allowed b/w SGP to ASP.

             Thanks & Regards,

             selva.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 29 Mar 2003 01:50:33 -0700

Selvam.V,

Selvam.V wrote:                                                                   (Wed, 26 Mar 2003 20:21:40)
>    if  the  association towards ASP1 is congested, can  the traffic be
>    diverted to ASP2.
> 

Redirecting traffic between ASPs in a load-shared AS based on SCTP congestion
would be spectacularly foolish.  Mis-sequencing of messages would be almost
guaranteed.

--brian

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

---

From: "Selvam.V" <[email-masked]>
Date: Sat, 29 Mar 2003 16:16:59 +0530

Brian,
           Does the same thing is applicable when the ASP goes DOWN/
           INACTIVE.
                               or
           when the ASP becomes ACTIVE

           Thanks & Regards,

           selva.

----- Original Message -----
From: Brian F. G. Bidulock <[email-masked]>
To: Selvam.V <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, March 29, 2003 2:20 PM
Subject: Re: [Sigtran] Re: M3UA Congestion Procedures

> >    Is  there  will  be  any  use,  only  if  the traffic is allowed b/w
SGP
> >    to ASP.

---

From: "Selvam.V" <[email-masked]>
Date: Sat, 29 Mar 2003 16:31:05 +0530

Brian,

1.3.2.4 Support for the Management of SCTP Associations between the SGP
        and ASPs.

   The M3UA layer at the SGP maintains the availability state of all
   configured remote ASPs, to manage the SCTP Associations and the
   traffic between the M3UA peers.  As well, the active/inactive and
   congestion state of remote ASPs is maintained.

  This section talks about maintaining congestion state of remote ASPs.
  This status is only for deriving SPMC congestion status ?.

  Thanks & Regards,

  selva.

----- Original Message -----
From: Brian F. G. Bidulock <[email-masked]>
To: Selvam.V <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, March 29, 2003 2:20 PM
Subject: Re: [Sigtran] Re: M3UA Congestion Procedures

SGP

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 29 Mar 2003 04:31:25 -0700

Selvam.V,

For that case see draft-bidulock-sigtran-corid-01.txt

You can get a copy here:

    ftp://ftp.ietf.org/internet-drafts/draft-bidulock-sigtran-corid-01.txt

--brian

Selvam.V wrote:                                                                   (Sat, 29 Mar 2003 16:16:59)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 29 Mar 2003 04:45:58 -0700

Selvam.V,

Selvam.V wrote:                                                                   (Sat, 29 Mar 2003 16:31:05)
>   This status is only for deriving SPMC congestion status ?.

Not even that.  This status is for reporting to local management using
the OPTIONAL M-ASP_STATUS primitive.  Yet, you will find no mention of
congestion in the M3UA MIB and no action is ever required (or even
described) in response to "ASP congestion".

--brian

---

From: "B.Sasidhar Reddy" <[email-masked]>
Date: Mon, 31 Mar 2003 11:01:54 +0530

Brian,

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Selvam.V" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, March 29, 2003 5:15 PM
Subject: Re: [Sigtran] Re: M3UA Congestion Procedures

> described) in response to "ASP congestion".

    Insection 1.4.2.4

     "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."

Isn't it required to maintain the congestion status to select the dynamic
list of ASPs.

--Sasidhar

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 30 Mar 2003 22:31:46 -0700

B.Sasidhar,

No is it not required.

--brian

B.Sasidhar Reddy wrote:                                                         (Mon, 31 Mar 2003 11:01:54)

---

From: ksrinivas <[email-masked]>
Date: Mon, 31 Mar 2003 11:21:29 +0530

Brian,

Section 1.3.2.4 of M3UA RFC says, we have to maintain the Congestion status for all ASPs at M3UA of SGP

and

Section 1.4.2.4 of M3UA RFC says, based on the Congestion status also, the dynamic list of ASPs are to be
determined

Since we do not have to look at the Congestion status of ASPs for the selection of an ASP from the AS. Is not
the Section 1.4.2.4 misleading?.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 31 Mar 2003 00:55:34 -0700

ksrinivas,

ksrinivas wrote:                               (Mon, 31 Mar 2003 11:21:29)
> status for all ASPs at M3UA of SGP

There is no requirement to maintain congestion status of ASPs.
Management of SCTP associations is OPTIONAL and implementation
dependent.  Congestion state is not represented in the MIB.
If your management function requires it, you are welcome to
maintain it, but the RFC does not require that it be maintained.

> 
> and
> 
> Section 1.4.2.4 of M3UA RFC says, based on the Congestion status also,
> the dynamic list of ASPs are to be determined

Read again starting at paragraph two:

  "To support this message distribution, the SGP MIGHT, FOR EXAMPLE, ...

The only requirement is in paragraph one:

   "To direct messages received from the SS7 MTP3 network to the
    appropriate IP destination, the SGP MUST perform a message
    distribution function using information from the received MTP3-User
    message."

The rest of the section is an example.

If the example confuses you so much, I suggest you ignore it.

> 
> Since we do not have to look at the Congestion status of ASPs for the
> selection of an ASP from the AS. Is not the Section 1.4.2.4
> misleading?.

No, it is not misleading.  Do not assume that because the SGP is
exemplified as considering congestion status that it is used in the
message-by-messages selection of an ASP within a Loadshare AS.
The RFC does not say that.  What the RFC does say is:

  "In the case of a Loadshare mode AS, reception of an ASP Active
   message at an SGP or IPSP causes the direction of trafic to the ASP
   sending the ASP Active message, in addition to all the other ASPs
   that are currently active in the AS.  The algorithm at the SGP for
   loadsharing traffic within an AS to all the active ASPs is
   implementation dependent.  The algorithm could, for example, be
   round-robin or based on information in the Data message (e.g., the
   SLS, SCCP SSN, ISUP CIC value)."

  (And I think we kicked out SCCP SSN and ISUP CIC).

The passage you have such a problem with says that "[t]he list of ASPs
in an AS is assumed to be dynamic", based on a list of things.  That
does not say that messages are routed on a message-by-message basis
to ASPs in a Loadshare AS based on congestion.  Section 4.3.4.3 above
makes it quite clear that the active state of an ASP in an AS is the
only thing that causes an ASP to receive traffic for an AS.  Which
traffic it receives when it becomes active can be resaonably based on
congestion status of the ASPs in the AS (i.e, in the dynamic list),
however, it is not required or even recommended that congestion status
of ASPs be considered.  The algorithm is "implementation dependent".

Quite differently, when the SGP is faced with redistributing load within
a loadshare AS (ASP has failed or ASP has become active), one of the
things that the SGP could reasonably consider when redistributing the
load is the congestion status of ASPs.  Redistribution of load should
give attention to mis-sequencing at the AS.  Rerouting messages based on
buffer occupancies is plain foolish.  If you want to do it that way in
spite of all arguments to the contrary, be my guest.  I hope you have
good professional liability insurance.  Just don't expect to convince
others to follow you over that cliff.

--brian