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

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

Re-sending...

-----Original Message-----
From: Javier Pastor-Balbas (ECE) 
Sent: Wednesday, September 11, 2002 7: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".

> 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: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 12 Sep 2002 10:56:51 +0200

Re-sending...

-----Original Message-----
From: Javier Pastor-Balbas (ECE) 
Sent: Wednesday, September 11, 2002 7:13 PM
To: 'Tolga Asveren'; [email-masked]
Subject: RE: [Sigtran] M3UA IG-01 : SCON in response to DAUD

Hi Tolga, 

Answers below...

Cheers // Javier.

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Thu, 12 Sep 2002 02:33:01 -0700 (PDT)

Re-sending...

-----Original Message-----
From: Javier Pastor-Balbas (ECE) 
Sent: Wednesday, September 11, 2002 7:13 PM
To: 'Tolga Asveren'; [email-masked]
Subject: RE: [Sigtran] M3UA IG-01 : SCON in response to DAUD

Hi Tolga, 

Answers below...

> to broadcast, necessary updates/clarifications should
Answering DAUDs with SCON helps a new ASP to have control of the
current SS7 nodes status.

> anything which can be done in this WG to change this

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.

---

From: Kevin McCandless <[email-masked]>
Date: Fri, 13 Sep 2002 07:16:25 -0700

I had to jump into this thread because I heard the M3UAv12 has been given
and RFC number.  I think the number was 3334.  Oh and by the way Jeffrey are
you saying your M3UA is not compliant with the M3UAv12?  What is the impact
if we need to interoperate your stack against another implementation that is
compliant?

Kevin.............

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 7:11 AM
> To: [email-masked]
> Cc: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] M3UA IG-01 : SCON in response to DAUD
> 
> 
> 
> Hello Brian,
> 
> >Precisely:  Your configuration is not supported by the RFC.  
> If you are
> >going to devise a proprietary or non-standard configuration, 
> it really
> >doesn't matter what you do.  If interoperability is of 
> concern to you,
> >I would advise that you follow the proposed standard.  In 
> the standard
> >you have two choices:  (1) the SG terminates MTP3; (2) the SG is not
> >connected to an SS7 network and is really an IPSP.
> 
> It is not a RFC yet, and yes, when M3UA becomes a RFC, we will comply.
> 
> IMO it is unfortunate that this functionality is required for the M3UA
> component of the SGP. It is not a function of an SG-STP's MTP3 to
> maintain congestion status obtained from TFCs that are not destined
> to it, but simply through-switched, as is the case when a TFC arrives
> for the ASP, and the SGP and ASP do not share a point code. It is
> clear to me (now) that, according to the RFC-to-be, ASP point 
> codes are
> virtual and are implicitly shared with the SGP.
> 
> Since the ASPs are notified of congestion status, and 
> probably implement
> a procedure to handle it (that is, stop sending and begin to audit), a
> simpler alternative is to allow them to provide the stimulus 
> for the SGP
> to generate RCTs. This allows for remote congestion status to 
> be maintained
> in just one place -- the ASP.
> 
> Regards,
> 
> Jeff
> 
> 
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]>@ietf.org on 09/12/2002
> 05:44:54 PM
> 
> Please respond to [email-masked]
> 
> Sent by:    [email-masked]
> 
> 
> To:    [email-masked]
> cc:    Tolga Asveren <[email-masked]>, [email-masked]
> Subject:    Re: [Sigtran] M3UA IG-01 : SCON in response to DAUD
> 
> 
> Jeffrey,
> 
> [email-masked] wrote:
> (Thu, 12 Sep 2002 16:58:48)
> >
> > Hello Brian,
> >
> > >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?
> >
> > I am refering to the scenario in which the M3UA SG-STP does
> > not share a point code with the M3UA peer. The M3UA ASP sends
> > a message via the SG-STP into the SS7 network, and the message
> > encounters congestion. A response method TFC is generated, arrives
> > at the SG destined to the peer's point code, and is sent out as
> > a SCON. (The SG-STP does not capture the TFC and maintain congestion
> > status for the destination, nor does it initiate route-set-test on
> > behalf of the ASP). The ASP replies with a deviated DAUD. The SG
> > generates a RCT and sends it to the congested destination.
> >
> > And yes, I know that your next response is going to be that the
> > SG is supposed to terminate MTP3, and therefore should implement
> > route-set-test on behalf of the ASP. I disagree with this, when
> > the SG and ASP do not share a point code.
> 
> Precisely:  Your configuration is not supported by the RFC.  
> If you are
> going to devise a proprietary or non-standard configuration, it really
> doesn't matter what you do.  If interoperability is of concern to you,
> I would advise that you follow the proposed standard.  In the standard
> you have two choices:  (1) the SG terminates MTP3; (2) the SG is not
> connected to an SS7 network and is really an IPSP.
> 
> >
> > >Then I take it you do not have a problem with the text in 
> the RFC2b?
> >
> > The fact that it does not require the SG to send a SCON in response
> > to a DAUD is good. ;)
> 
> I agree.
> 
> >
> > Regards,
> >
> > Jeff
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

---

From: [email-masked]
Date: Fri, 13 Sep 2002 11:31:09 -0400

Hello Kevin,

Our M3UA v12 compliance is documented in our compliance matrix.
The congestion abatement issue is described in detail.

The prevailing forum view seems to be that, when the SG maintains
congestion status for the congested destination the SG needs to respond
with
SCON to a received DAUD prior to sending DAVA/DRST.

If our SG is configured to share a point code with the ASP, then it
implements
congestion abatement on behalf of the ASP and maintains congestion status.
If the SG is configured such that it does not share a point code with the
ASP,
then it almost never maintains congestion status for remote destinations,
since it does not originate traffic.

When our SG maintains congestion status, it sends a SCON prior to sending
DAVA/DRST.

So we are compliant on this issue, depending on one's interpretation.

Regards,

Jeff