Subject: [Sigtran] Message loss in SIGTRAN networks

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 3 Oct 2005 16:17:42 -0400

Subject changed to reflect topic

Tolga,

In an ideal world with everything working according to the
specification, I agree that there will be no message loss.  In the real
world, associations fail, fault-tolerant routers fail, customer support
people accidently pull cables, execute the wrong commands, etc...  We
must deal with poorly designed networks and human error.

If you are running multihoming (optional), you have less of a
probability that associations won't fail.  However, they still can fail
(and they do fail).  The question is do you want to add additional fault
tolerance in to the specifications to cover the inevitable failures that
are going to occur in the network.

Regards,
Lincoln

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

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

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Monday, October 03, 2005 3:00 PM
> To: Tolga Asveren; [email-masked]
> Subject: RE: [Sigtran] recommendations for M3UA/SUA BEATs when running

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 3 Oct 2005 16:18:31 -0400

Lincoln,

I agree with all of the goals you mentioned. The only point we differ is,
whether SCTP multihoming using multiple networks provides no-single point of
failure semantics or not.

IMO, SCTP multihoming could address router failures, accidently pulling a
cable etc... This obviously won't mean that associations won't fail, they
will, when the peer is down.

Another point is, I personally always thought that SIGTRAN protocols are
going to be run on private networks -with all respect to the "I" in IETF-
which will be engineered for that purpose. Even if SCTP parameters are
adjusted for poor IP network characteristics, I would thint that most SS7
applications would be more demanding in terms of message delays.

Would adding additional reliability hurt? IMO, defining new procedures for
reliability will have a very high cost, both in terms of
development/complexity/interoperability and from CPU cycles point of view
with marginal/no added value.

It would be interesting to hear what other people think about this topic.
IMO, if there are concerns, they need to be addressed, either by
demonstrating a solution from existing procedures or by defining new
procedures. IMO, SCTP multihoming is the solution.

    Thanks,
    Tolga

> Sent: Monday, October 03, 2005 4:18 PM
> Subject: Message loss in SIGTRAN networks
>
>