Subject: [Sigtran] M3UA IG-01 : SCON in response to DAUD

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 09:58:18 -0400

1- In M3UA-IG 01  3.9.2 , it is said that for ITU(International Network)
case congestion status of destinations is not kept. Per 3.8.4 this is not
true, congestion status of route sets is kept also for ITU(International)
networks, but updated only in case of link congestion, not with a received
TFC.

2- Why is SCON sent as response to DAUD? In MTP3 neither in MTP3 restart nor
as response to RSM, TFC is sent.

    Tolga

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 10:08:05 -0400

A correction:

3.8.4 ==> 3.8.4 of Q.704

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tolga Asveren
> Sent: Wednesday, September 04, 2002 9:58 AM
> To: [email-masked]
> Subject: [Sigtran] M3UA IG-01 : SCON in response to DAUD
>
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Sep 2002 08:44:21 -0600

Tolga,

Tolga Asveren wrote:                              (Wed, 04 Sep 2002 10:08:05)
> > networks, but updated only in case of link congestion, not with a received

Read the clause carefully: congestion status of destinations is not kept;
congestion status of linksets is kept.  Responding to a local user with
MTP-STATUS for a destination will depend upon the congestion status of
linksets and the linkset selected for a particular message at a particular
point in time.  This is not something that can be maintained per-destination.
If a sent message happens to encounter a congested link, the MTP-STATUS is
returned (also consider [n=8,16,24,32...] in clause 11).

For variants that perform the routeset congestion test proedure, there is
truly a congestion status associated with each destination at any given
point in time independent of the selected outgoing link.  That is certainly
not the case for ITU (International).

> >
> > 2- Why is SCON sent as response to DAUD? In MTP3 neither in MTP3 restart
> > nor as response to RSM, TFC is sent.

SCON and TFC are two different things.  SCON corresponds to an MTP-STATUS
primitive, not TFC.  DAUD audits the availability and congestion status (if
known) of the indicated destinations or all destinations.  When congestion
status is known, SCON is returned in response to DAUD.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 11:11:04 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 10:44 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] M3UA IG-01 : SCON in response to DAUD
>
>
> Tolga,
>
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Tolga Asveren
[TOLGA] Q.704 (07/96) 3.8.4 says:
"At each originating signalling point, there is associated with each
signalling route set a congestion status, which indicates the degree of
congestion in the signalling route set.
a) In the international signalling network, two states are provided,
congested and uncongested.

If a link in a signalling route towards a given destination becomes
congested, the congestion status of the signalling route set towards the
affected destination is changed to congested."
In my opinion based on that, it is quite clear that congestion status of
route sets is kept also for ITU international case.
> status is known, SCON is returned in response to DAUD.
[TOLGA] I think it is quite discussable what SCON really corresponds to.
When SG and AS share the same PC, I also would think that it corresponds to
MTP-STATUS primitive. But what about the case when SG and AS have different
PCs? In such a case, I would say, it corresponds to TFC (BTW, for a MTP3-UA
protocol, personally I find it odd, to have different point codes for SG and
AS, this is more like a PA behavior, but this case will probbaly be used
more)
Now, even for the case, where SCON corresponds to MTP-STATUS primitive, what
is the counterpart of DAUD in MTP3 in such a case? Such a primitive does not
exist.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Sep 2002 10:34:37 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 04 Sep 2002 11:11:04)
> route sets is kept also for ITU international case.

I disagree with that interpretation.  ITU International only needs to
know the congestion status of a routeset when it is in the process of
sending a message to L2 on behalf of a user so that it can respond
with an MTP-STATUS primitive if required per clause 11.  There is no
need (or requirement) to maintain any congestion status of routesets
between message transmissions.  In fact, to do so would be bad
engineering design.

> is the counterpart of DAUD in MTP3 in such a case? Such a primitive does not

DAUD corresponds to the MTP-RESTART-ENDS implementation dependent mechanism
referred to in the footnote in Q.701 Clause 8.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Sep 2002 10:51:13 -0600

Tolga,

> route sets is kept also for ITU international case.

Not in our (conforming) stack.  What state variables an implementation
keeps is its own business in SS7: as long as the external behavior
conforms.  The external behavior in this case is an MTP-STATUS primitive
in response to a MTP-TRANSFER primitive from a user.  There is no requirement
for an implementation to maintain any status whatsoever between MTP-TRANSFER
primitives.

Besides: I don' care.  The soon to be RFC is clear in section 4.5.3:

   "Where the SGP maintains the congestion status of the SS7 destination,
   and the SS7 destination is congested, the SGP MUST additionally respond
   with an SCON message before the DATA or DRST message."

The first part of that phrase expresses that an implementation may or may
not have congestion status available, regardless of variant.

> [TOLGA] I think it is quite discussable what SCON really corresponds to.

Read section 4.5.1 of the soon to be RFC.  It is clear that SCON corresponds
to MTP-STATUS.

> is the counterpart of DAUD in MTP3 in such a case? Such a primitive does not

Read Q.703 Clause 8.  MTP-RESTART-ENDS.

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 13:25:35 -0400

Brian,

> Sent: Wednesday, September 04, 2002 12:35 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] In the quoted section it is clearly said that congestion status of
the route set updated. I think, checking the status just of the link before
sending the message to L2 wouldn't be 100% inline with Q704, because when
one link in a signalling route is congested, status of the route set is
updated based on that. If we just check link status, depending on the link
we choose, status might be congested or not.
> referred to in the footnote in Q.701 Clause 8.
[TOLGA] My interpretation of Q.701 8.5 is, that it is an indication from
MTP3 to the MTP3 users. DAUD is sent from ASP to SGP. Furthermore, there is
also the question, how to interprete it when AS/SG have different PCs.

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 13:44:39 -0400

Brian,

> Sent: Wednesday, September 04, 2002 12:51 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] What variables to use is of course implementation decision, but even
for ITU international case, one has to keep congestion state for route sets.
Otherwise I don't see, how one can fully comply with Q.704.
> not have congestion status available, regardless of variant.
[TOLGA] I think for that one has to refer to the corresponding MTP3
specification. And in IG, why is it said explicitly that for ITU
international congestion state of route sets is not kept?
> Read section 4.5.1 of the soon to be RFC.  It is clear that SCON
[TOLGA] Even if one wants to see the interface between ASP/SGP always as
MTP3-MTP3 user interface, still I don't understand why SCON  should be sent
as response to DAUD. In MTP3 Restart MTP-STATUS is not sent. Why are we
trying to diverge from congestion schema of MTP3? It is clear that in MTP3,
MTP-STATUS/TFC is generated only as response to a received message to the
congested destination.
> Read Q.703 Clause 8.  MTP-RESTART-ENDS.
[TOLGA] I don't think DAUD corresponds what is said in Q.701 8.5. And
furthermore during MTP Restart no MTP-STATUS primitive is sent to user
parts.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Sep 2002 12:00:48 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 04 Sep 2002 13:25:35)
> we choose, status might be congested or not.

I'm sorry you are having so much difficulty with your new-found
discovery of SS7.  If you look at Figure 26/Q.704 sheet 5 of 5 you
will see that it is possible to check the direct linkset congestion
at the time that the mesage is being sent L3->L2.  When the link in
the direct linkset is selected, simply check whether the direct
linkset is congested and then also issue "Message for congested
destination" HMRT->TSFC.  No separate destination congestion status
separate from direct linkset congestion need be maintained.  (Unless
of course you are using HMCG, and then it is not the International
flavor.)

> > DAUD corresponds to the MTP-RESTART-ENDS implementation dependent
> > mechanism referred to in the footnote in Q.701 Clause 8.
> MTP3 to the MTP3 users.  DAUD is sent from ASP to SGP.

It says no such thing.  It does not specify any direction.  It is an
implementation dependent function.  DAUD was provided to accomodate
this.  There is also a reference in Q.700 in the definition of the
MTP-SAP concerning user parts which newly join/attach to an MTP-SAP.

> Furthermore, there is also the question, how to interprete it when
> AS/SG have different PCs.

All PC's are owned by the SG regardless of whether they are dedicated
to an AS or not.

We have been over these points many times.

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 14:34:24 -0400

Brian,

> Sent: Wednesday, September 04, 2002 2:01 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] I don't think my interpretation is wrong:
1- Specification itself has always precedence over SDL sheets in case of
conflict. 3.8.4 says cleary that in case of ITU international, when one link
is congested, corresponding route sets are put to congested status. Whether
you do it by keeping it a variable or by checking everytime relevant link
congestion status might be implementation dependent. But route set
congestion status concept exists for ITU international network. If one
checks just congestion status of a single link, before sending the message
to L2, this wouldn't be correct in my opinion.
2- I furthermore don't think Figure26(5 of 5) is inline with what you say,
just in opposite, it is what I say. The NOTE on the figure says "Dotted
symbols apply only to the multiple congestion states option. Delete hatched
symbols when using option" So, for ITU international case, one has to delete
dotted symbols (Message HMRT->HMCG) and to keep hatched symbols. So,
"Destination Congested" check is there.
> MTP-SAP concerning user parts which newly join/attach to an MTP-SAP.
[TOLGA] Q.701 8.5 says:
"When the MTP restart procedure is terminated, the MTP indicates the end of
the MTP restart to all local MTP Users showing each signalling point's
accesibility or inaccessibility. the means of doing this is implementation
dependent"
Based on that , it is quite clear to me that this indication should be sent
from MTP3 to MTP3 users.
> All PC's are owned by the SG regardless of whether they are dedicated
[TOLGA] That is fine. But in such a case, we should behaeve like MTP3-MTP3
user interface. During MTP3 restart no MTP-STATUS is sent. It is only sent
as response to a message destined to congested destination.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Sep 2002 12:36:18 -0600

Tolga,

Tolga Asveren wrote:                                (Wed, 04 Sep 2002 13:44:39)
> Otherwise I don't see, how one can fully comply with Q.704.

Look at Figure 26/Q.704 Sheet 5 of 5 and see if you can see the obvious
reduction.

> international congestion state of route sets is not kept?

Because keeping congestion states of routesets for ITU International
is inefficient and of no interest.  Regardless, I think the RFC is clear
in that when congestion states are kept they must be sent in SCON.

> > Read section 4.5.1 of the soon to be RFC.  It is clear that SCON
> > corresponds to MTP-STATUS.

Destination status is sent at MTP-RESTART-ENDS and not during restart.  We
agreed that the SG should not offer MTP-RESTART-ENDS with a sizeable list
of PC status information unless requested to by the ASP/AS.

We have had this discussion before.  The RFC is the result.

> furthermore during MTP Restart no MTP-STATUS primitive is sent to user

Look at the MTP-SAP definition in Q.701 (look at Q.711 too).  (There's
another reference (Q.2410?) from the NA/RC dicussion, but I can't remember
it of hand just now.)

Effectively an implementation dependent mechanism is described whereby
the newly joining MTP-User can obtain historical information concerning
MTP-PAUSE, RESUME and STATUS primitives which have transpired in a
similar fashion to MTP-RESTART with the network.  We had discussed this
in detail before, and agreed that a restarting ASP/AS might or might not
know destination status from its ASP/AS peers.  As a result, the SG
would not offer this information in an MTP-RESTART-ENDS-like procedure
but would wait to be prompted by the ASP.

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 14:53:31 -0400

Brian,

> of PC status information unless requested to by the ASP/AS.
[TOLGA] For that I agree, DAUD is usefull so that ASP gets the status only
when it wants. But I don't understand why congestion status is also
reported. This is not inline with MTP3.
> but would wait to be prompted by the ASP.
[TOLGA] As I said , using DAUD makes sense to me, because it will put things
in control of ASP(although one might argue it is not the same like in pure
MTP3 case). But I don't think sending SCON is a good idea, as response to
DAUD.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Sep 2002 12:43:26 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 04 Sep 2002 14:34:24)
> conflict.

There is no conflict.

> 3.8.4 says cleary that in case of ITU international, when one link
> is congested, corresponding route sets are put to congested status.

But doesn't say that this status is to be maintained anywhere: only
that an MTP-STATUS is to be sent to users attempting to send to such a
destination.

> Whether you do it by keeping it a variable or by checking everytime relevant
> link congestion status might be implementation dependent. But route set
> congestion status concept exists for ITU international network.

So?

> If one checks just congestion status of a single link, before sending the
> message to L2, this wouldn't be correct in my opinion.

What conformance test from Q.782 would it fail?

> "Destination Congested" check is there.

Yes, but it can be combined with select link in direct linkset, which was
my point: there is no need to maintain a destination congestion status
separate from direct linkset congestion status, even in the ITU SDLs (which
are normally renowned for their inefficiency.)

> accesibility or inaccessibility. the means of doing this is implementation
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> dependent"
^^^^^^^^^^^^

In M3UA's case, the SG waits for a DAUD and then indicates.

> Based on that , it is quite clear to me that this indication should be sent

The response to the DUAD *is* sent from MTP3 (SG) to its users (AS).

> user interface. During MTP3 restart no MTP-STATUS is sent.

Collected MTP-PAUSE/RESUME/STATUS is sent with MTP-RESTART-ENDS: the SG's
response to DAUD.

> It is only sent as response to a message destined to congested destination.

No, the status can also be part of the MTP-RESTART-ENDS.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Sep 2002 12:51:58 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 04 Sep 2002 14:53:31)
> reported. This is not inline with MTP3.

It is in line with MTP3: IN THE CASE WHERE THE MTP MAINTAINS CONGESTION STATUS.
You don't see that spelled out in Q.701 because it was written before ANSI
added congestion procedrues which were later incorporated in Q.704.  Q.701
was not revisited.

> MTP3 case). But I don't think sending SCON is a good idea, as response to

Quite frankly you can get away without DAVA and DUNA as a response to DAUD too.
All four (DUNA, DAVA, DRST and SCON) can be performed responsive.  Simply always
return DAVA to all addresses in a DAUD and then if the AS attempts to send to
a restricted, unavailable or congested destination, response with DUNA, DRST
and/or SCON as necessary.

Both approachs are fully consitent with MTP where TFA/TFP/TFR are both
broadcast and responsive (and sent unreliably) and TFC is responsive but with
a test procedure (RCT).

The RFC accomodates this.  So what is the issue?

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 15:18:30 -0400

Brian,

> The RFC accomodates this.  So what is the issue?
[TOLGA] For me the real issue is sending SCON as response to DAUD. I don't
think this is inline with MTP3. And I don't see special added value, if we
violate MTP3 way of doing things here. After MTP3 restart, only RESUME-IND
(in fact here spec is not very clear, I think PAUSE-IND is also allowed) is
sent to MTP3 User parts.
Q.704 9.2.4 says:
"When T20 is stopped or expires, the restarting MTP of the signalling point
or siganlling transfer point sends traffic restart allowed messages to all
adjacent signalling points via corresponding available direct link sets, and
an indication of the end of MTP reastart is sent to all local MTP Users
showing each signalling point's accessibility or inaccessibility. The means
of doing the latter is implementation dependednt." (On 9.7.1. SP with
restarting MTP according to subclause 9.2, only MTP-RESUME indications is
shown, but text has as usual precedence over that figure)
Based on that MTP3 informs its users only about accessibility or
inaccessibility of destinations, not about congestion status, after MTP3
restart. STATUS-IND is only sent as responsive.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Sep 2002 13:27:18 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 04 Sep 2002 15:18:30)
> (in fact here spec is not very clear, I think PAUSE-IND is also allowed) is

STATUS is also allowed.  So are CLLI codes and vendor identifiers.  So is
the color of the destination.

> restart. STATUS-IND is only sent as responsive.

There was no need to any more mention because the MTP/MTP-User interface was
normally internal to an implementation.  As such, the primitive interface was
abstract and there was no need to elaborate on implementation dependent items
totally under the control of single vendor on a single box.  By opening up
this interface with M3UA, these things needed to be clarified.  Remember the
discussions on NA/RC?

The AS will have a hard enough time as it is handling delayed SCON indications
from the SG, aggravated by the utter lack of ULP back pressure and flow
controls in M3UA.  Why do you want to delay indicating congestion to the AS
further, even when the SG has this information readily at hand to provide in
response to a DAUD: particularly at the critical moment when a new AS/RC is
activated and significant traffic pressure may already exist?

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 16:07:26 -0400

Brian,

> the color of the destination.
[TOLGA] Where is this written? I think Q.704 9.2.4 is clear there, that only
accessibility, inaccessibility should be indicated.
> this interface with M3UA, these things needed to be clarified.
[TOLGA] If MTP/MTP-User  interface were considered implementation dependent,
no primitives would be defined. And also, why should we consider it
implementation dependent? I can buy MTP3 from vendorA and ISUP from vendorB.
Interface between them is defined (primitives and when to send them).
> activated and significant traffic pressure may already exist?
[TOLGA] I think your this comment is more related with MTP3. In my opinion,
we should follow just, what MTP3 does. If it is responsive there, in my
opinion it is better to have it also responsive in M3UA. Also TFC in MTP3 is
delayed and originating node continues to send messages till it receives TFC
and user part is informed with STATUS-INDICATION. So, that originating node
is ware of congestion is delayed also in this case.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Sep 2002 14:27:44 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 04 Sep 2002 16:07:26)
> accessibility, inaccessibility should be indicated.

See also Q.751.

> Interface between them is defined (primitives and when to send them).

Sorry, interfaces at MTP were not an objective.  Upper layer OSI work did
include this, however, primitive are more elearly defined and available for
testing using TTCN.

> is ware of congestion is delayed also in this case.

The SS7 network procedures you speak of are not applicable to the MTP/MTP-User
interface, which is normally frictionless.

Consider, for example, the mass calling case with an MGC recovering, coming on
line and sending 2,000,000 IAMs before receiving the first SCON for the first
IAM from the SG, not due to SS7 network delays (the congestion is a result of
local link overload at the SG), but due to SCTP delays between the SG and
the AS.  Normally in the international case, the MTP User (ISUP in this case)
would have received MTP-STATUS on the 1st and 8th message.  Because of the
complete lack of application flow controls on SCTP, however,the full 2,000,000
were transfered before the 1st and 8th SCON arrived at the MGC.

In the normal SS7 system, the MTP/MTP-User interface is implemented as a
rather frictionless function call, and system dependent internal flow controls
(queue discipline).  It is rather easy in an intergrated SS7 system to avoid
such brutal conditions; however, for M3UA it is more problematic.

So, the AS needs to ramp up traffic somehow while being able to test for
congestion.  SCON in response to DAUD affords the AS some more flexibility in
this area, but you would appear to have it removed because it does not fit
with your interpretation of the specifications.

Please leave the use of SCON as it is in the RFC in response to DAUD: ASPs can
then, if they wish, test for congestion in a closed-ended, and even pre-emptive
fashion if they are capable (waiting for the DAUD response) rather than the less
desirable open-ended fashion (getting SCON 2,000,000 message too late).

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 17:17:31 -0400

Brian,

> interface, which is normally frictionless.
[TOLGA] I just mention procdures as defined in Q.704.
> were transfered before the 1st and 8th SCON arrived at the MGC.
[TOLGA] I think your example is too extreme, because you assume that AS
sends 2,000,000 messages, before SG can even reply with 1 SCON. First, I
don't think SCTPs congestion avoidance would allow this, if the roundtrip
time is really bad. Such problems are to be handled with a good IP network
design. Even if one tries to handle the scenario in your example, what about
a congestion in SS7, which will be reflected with TFC to SG? Till TFC is
sent to AS, MGC will continue to send messages. As I mentioned in my
previous message, I would think your comments more applicable to MTP3
itself.
> with your interpretation of the specifications.
[TOLGA] The point is, in MTP3 specifications it is quite clear that
TFC/STATUS-IND works in a responsive mode, not in broadcast mode.
> desirable open-ended fashion (getting SCON 2,000,000 message too late).
[TOLGA] Whenever SG detects local link congestion or receives TFC, it will
inform AS with SCON. So, I don't think checking congestion status with DAUD
is usefull, because if there is a change, SG will report it anyway. The only
time, where this migth have sense is, after association is established and
before traffic is started. But in that case, as I indicated above, I don't
think SCTP will allow to send huge numbers of messages from AS to SG,
without getting a response. Furthermore, there is nothing we can do for
congestion cases in SS7 network itself. They will continue to behave in
responsive mode.

Having said all of that, I think now we need to find a consensus. My
proposal is changing MUST for sending SCON as reply to DAUD to a MAY.
Furthermore, I would prefer not to refer to "ITU international network", in
sentences like "Where the SGP doe snot maintain the congestion status of the
SS7 destination". So, everybody will be free, to keep or not to keep
congestion status for ITU international network case, and it will be a
problem of MTP3 stack itself.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Sep 2002 15:34:41 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 04 Sep 2002 17:17:31)
> previous message, I would think your comments more applicable to MTP3

You miss the point: SCTP is not congested: the SS7 signalling links
off the SG quickly do become congested.  In fact, for the example,
SCTP never congests: there is a real big IP network feeding fixed
bandwidth SS7 network.  F=ma

> TFC/STATUS-IND works in a responsive mode, not in broadcast mode.

And SCON is sent in *response* to a DAUD.

> inform AS with SCON.

After some indeterminate delay.  How long must the AS wait to know whether
SCON will be sent in response to DATA?  With DAUD, the response is coupled
to the query and the AS can wait till it gets a response it it wants.  With
just responsive SCON, the AS can wait and wait...  How does it know that no
SCON is forthcoming?  Or whether the lack of SCON indicates lack of
congestion?  If the AS does not wait long enough, the problem I illustrated
arises.

> So, I don't think checking congestion status with DAUD
> is usefull, because if there is a change, SG will report it anyway.

You need to solve the above dilemma before making such broad statements.

> The only
> before traffic is started.

Also on an RC that was just activated, no matter how long the association
has been established.  This is one of the two procedures in the RFC.  The
other procedure is periodic, the use of which is illustrated above.  If you
don't want to use it, don't.  But the SG must respond appropriately so that
those ASPs which care to take advantage of it can.

> But in that case, as I indicated above, I don't
> without getting a response.

Each of the 2,000,000 messages have been properly acknowledged by SCTP.
It is the SCON that takes the time to get back.

Note that the draft still ridiculously implies that SCON should be sent
with sequenced delivery (further delaying them behind the reply messages
to the 2,000,000 message step function).

> Furthermore, there is nothing we can do for

The congestion in the example in not in the SS7 network, it is getting
to the SS7 network from the SG.  The direct links off the SG have their
transmit buffer overflowing triggering the MTP-STATUS/SCON to the AS.
It is just that it is going to take time to get there rather than just
being transferred across a functional interface.

> 
> Having said all of that, I think now we need to find a consensus.

We have consensus.  It is in the RFC.  I suggest you look back in the
mail archives because this was discussed extensively and consensus reached.
The IG statements just clarify some wording which wound up too brief in
the final draft.  It does not appear to make any change to the original
intent of the passage.

> proposal is changing MUST for sending SCON as reply to DAUD to a MAY.

It is already a MAY:  (You MUST if the SGP supports congestion status,
which it MAY not).  The MUST was originally being use to say that the
SCON MUST come before the corresponding DAUD/DAVA/DRST (because in earlier
drafts it mistakenly came after causing the same wait dilemma).

> problem of MTP3 stack itself.

I think it is appropriate an illustrative.  Nowhere does it say that ITU
international networks MUST NOT send SCON...

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 4 Sep 2002 19:11:53 -0400

Brian,

> bandwidth SS7 network.  F=ma
[TOLGA] I don't think that I miss the point. I am not talking about SCTP
congestion, I am talking about SCTP congestion avoidance mechanism. SCTP is
not congested but with a properly implemented congestion avoidance
mechanism, it is unlikely that AS can send 2,000,000 messages, without
receiving a reply. For that to happen, SCTP should be receiving 1,999,999
more messages , do some proper acknowledgement for them, whereas M3UA sleeps
lazly.
> And SCON is sent in *response* to a DAUD.
[TOLGA] TFC/STATUS-IND is sent as response to a message, which is destined
to the congested destination. DAUD is not such a message.
> You need to solve the above dilemma before making such broad statements.
[TOLGA] By not letting M3UA send messages without getting SCON, the
congestion is just pushed to the above layers. And even this won't solve the
problem. Let's consider the scenario, where at the beginning there was no
congestion, DAUD is sent, SCON(0) is received and traffic starts. After some
time local links of SG are congested (just to make it similar to your
example) SCON is sent from SG to AS, but till SCON is received by AS, AS
continues to send messages. How can one handle this case?

> It is the SCON that takes the time to get back.
[TOLGA] Is this a realistic scenario? When SCTP receives a message, it will
send it to M3UA. You assume SCTP receives 1,999,999 more messages and does
proper acknowledgement, before M3UA can reply even with one.
> being transferred across a functional interface.
[TOLGA] That the congestion is on local links in your example does not mean
that there won't be any congestion in SS7 network at all. How are those to
be handled?
> international networks MUST NOT send SCON...
[TOLGA] In IG 3.9.2 it is said:
"Where the SGP does not maintain the congestion status of the SS7
destination(ITU international networks), the response to a DAUD message
should always be only a DAVA, DRST or DUNA message as appropriate."
Furthermore the message flows on the following page also don't show SCON for
ITU international case. It is not important, whether there is a MUST NOT or
not, it is *wrong* to have a sentence saying that ITU international does not
keep congestion status, based on what it stands in Q.704.

BTW, m3uav12 3.4.4 SCON says:
"The SCON message can be sent from an SGP to all concerned ASPs...." Which
ones are those concerned ASPs?

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 9 Sep 2002 09:39:39 -0400

Javier,

As the author of IG, could you summarize changes necessary related with
"SCON in response to DAUD" thread -or if no changes are necessary answers to
the questions I have raised about this topic- , in any case giving technical
reasons behind it. Otherwise we will find ourselves again in an endless loop
and unless the concerns I raised are answered, in my opinion current text
needs modifications.

      Tolga