Subject: RE: [Sigtran] recommendations for M3UA/SUA BEATs when running overSCTP

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 3 Oct 2005 14:41:26 -0400

Brian,

That's really a separate issue.  Whenever we loose an association for
whatever reason, there exists the possibility of message loss.  I
consider this one of the major shortcomings of the current
specification.  I have reviewed an early draft (Version 0) of your
recommendation for using the COORID to prevent message loss and I think
it's a good idea.  I haven't seen any other switches that we have
interfaced to using this nor have any customers mentioned this.  I
believe that, as the customers become more educated, they will begin to
look for solutions to this problem and I think your recommendation is a
good place to start.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Monday, October 03, 2005 2:29 PM
To: Haresign Lincoln
Cc: Jeff Morriss; [email-masked]
Subject: Re: [Sigtran] recommendations for M3UA/SUA BEATs when running
overSCTP

Lincoln,

After you abort the association, how are you handling the resulting
message loss?

--brian

Haresign Lincoln wrote:                       (Mon, 03 Oct 2005
13:49:47)
> To whom it may concern:
> 
> I believe Jeff has a valid point.  To make the argument "Either the 
> SCTP implementation of appplication are broken.  Fix them." is not a 
> real valid argument.
> 
> When you deploy in the field against other people's switches, you can 
> not fix their switches.  And if there is a scenario that can lead to a

> stuck condition because one side is badly behaved, then we should add 
> protection in to the implementation.
> 
> In our implementation, we are taking down the associations if the 
> other side is misbehaving.  We are operating outside the specification

> in this case.  But I don't think any customers will complain when we 
> explain to them that we are protecting against lost revenue.
> 
> I agree that we should modify the recommendations to protect against 
> all bad scenarios.  The ITU/ANSI specifications have undergone 25 
> years of editting to improve them.  However, if you fail to get 
> agreement, I would operate outside the recommendation in this case.  
> You won't find any interoperabilty problems and you will keep your
customers happy.
> Regards,
> Lincoln

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 3 Oct 2005 14:35:25 -0400

Lincoln,

Architecturally, there is no shortcoming of M3UA in terms of message loss
for the following reasons:
1- It is assumed that SCTP will provide transport layer/network interface
reliability, i.e. use multihoming and multiple networks.
2- Because of 1), it is assumed that loss of SCTP association indicates that
peer host is down.
3- When peer host is down, there is no way to decide, which messages in
retransmission buffers are really received by the peer -please note this is
also the case for SS7-.

Whether SCTP meets 1) and/or a few changes are necessary in M3UA are a
different issue but as said, 1) is the main rational behind not having
recovery procedures in M3UA.

   Tolga

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Haresign Lincoln
> Sent: Monday, October 03, 2005 2:41 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] recommendations for M3UA/SUA BEATs when running
> overSCTP
>
>
> Brian,
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Oct 2005 00:07:45 -0600

Haresign,

Separate issue?

<pardon_the_sarcasm>

  Let me get this right:

  You are sending M3UA over SCTP over a non-graded (even noisy crappy)
  network (a combination that provides no assurances of meeting any
  deadline whatsoever and can delay packets within any stream indefintedly,
  or at least for several minutes, at any time), and you are proposing using
  a BEAT/ACK (which is sent only in one stream) with some fixed timeout after
  which you are going to ABORT the association, not knowning whether the
  timeout was due to broken equipment at the other end, or normal HOL blocking
  within the stream due to a dirty network, discarding at least the one packed
  stream of messages on every ABORT, with no procedure for recovering from the
  message loss, trying to reestablish the association from scratch in the midst
  of what could be just a noise burst, and punishing yourself and the properly
  operating peer, for the sake of a specific broken implementation?

  Did you want us to recommend a value for this T.punish timer?  Even recommend
  that it be used?  So that everybody can punish properly operating peers
  and end-point applications?

  Does that about sum it up?

  Oh, that's not all.  You want to replace the SS7 network with it too: right?

</pardon_the_sarcasm>

--brian

Haresign Lincoln wrote:                         (Mon, 03 Oct 2005 14:41:26)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Oct 2005 02:11:04 -0600

Lincoln,

By the way, a more current version of the corid draft is here:

  http://www.openss7.org/docs/draft-bidulock-sigtran-corid-02.txt
  http://www.openss7.org/docs/draft-bidulock-sigtran-corid-02.ps
  http://www.openss7.org/docs/draft-bidulock-sigtran-corid-02.pdf

The document did not receive any support as a WG item and expired almost
2 years ago.  You will find backwards compatible procedures in that draft
that can be used by M3UA, even if the other side does not support the draft.
I would recommend that you use at least that subset when you ABORT
associations in the manner you describe.

--brian

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