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

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

Tolga,

Sorry, but this reasoning doesn't work.  I don't know about you, but our
SW has been deployed in some places with fairly unreliable IP networks.
As a result of this, we have lost some associations.

Also, another consideration is that some switches that we have connected
to do not support multihoming.  However, we must provide fault
tolerance.  Therefore, we are running multiple associations to the same
switch and loadsharing our traffic across the associations.  The
associations are on different networks.  If you have a router or IP
switch fail between you and the remote switch (and they do fail), then
you loose an association and there will be loss of data.

Remember, there are many things that can break between you and the end
point.

With SS7, the peer host can be up, but you can loose an I/O board, or
simply have a cable failure (also true with SIGTRAN).

Regards,
Lincoln 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tolga Asveren
Sent: Monday, October 03, 2005 2:35 PM
To: [email-masked]
Subject: RE: [Sigtran] recommendations for M3UA/SUA BEATs when running
overSCTP

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

> -----Original Message-----
> 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,
>
> 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
>

_______________________________________________
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: Mon, 3 Oct 2005 14:57:01 -0400

Lincoln,

I understand the concerns you mention but I just stated how things are
supposed to be from M3UA point of view : multihoming + reliable IP networks.
Yes, things can be broken in the network, so the IP network also needs to be
designed in a fault-tolerant way -which is possible- and multihoming allows
us to tolerate some reasonable long amount of IP down time.

Specifically for the problem you mentioned, lack of multihoming support
seems to be the key point, otherwise there wouldn't be any message loss
whatsoever. Configuring SCTP parameters properly according to the
characteristics of underlying IP network and according tot he needs of the
application are also important.

If the basic assumptions of protocol architecture are violated, it is no
suprise that certain procedures are broken and/or procedures defined in the
protocol fall short of satisfying demands. If there were multihoming support
and multiple networks, NIC card failures, cable problems, router failures
and alike would be addressed.

   Thanks,
    Tolga

> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Monday, October 03, 2005 3:00 PM
> To: Tolga Asveren; [email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Oct 2005 22:38:58 +0200

Hi Lincoln,

I think Tolga gave a very good description. You need multihoming
to avoid single point of failures and you need some reliability of
your IP network.

This is pretty much the same as in the SS7 world. You have separate
networks there too, and require also some limits on the error rate.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Oct 2005 22:39:51 +0200

Hi Tolga,

good description.

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Oct 2005 03:51:25 -0600

Michael,

But, you also need to fail over between associations to support M3UA's
redundancy model (that is to acheive NSPOF).  It is at that point where
M3UA unnecessarily discards messages.

--brian

Michael Tuexen wrote:                       (Mon, 03 Oct 2005 22:38:58)

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