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

From: [email-masked]
Date: Thu, 12 Sep 2002 10:33:19 -0400

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Sep 2002 10:34:54 -0600

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)

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