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

From: [email-masked]
Date: Thu, 27 Mar 2003 18:59:51 +0530

Brian,

In my draft till now i have not specified anything about sending SCON message
from SGP when it suffers congestion due to increasing receive buffer occupancy
it may not happen but cant be ignored . In SS7 network MTP2 layer below MTP3
takes care of situation when receive buffer occupancy of the link exceeds the
engineered buffer occupancy for expected load. MTP2 sends Busy signals to the
transmitting peer as mentioned in sections 9.1, 9.3. Point is that if the same
situation exists at SGP receiving the traffic from ASP you have to indicate the
generator of traffic to decrease the flow. How can that be accomplished. Also
SCON send from ASP when it is experiencing local congestion is not indicating
SS7 network congestion. Why can't we send SCON message in the reverse direction
when SGP experiences local congestion, i guess this will not fool MTP3 users at
the ASP but make sure that congestion doesn't get worse.

Regards
Kamesh

"Brian F. G. Bidulock" <[email-masked]> on 03/26/2003 07:48:41 PM

Please respond to [email-masked]

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

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

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)
>
>
> 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

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Mar 2003 15:37:18 -0700

kakaul,

[email-masked] wrote:                                                           (Thu, 27 Mar 2003 18:59:51)
> the ASP but make sure that congestion doesn't get worse.

You cannot use SCON because SCON is used for SS7 congestion in *both*
directions.

What is the point of sending a message?  In SCTP receive buffer occupancy
always translates to transmit buffer occupancy at the peer, so both sides know
what is happening.  There is no message that needs to be sent.

--brian

---

From: ksrinivas <[email-masked]>
Date: Fri, 28 Mar 2003 11:01:08 +0530

Brian,

See my comments below.

--Srini

> what is happening.  There is no message that needs to be sent.

Similarly, receive buffer occupancy at ASP will be translated to transmit buffer occupancy at the SGP. So IMO even
ASP does not have to send the SCON.

---

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

ksrinivas,

ksrinivas wrote:                                                                 (Fri, 28 Mar 2003 11:01:08)

[snip]
> Similarly, receive buffer occupancy at ASP will be translated to transmit
> buffer occupancy at the SGP. So IMO even ASP does not have to send the SCON.
> 

SCON sent by the ASP is not intended to signal SCTP buffer occupancy.  It is
intended to handle the Q.704/11.2.6 case of SS7 signalling network congestion.

--brian

---

From: kamesh kaul <[email-masked]>
Date: Sat, 29 Mar 2003 05:53:50 -0800 (PST)

Brian,
See the comments in line.
Regards
Kamesh
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> ksrinivas wrote:                                    
>                             (Fri, 28 Mar 2003
> 11:01:08)

[Kamesh]Section 11.2.6 of Q.704 says that detection of
congestion onset and abatement in a signalling point
or signalling transfer point should, if required be
implementation dependent.Any resulting action taken,
and messages and primitives sent, should align with
those procedures, messages 
and primitives specified for signalling route set
congestion.So the point is that if some implementation
wants to take action at SGP when its receive buffer
occupancy touches onset threshold it should be
provided flexibility and allowed to send SCON to ASP.
> --brian

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 29 Mar 2003 12:32:40 -0700

kamesh,

kamesh kaul wrote:                                                                  (Sat, 29 Mar 2003 05:53:50)
> provided flexibility and allowed to send SCON to ASP.

Right concept; wrong direction.  Q.704/11.2.6 is why
the ASP "MAY" send SCON to the SGP.

--brian

---

From: kamesh kaul <[email-masked]>
Date: Sat, 29 Mar 2003 18:09:06 -0800 (PST)

Brian,
      I am not convinced see the comments in line.
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> kamesh kaul wrote:                                  
>                                (Sat, 29 Mar 2003
> 05:53:50)
> > > > > You cannot use SCON because SCON is used for
> SS7
> > > congestion in *both*
> > > > > directions.
> > > > >
> > > > > What is the point of sending a message?  In
> SCTP
> > > receive buffer occupancy
> > > > > always translates to transmit buffer
> occupancy
> > > at the peer, so both sides know
> > > > Similarly, receive buffer occupancy at ASP
> will be
> > > translated to transmit
> > > > buffer occupancy at the SGP. So IMO even ASP
> does
> > > not have to send the SCON.
> > > > 
> > > 
> > > SCON sent by the ASP is not intended to signal
> SCTP
> > > buffer occupancy.  It is
> [Kamesh]In SS7 Signalling transfer point generates
TFC in response to the incoming message(by changing
OPC in the message to DPC), if it finds that outgoing
link on which the message is supposed to be routed is
suffering congestion and that congestion is somehow
derived from two factors:
1) If the current transmit buffers occupancy of the
link on which the message is supposed to be send
exceeds the expected engeenered load.
2) If receiving MTP2 peer determines that its current
receiving buffer occupancy of the link exceeds the
expected engeenering load. MTP2 sends BUSY message in
accordance with sections  9.1 , 9.2, 9.3 of Q.703.So
MTP2 below MTP3 informs the peer MTP2 of receive
buffer limitation which results in congestion
indication being given to MTP3 of the sending end.The
point i am trying to make is that in SCTP as there is
no such procedure defined receiving SGP has to inform
sending ASP of congestion due to receive buffer limit
at SGP.I am fully aware that it is MTP3/MTP3 user in
IP domain.But if receive buffers are reaching there
limit it has to be immidiately informed to sending end
so that correct action can be taken immidately before
situation gets worst.We can make sending SCON from SGP
due to receive congestion as OPTIONAL so that some
implementations can be provided flexibility.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 30 Mar 2003 03:19:47 -0700

kamesh,

I'm not trying to convince you.  Quite the opposite, I think that it
is you that need to do the convincing.

Please see comments below.

kamesh kaul wrote:                             (Sat, 29 Mar 2003 18:09:06)

[snip]

> [Kamesh]In SS7 Signalling transfer point generates TFC in response to
> the incoming message(by changing OPC in the message to DPC), if it
> finds that outgoing link on which the message is supposed to be routed
> is suffering congestion and that congestion is somehow derived from
> two factors:

> 1) If the current transmit buffers occupancy of the link on which the
> message is supposed to be send exceeds the expected engeenered load.

And this is what an SG will do: but for transmit congestion towards the
SS7 network, and then it will send SCON to AS just as it would send
MTP-STATUS to MTP-Users.

> 2) If receiving MTP2 peer determines that its current receiving buffer
> occupancy of the link exceeds the expected engeenering load. MTP2
> sends BUSY message in accordance with sections  9.1 , 9.2, 9.3 of
> Q.703.

It's clear you did not read (or understand) the note in 9.1, section 9.2
and the note in section 9.4.  Sending SIB neither causes transmit
congestion, nor does it cause any TFC to be launched.  SIB just extends
the period of time that is permitted for acknowledgement.

> So MTP2 below MTP3 informs the peer MTP2 of receive buffer limitation
> which results in congestion indication being given to MTP3 of the
> sending end.

That is simply not true.  Read the note in 9.1, section 9.2 and the note
in 9.4.

The receive congestion procedure in SS7 in intended to handle very
temporary receive congestion situations in specific implementations that
would otherwise fail the link due to excessive delay of acknowledgement.
It has nothing to do with receive buffer occupancy and does not
translate to transmit buffer occupancy at the other end of the link.
The receiver can continue to acknowledge messages, SIB is just a warning
to the sender that acknowledgements might be delayed beyond T7.

Implementations that send SIB, even when receiving 1 Erlang of traffic,
will have a hard time finding their way into an SS7 network.

> The point i am trying to make is that in SCTP as there is
> no such procedure defined receiving SGP has to inform sending ASP of
> congestion due to receive buffer limit at SGP.

There is no such procedure in SS7.

> I am fully aware that it is MTP3/MTP3 user in IP domain.  But if
> receive buffers are reaching there limit it has to be immidiately
> informed to sending end so that correct action can be taken immidately
> before situation gets worst.  We can make sending SCON from SGP due to
> receive congestion as OPTIONAL so that some implementations can be
> provided flexibility.

What bad thing do you think will happen?

If the SG is acting as an STP, the SG implementation is welcome to send
TFC to the SS7 network based on SCTP transmit congestion, if it would
like, based on Q.703/11.2.6, but no recommendations whatsoever should be
made in this regard: it is completely at the discretion of the SG and
does not require interoperability with the ASP.

Also, normal MTP-Users have a fairly balanced load.  The AS at the ASP
will normally be experiencing transmit congestion at about the same
time.  The MTP-User is welcome to use MTP-User controls (ISUP ACL, SCCP
SSC) to limit the traffic which is sent to it, it is even welcome to
send SCON to the SG.

If you set your SCTP protocol parameters appropriately and use
mechanisms such as SCTP lifetimes, the association will ABORT long
before congestion gets out of hand.  Then the SG will properly return
UPU(inaccessible) to the originators of traffic (or even TFP if the SG
is acting as an STP) and remote MTP-Users will take appropriate actions.

Signalling TFC to the SS7 network, or MTP-STATUS(cong) to an MTP-User
based on SCTP's exponential back-off congestion algorithms would be
extremely foolish.  Sending either in response to transient IP network
conditions could severely disrupt grade of service at remote signalling
points as well as at the AS.

Translating M3UA events into SS7 congestion indications, whether they be
TFC (sent to SS7 network) or MTP-STATUS(cong) (sent to local users) is
completely implementation dependent, depends on national and
international variant, and must not be specified.  The SG determines the
status of the SPMC, solely at its discretion, using whatever information
it has at its disposal (including SCON sent from ASP to SGP), and only
the SG determines when to send TFC to the SS7 network.  SCON sent from
SG to ASP is an indication of MTP-STATUS(cong) and is sent solely at the
discretion of the implementation at the SG.

That's the way it sits in the RFC, and you have presented no compelling
reason to change it.

--brian

---

From: kamesh kaul <[email-masked]>
Date: Sun, 30 Mar 2003 03:22:21 -0800 (PST)

Brian,

wrote:
> TFC in response to
[Kamesh]What will be the affect of not sending
acknowledgements for some time ,as far as i understand
at high data rate it will result 
in increase of transmit buffer occupancy at the
sending MTP2 and thus immidately will result in the
transmit congestion at the sending side.
That is why receive congestion immediately leads to
transmit congestion
in SS7.

> points as well as at the AS.
[Kamesh]But sending SCON from ASP to SGP is also based
on receive buffer limits at the ASP, although it is
OPTIONAL but it is there.
Nodal TFC from SG to SS7 network can also be triggered
by transmit buffer limits at SG itself why do we need
M3UA SCON message for it.
If this is allowed OPTIONALLY i dont see any reason
why SGP can't do the same OPTIONALLY. Please do give
explicit reasons for not doing it. 

> That's the way it sits in the RFC, and you have
> presented no compelling  reason to change it.
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 30 Mar 2003 05:44:56 -0700

kamesh,

kamesh kaul wrote:                                                                  (Sun, 30 Mar 2003 03:22:21)

[snip]
> > 
> > It's clear you did not read (or understand) the note in 9.1, section
> > 9.2 and the note in section 9.4.  Sending SIB neither causes
> > transmit congestion, nor does it cause any TFC to be launched.  SIB
> > just extends the period of time that is permitted for
> > acknowledgement.
> > 
> [Kamesh]What will be the affect of not sending acknowledgements for
> some time ,as far as i understand at high data rate it will result in
> increase of transmit buffer occupancy at the sending MTP2 and thus
> immidately will result in the transmit congestion at the sending side.
> That is why receive congestion immediately leads to transmit
> congestion in SS7.

Sending SIB does not mean that messages will not be acknowledged:

  Section 9.1:

  NOTE -- The receiving end continues to process BSN and BIB carried
  in signal units received in order to avoid, as far as possible,
  disturbance of the message flow in the opposite direction and in
  addition may continue to accept message signal units.

[snip]
> > If the SG is acting as an STP, the SG implementation is welcome to
> > send TFC to the SS7 network based on SCTP transmit congestion, if it
> > would like, based on Q.703/11.2.6, but no recommendations whatsoever
> > should be made in this regard: it is completely at the discretion of
> > the SG and does not require interoperability with the ASP.
> > 
> > Also, normal MTP-Users have a fairly balanced load.  The AS at the
> > ASP will normally be experiencing transmit congestion at about the
> > same time.  The MTP-User is welcome to use MTP-User controls (ISUP
> > ACL, SCCP SSC) to limit the traffic which is sent to it, it is even
> > welcome to send SCON to the SG.
> > 
> > before congestion gets out of hand.  Then the SG will properly
> > return UPU(inaccessible) to the originators of traffic (or even TFP
> > if the SG is acting as an STP) and remote MTP-Users will take
> > appropriate actions.
> > 
> > Signalling TFC to the SS7 network, or MTP-STATUS(cong) to an
> > MTP-User based on SCTP's exponential back-off congestion algorithms
> > would be extremely foolish.  Sending either in response to transient
> > IP network conditions could severely disrupt grade of service at
> > remote signalling points as well as at the AS.
> > 
> [Kamesh]But sending SCON from ASP to SGP is also based on receive
> buffer limits at the ASP, although it is OPTIONAL but it is there.
> Nodal TFC from SG to SS7 network can also be triggered by transmit
> buffer limits at SG itself why do we need M3UA SCON message for it.

Nobody said anything about receive buffer limits.  ANSI-T1.111.4-2000
says that Q.704/11.2.6 TFC is sent only due to congestion of the SMH
(Signalling Message Handling) functions (and primarily HMRT not HMDT).
So it is only Q.704/11.2.6 (ITU-T/ETSI variants) where it would even
be considered to send SCON.  Q.704/11.2.6 says nothing about receive
buffer limits.  It says:

  11.2.6  Signalling point/signalling transfer point congestion

  The detection of congestion onset and abatement in a signalling point
  or signalling transfer point should, if required, be implementation
  dependent.  Any resulting action taken, and messages and primitive
  sent, should align with those procedures, messages and primitives
  specified for signalling route set congestion.

In fitting with this, SCON (MTP-STATUS(cong) primitive equivalent) is
sent from SG to ASP to inform MTP-Users at the AS of routeset congestion.
To permit Q.704/11.2.6 in the case of SP congestion (ASPs can't be STPs)
where there are multiple SG acting as STPs, the ASP "MAY" send SCON to
the SG.  What the SG does with that SCON in fitting with management of
the SPMC status to the SS7 network is at the discretion of the SG
implementation.

> If this is allowed OPTIONALLY i dont see any reason why SGP can't do
> the same OPTIONALLY.

The SGP sending SCON is not OPTIONAL.  However, when the SGP sends
SCON is up to the MTP implementation and the NIF.

> Please do give explicit reasons for not doing it. 

I think the oweness is on you to give explicit reasons for doing so.

--brian

---

From: kamesh kaul <[email-masked]>
Date: Sun, 30 Mar 2003 06:39:56 -0800 (PST)

Brian,
      Some comments in line.
wrote:
>                                (Sun, 30 Mar 2003
> 03:22:21)
> acknowledgements for
[Kamesh]What is the point in sending SCON to the SG
here.Transmit congestion is due to MTP3 users above
M3UA at ASP.

> > > if the SG is acting as an STP) and remote
[Kamesh]This is true when traffic is send from SGP to
ASP that is fine what if direction of traffic is
reversed.
> be considered to send SCON.  Q.704/11.2.6 says
[Kamesh]In one of your earlier mails you agreed that
receive buffer limit triggers SCON from ASP to SGP. I
am attaching the lines 
[Joes question]You did not answer my question
explicitly.  Can you give me an example of the
implementation in which the ASP would send
SCON for a reason other than the congestion of the
read/write buffer used between the ASP and SGP?
[Your response]Yes; internal buffer capacity or other
resource limitations at the ASP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 30 Mar 2003 14:42:39 -0700

kamesh,

kamesh kaul wrote:                                                                  (Sun, 30 Mar 2003 06:39:56)
> > > > Also, normal MTP-Users have a fairly balanced load.  The AS at
> > > > the ASP will normally be experiencing transmit congestion at
> > > > about the same time.  The MTP-User is welcome to use MTP-User
> > > > controls (ISUP ACL, SCCP SSC) to limit the traffic which is sent
> > > > to it, it is even welcome to send SCON to the SG.
> > > > 
> [Kamesh]What is the point in sending SCON to the SG here.Transmit
> congestion is due to MTP3 users above M3UA at ASP.

Q.704/11.2.6 does not specify what will trigger nodal TFC.  M3UA
cannot specify what will trigger ASP->SGP SCON.

> > > > mechanisms such as SCTP lifetimes, the association will ABORT
> > > > long before congestion gets out of hand.  Then the SG will
> > > > properly return UPU(inaccessible) to the originators of traffic
> > > > (or even TFP if the SG is acting as an STP) and remote MTP-Users
> > > > will take appropriate actions.
> > > > 
> [Kamesh]This is true when traffic is send from SGP to ASP that is fine
> what if direction of traffic is reversed.

SCTP is a peer to peer protocol.  Once an association is established,
it functions identical in both directions.  It makes no difference
whether the SG aborts the association or whether the ASP aborts the
association.  The result is the same.

> > > > MTP-User based on SCTP's exponential back-off congestion
> > > > algorithms would be extremely foolish.  Sending either in
> > > > response to transient IP network conditions could severely
> > > > disrupt grade of service at remote signalling points as well as
> > > > at the AS.
> > > > 
> > Nobody said anything about receive buffer limits.
> > ANSI-T1.111.4-2000 says that Q.704/11.2.6 TFC is sent only due to
> > congestion of the SMH (Signalling Message Handling) functions (and
> > primarily HMRT not HMDT).  So it is only Q.704/11.2.6 (ITU-T/ETSI
> > variants) where it would even be considered to send SCON.
> > Q.704/11.2.6 says nothing about receive buffer limits.  It says:
> [Kamesh]In one of your earlier mails you agreed that receive buffer
> limit triggers SCON from ASP to SGP. I am attaching the lines

> [Joes question]You did not answer my question explicitly.  Can you
> give me an example of the implementation in which the ASP would send
> SCON for a reason other than the congestion of the read/write buffer
> used between the ASP and SGP?

> [Your response]Yes; internal buffer capacity or other resource
> limitations at the ASP.

Kamesh, if you're going to quote my own statements back at me, you
should at least read them first: I said nothing about receive buffers.
I was refering (as Joe requested) to buffers other than read/write
buffers.

I think that it would be particularly absurd to send SCON from ASP->SGP
based on receive buffer occupancy, but the RFC does not preclude an
implementation from doing so.  Nevertheless, the RFC does not require an
SGP to respond in any way to a received SCON so the matter is moot.

Because you can present no reasons nor basis in SS7 network practice
for the procedures you escrie in your congestion proposal, IMO your
proposal has no merit and should not be considered further.

--brian