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

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 11 Sep 2002 19:12:59 +0200

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

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

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

Cheers // Javier.

> 
>     Tolga
> 
> --- "Javier Pastor-Balbas (ECE)"
> <[email-masked]> wrote:
> > Hi Tolga, 
> > 
> > I think, I already answered the question.
> > 
> > The point is that currently only the remote endpoint
> > congestion is what is tracked in M3UA, when
> > available (national ITU and ANSI). The local
> > congestion at the SG can be tracked using SCTP
> > congestion mechanisms as the buffer gets full.
> > 
> > Anyway, if you have a proposal, make it public on
> > the list so that other people can also contribute
> > with their opinion.
> > 
> > 
> > Cheers // Javier.
> > 
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Monday, September 09, 2002 3:40 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] M3UA IG-01 : SCON in
> > response to DAUD
> > > 
> > > 
> > > 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
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
> _______________________________________________
> 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: "Tolga Asveren" <[email-masked]>
Date: Thu, 12 Sep 2002 10:02:12 -0400

Hi Javier,

> 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]
[TOLGA] I think, if it is done in a way, where Q.704 is not violated, that
would be fine.
> 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.
> 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.

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 12 Sep 2002 11:26:59 -0400

Please find a comment/correction below.

  Tolga

> Tolga Asveren
> Sent: Thursday, September 12, 2002 10:02 AM
> To: [email-masked]
[TOLGA] In fact what matters is whether local SCTP sends ACKs to the remote
SCTP, because the congestion needs to propogate to the remote SCTP. So,
unless we control ACKing of SCTP messages a per SS7 destination basis, I
don't think, remote SCTP will get congested.