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

From: [email-masked]
Date: Thu, 12 Sep 2002 15:51:57 -0400

Hello Brian,

>Issuing an RCT on such a basis is a violation of SS7 MTP Level 3
>conformance (RCT is issued solely in response to receipt of TFC).

In our implementation of M3UA SG-STP, the requirement is that the
ASP properly issues the deviated DAUD (RCT) only in response to
receiving a response method SCON. For networks that do not support
route-set-congestion-test procedures, no RCT is generated, and the
deviated DAUD is ignored. The SG regulates the rate of generated
RCTs.

>The just of the RFC is simply that when the SG has congestion state
>information it respond with SCON; when it dosn not have congestion
>state information it deos not respond with SCON.  The importance is
>that the SCON MUST come before the DAVA or DRST in the response.

I understand this. For almost all situations, our implementation
of M3UA SG-STP does not respond to a (compliant) DAUD with a SCON,
since remote congestion status is not maintained.

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]> on 09/12/2002 12:34:54 PM

Please respond to [email-masked]

To:    [email-masked]
cc:    Tolga Asveren <[email-masked]>, [email-masked]
Subject:    Re: [Sigtran] M3UA IG-01 : SCON in response to DAUD

Jeffrey,

Issuing an RCT on such a basis is a violation of SS7 MTP Level 3
conformance (RCT is issued solely in response to receipt of TFC).

Also, what would you do for variants without TFC/RCT at all?

The intention of the procedure was that in the case where congestion
state is maintained ("rarely as you put"), the SG must respond with
SCON before DAVA or DRST.  In the case where the SG does not have the
congestion state (for whatever reason), it is not necessary to respond
with SCON.  In most cases, this may bonly be necessary to reply with
SCON when the SG has direct links that are congested.

The just of the RFC is simply that when the SG has congestion state
information it respond with SCON; when it dosn not have congestion
state information it deos not respond with SCON.  The importance is
that the SCON MUST come before the DAVA or DRST in the response.

--brian

[email-masked] wrote:
(Thu, 12 Sep 2002 10:33:19)
>
> Hello Tolga,
>
> I agree with everything you've been saying with regards to DAUD and SCON.
> In our M3UA SG-STP implementation, congestion status is rarely maintained
> in a fashion that allows for broadcast (SCON sent in response to DAUD).
>
> To address this issue, our implementation of M3UA deviates such that the
> Congestion Indications parameter is optional on received DAUDs. If that
> parameter is present, then the DAUD is converted (when appropriate) into
> a SS7 RCT and sent off into the network, possibly prompting a responsive
> SS7 TFC --> SCON to be generated back to the sender.
>
> In this way, we have distinguished an availability audit from a
congestion
> audit,
> and have allowed the M3UA peer to abate congestion, should it choose to
do
> so.
>
> Regards,
>
> Jeff
>
>
>
>
>
>
> "Tolga Asveren" <[email-masked]>@ietf.org on 09/12/2002 10:02:12
AM
>
> Sent by:    [email-masked]
>
>
> To:    <[email-masked]>
> cc:
> Subject:    RE: [Sigtran] M3UA IG-01 : SCON in response to DAUD
>
>
> Hi Javier,
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf
Of
> > Javier Pastor-Balbas (ECE)
> > Sent: Wednesday, September 11, 2002 1:13 PM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] M3UA IG-01 : SCON in response to DAUD
> >
> >
> > Hi Tolga,
> >
> > Answers below...
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Monday, September 09, 2002 5:44 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] M3UA IG-01 : SCON in response to DAUD
> > >
> > >
> > > Javier,
> > >
> > > I don't think that the concerns I raised are answered.
> > > I don't like at all to repeat several times the same
> > > thing (all of those  things are in the mailing list on
> > > the messages I sent to the WG, so how can I make it
> > > more public?) but anyway:
> > >
> > > What I propose is:
> > > 1- Remove any sentences in the IG like "ITU
> > > international does not keep congestion status",
> > > because this is wrong according to Q.704.
> >
> > We can change it to "remote node congestion status".
> [TOLGA] I think, if it is done in a way, where Q.704 is not violated,
that
> would be fine.
> >
> > > 2- Make congestion mechanism inline with Q.704, i.e. a
> > > responsive method to messages destined to the
> > > congested destination, which means no SCON reply to
> > > DAUD. If we see pactical benefit -which I doubt- to
> > > change nature of congestion notification from response
> > > to broadcast, necessary updates/clarifications should
> > > be done.
> > >
> > Answering DAUDs with SCON helps a new ASP to have control of the
> > current SS7 nodes status.
> [TOLGA]But this is not how it is done in SS7. Congestion is a responsive
> method, whereas availability/unavailability/restricted are broadcasted.
> What
> is the reason to change this with M3UA? I see benefit of SCON as reply to
> DAUD only, when there is *already* congestion for the queried
destination.
> But because we also need to handle the cases, where there is congestion
in
> SS7 network -and we know those nodes won't broadcast TFC, they will send
it
> only as response- the solution should be somewhere else. And IMO, it can
be
> done by carefully engineering the network both at SS7(number of links,
how
> many STPs SG is connected to etc..) and IP side(characteristics of IP
> network like roundtrip time, packet loss, and SCTP parameters). Sending
> SCON
> as reply to DAUD solves only a special case of the problem but the rest
is
> still there.
> >
> > >
> > > BTW, I totally disagree with your opinion, that we
> > > should rely to SCTP congestion for local link
> > > congestion. Those are congestions on different levels.
> > > So, in my opinion SS7 congestion should be handled as
> > > it is handled today in SS7 network. Also please note
> > > it is MTP3 which is tracking local link congestion or
> > > remote congestion in SS7 domain, not M3UA like you
> > > wrote in your message, so I don't think there is
> > > anything which can be done in this WG to change this
> > > behavior.
> > >
> >
> > Congestion mechanisms are handled by level 3 (network layer) in
> > SS7 network and handle by Transport Layer in IP networks. When
> > designing M3UA only remote congestion status are taking into
> > account since SCON is seen as a direct tranlation of TFC messages.
> [TOLGA] For that I don't agree 100%. I agree that for congestion between
> M3UA peers we rely on SCTP. But what about the congestion of local links
of
> MTP3? If we wait for SCTP buffers to get full, to propogate local link
> congestion:
> 1- There is no 1:1 relationship between links and associations, and how
> will
> the link congestion cause an association congestion? Before reading
> messages
> from SCTP we don't know for which PC they are destined to, and once we
read
> it from SCTP, it is already read, then how will the congestion propogate
to
> SCTP? Also buffer sizes for links and associations will be very different
> with a very high probability.
> 2- Even if this were possible, still this would be an odd way of doing
> this,
> we know there is congestion on the links, but we don't inform the peer
and
> wait some other buffers to get full. What might be the reason for this?
>
> So, IMO, we shouldn't be interested in just remote congestions but also
to
> local link congestions.
> >
> >
> > Cheers // Javier.
> >
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Sep 2002 14:13:28 -0600

Jeffrey,

[email-masked] wrote:                                             (Thu, 12 Sep 2002 15:51:57)
> deviated DAUD is ignored. The SG regulates the rate of generated

But SS7 does not permit RCT to be generated except in response to TFC.
Are you meaning that you are delaying response to DAUD until the next
normal RCT cycle?

> since remote congestion status is not maintained.

Then I take it you do not have a problem with the text in the RFC2b?

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 12 Sep 2002 17:14:43 -0400

Brian/Jeff,

> Then I take it you do not have a problem with the text in the RFC2b?
[TOLGA]My understanding of the current M3UA text is any SGP "MUST" reply
with SCON to a received DAUD always. IMO in the context of the text
SGP=MTP3+M3UA+NIF. Based on that, for any network
(ITU-international/ITU-national/ANSI) SCON should be sent, because for each
of them, congestion status is kept in MTP3(for ITU-international just for
local congestion), according to the relevant MTP3 specifications. As I
mentioned in my earlier messages, I see limited added value by sending SCON
as reply to DAUD and IMO it is not worth to diverge from MTP3 way of
handling congestion, but IMO it is more important to describe when to send
SCON as reply to DAUD (if any) in a clear way, rather than having some
sentences with MAY.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Sep 2002 15:40:19 -0600

Tolga,

That is not correct:  two passages from 4.5.3:

1:

"The SGP SHOULD respond to a DAUD messages with the MTP3 availability/
congested status of the routeset associated with each Destination Point
Code(s) in the DAUD message."

Meaning that the SGP MAY refuse to respond at all (e.g. for security
purposes: the ASP is not authorized to audit the requested DPC).

and 

2:

"Where the SGP maintains the congestion status of the SS7 destination,
and the SS7 destination is congsted, the SGP MUST adiitionally respond
with an SCON message before the DAVA or DRST message."

Which clearly indicates that where the SGP *does not* maintain the
congestion status, it is not obliged to respond with SCON.

Not only are these passages there to be read, but they clearly represent
the final concensus on the matter.  If you check the archives you will see
that all issues have already been considered.

--brian

Tolga Asveren wrote:                                                               (Thu, 12 Sep 2002 17:14:43)

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 12 Sep 2002 18:01:52 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, September 12, 2002 5:40 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] Bu then what about the sentence "Where the SGP maintains the
congestion status of the SS7 destinations, the SGP MUST additionally respond
with an SCON message before the DAVA or DRST message." This sentence uses a
"MUST".
> congestion status, it is not obliged to respond with SCON.
[TOLGA]The sentence "Where the SGP maintains the congestion status of the
SS7 destinations,..." does not have any meaning in my opinion. Because, SGP
*always* keeps congestion status of SS7 destinations, based on MTP3
standards, and there is nothing we can do about this in SIGTRAN WG. So, if
SGP keeps congestion status always, it also *MUST* reply always with SCON to
DAUD, accordin to current M3UA text.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Sep 2002 18:25:52 -0600

Tolga,

That doesn't appear to be anyone else's reading of the text.  Quite
the reverse...

--brian

Tolga Asveren wrote:                                                                 (Thu, 12 Sep 2002 18:01:52)

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 13 Sep 2002 09:18:05 -0400

Brian,

If it were open to interpretation, I wouldn't have a problem. But for
anybody familiar with first order logic it is clear that:

(1) Congestion Status Kept ===> SCON is sent as reply to DAUD (from M3UA)
(2) Congestion Status Kept (from MTP3)

Modus Ponens (1) + (2)   SCON is sent as reply to DAUD

There is nothing open to interpretation.

   Tolga

> Sent: Thursday, September 12, 2002 8:26 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Sep 2002 09:26:13 -0600

Tolga,

Nowhere does it say that the SGP MUST maintain congestion status.  This
is an IETF doucment.  Because it is not explicitly forbidden for an SGP
to not maintain congestion status, it is permitted.  This one does not
have to maintain congestion status and one doesn't have to reply with
SCON.  But, WHERE THE SGP MAINTAINS CONGESTION STATUS, it the SGP MUST
reply with SCON.

Note, this does not say "Whenever specified in the SS7 specifications
that one might need to maintain congestion status," or anyline of the sort.
How about we change "Where" to "When" in the final.  Would that make it
clearer for you?

--brian

Tolga Asveren wrote:                                                               (Fri, 13 Sep 2002 09:18:05)

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 13 Sep 2002 11:49:41 -0400

Brian,

> Sent: Friday, September 13, 2002 11:26 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] My only concern is that we make the document more clear and
add/correct text if there is a violation of what is said in MTP3 standards.
The reason why IMO the text indicates that SGP MUST maintain congestion
status is, because SGP=MTP3+NIF+M3UA and it is MTP3 which keeps it. The
behavior of MTP3 is defined in the relevant standards. I agree with you that
M3UA is an IETF document, but this is exactly my point. For that very
reason, we can't mandate how MTP3 should behave, so we can't change the fact
that it should keep congestion state. Any rephrasing, which addresses those
concerns is fine with me (or if there is a point which I miss, and which
will make any change unnecessary, I will be more than happy)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Sep 2002 10:01:23 -0600

Tolga,

Nowhere does it say that the MTP must keep congestion status.

Nowhere does it say that this requirement depedends on some
normative reference.

The requirements stand on their own (they don't even reference
other material).

Quite simply, for interoperability, if the ASP is relying upon
auditable state (it is sending DAUDs) and the SG maintains congestion,
state, then the SG must reply to the audit (DAUD) with SCON (the
congestion state), for heavens' sake...  Where the SG does not maintain
congestion state, it cannot (and does not) reply to the audit with
a congestion state it does not have (no SCON), or as permitted in the
RFC, it can refuse to provide anything at all (for security or whatever
reason), but for interoperability sake, the SG SHOULD reply to DAUD.

This is sooooo simple.

--brian

Tolga Asveren wrote:                                                               (Fri, 13 Sep 2002 11:49:41)

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 13 Sep 2002 12:19:28 -0400

Brian,

> Sent: Friday, September 13, 2002 12:01 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] This is said in relevant MTP3 specifications.
> Nowhere does it say that this requirement depedends on some
[TOLGA]Both ITU and ANSI MTP3 specifications are in the normative reference
list. I think whenever there is something related with MTP3 in M3UA
specification, this means "the relevent MTP3 specification".

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Sep 2002 10:42:59 -0600

Tolga,

Tolga Asveren wrote:                                                               (Fri, 13 Sep 2002 12:19:28)
> [TOLGA] This is said in relevant MTP3 specifications.

Nowhere in the SS7 specs does it mention what status an "SGP"
must maintain.  Also, I have already demonstrated to you how an
International MTP can be Q.782 compliant and still not "maintain"
routeset congestion status (only combined linkset congestion status).

> specification, this means "the relevent MTP3 specification".
Just because a reference is on the list does not mean that the
reference is applicable to each and every requirement in the RFC.
Where the reference is applicable, or relevant SS7 specifications
are germane, it is stated.  We used language such as "per the
relevant SS7 specifications" in such cases.  Because the passage in
question is not dependent on relevant specifications (but is depdendent
largely on implementation), we did not reference "relevant SS7
specifications".

Would it help you if we slipped the word "implementation" behind SGP?

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 13 Sep 2002 13:31:14 -0400

Brian,

> Sent: Friday, September 13, 2002 12:43 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] Of course MTP3 specs don't say anything about SGP. But in SGP MTP
connectivity is provided by MTP3. It is clear in Q.704 that congestion
status of route states must be kept (both for national and international).
If for ITU-international you keep combined link set congestion status and
use it instead of route set congestion status, it will be of course correct,
because ITU-international just keeps local congestion. For ITU-international
those two things are the same, bu thti sdoes not mean that ITU-international
does not keep congestion status.
> largely on implementation), we did not reference "relevant SS7
[TOLGA] It is said "Where the SGP does not maintain the congestion status of
the SS7 destination(ITU international networks)....". First of all this is
wrong but this also shows that M3UA refers to the relevant MTP3
specifications to decide whether SGP(MTP3) keeps congestion status or not.
BTW, is there a consensus that SCON reply to DAUD is not mandatory? If so,
why not to use a sentence with "MAY", without mentioning anything about
whether SGP keeps congestion status or not?

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 19 Sep 2002 09:55:26 -0400

Javier/Brian and all,

To close the loop, my proposed text changes for this thread is:

1)m3uaIGv01 3.9.2

New Text:
Delete "(ITU international networks)" in the last paragraph.

2)m3uaIGv01 5.4
5.4.3
Delete "(ITU international network)"

3)With the above modifications done, in fact the text will say "If
congestion status is kept, SCON MUST be sent as reply to DAUD",where it is
not specified when congestion status is kept(still IMO this migth imply,
whether congestion status is kept or not is defined in MTP3), instead of
this personally I would find it more appropriate to say "SCON MAY be sent as
reply to DAUD".

4)Sending SCON as reply to DAUD has positive impact ony for special cases
and because the overal system needs to handle all of the cases, SCON as
reply to DAUD shouldn't be necessary but there seems also no harm on sending
it. So, let's keep it.