Subject: RE: [Sigtran] RE: Message loss in SIGTRAN networks

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 4 Oct 2005 11:59:49 -0400

Tolga,

Sounds like a good plan (the part about putting together a document).

Lincoln 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tolga Asveren
Sent: Tuesday, October 04, 2005 11:39 AM
To: [email-masked]
Subject: RE: [Sigtran] RE: Message loss in SIGTRAN networks

Lincoln,

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Tuesday, October 04, 2005 11:48 AM
> To: Tolga Asveren; [email-masked]
> Subject: RE: [Sigtran] RE: Message loss in SIGTRAN networks
>
>
> Tolga,
>
> In theory, what you are saying may be true.  In practice, associations

> are failing without remote host failure.  We are seeing it in the 
> networks (multihomed) that we are dealing with.  If you fail to 
> acknowledge this fact, then there is no point to this discussion any 
> further and we should just agree to disagree on this point.
[TOLGA] No, no I am not trying to keep my eyes closed, just thinking
there may be something to do -adjusting SCTP parmaeters etc..- to make
the situation acceptable, without adding some procedures with sequence
numbers and such kind of things -and I may be wrong-. OTOH, yes, for now
we have different opinions about how to tackle the problem but I believe
Lyndon's suggestion is a really good one. Let's try to document things
in a draft and then let's see where it is going to lead.
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tolga Asveren
> Sent: Tuesday, October 04, 2005 11:24 AM
> To: [email-masked]
> Subject: RE: [Sigtran] RE: Message loss in SIGTRAN networks
>
> Lincoln,
>
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email-masked]]
> > Sent: Tuesday, October 04, 2005 11:33 AM
> > To: Tolga Asveren; [email-masked]
> > Subject: RE: [Sigtran] RE: Message loss in SIGTRAN networks
> >
> >
> > Tolga,
> >
> > Let's take this one step at a time.
> >
> > OK, so you accepted my premise that theoretically (and practically),

> > associations will fail.
> [TOLGA]No, I just said theoretically. Practically an SCTP association 
> failure should indicate a host failure with a very very high 
> probability from M3UA point of view where this is high enough to 
> satify the needs of SS7. And as said below, SCTP with multihoming 
> should deliver this by preventing single-point of failures with 
> multihoming -one can even have more than 2 interfaces/networks 
> multihomed to prevent even n-point of failures-.
>
> Just on the more philosophical side of the things, I believe for any 
> system/mechanism it could be argued that it could fail theoretically 
> (and practically with a certain probability). Important is that 
> reliability is above a certain threshold for practical usability of 
> that system/mechanism.
> >
> > The next question is do you want to live with the potential data 
> > loss,
>
> > or do you want to design something in to the M3UA protocol to try to

> > reduce or eliminate the message loss when the lower layer transport 
> > fails.
> >
> > Regards,
> > Lincoln
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Tolga Asveren
> > Sent: Tuesday, October 04, 2005 10:36 AM
> > To: [email-masked]
> > Subject: RE: [Sigtran] RE: Message loss in SIGTRAN networks
> >
> > Lincoln,
> >
> > > -----Original Message-----
> > > From: Haresign Lincoln [mailto:[email-masked]]
> > > Sent: Tuesday, October 04, 2005 10:45 AM
> > > To: Tolga Asveren; [email-masked]
> > > Subject: RE: [Sigtran] RE: Message loss in SIGTRAN networks
> > >
> > >
> > > Tolga,
> > >
> > > Just to be clear....are you saying that the ONLY way that a 
> > > multihomed
> >
> > > association can fail is through peer host failure?
> > [TOLGA]Theoretically no, but from M3UA point of view the expectation

> > is that this holds true with a very very high probability. I 
> > believe, we also need to consider that no mechanism is fully failure
safe, i.e.
>
> > if we avoid single-point of failures we usually consider this as an 
> > acceptable solution.
> > My understanding is that SCTP multihoming can avoid single-point of 
> > failures for transport layer services.
> > >
> > > Regards,
> > > Lincoln
> > >
> >
>
>
>
> _______________________________________________
> 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: Thu, 6 Oct 2005 11:43:21 -0400

Thomas,
  -----Original Message-----
  From: Thomas Steffen [mailto:[email-masked]]
  Sent: Thursday, October 06, 2005 11:43 AM
  To: Tolga Asveren
  Cc: [email-masked]
  Subject: Re: [Sigtran] RE: Message loss in SIGTRAN networks

  On 10/4/05, Tolga Asveren <[email-masked]> wrote:
    a) would contradict with 4). We don't want to send messages to a host,
which
    already has crashed, because all such messages would be lost.

  Just one question: if the host fails, the messages would not be
acknowledge, and they should still sit in the outgoing window buffer. So
once the host failure has been detected, you can read the buffer and
reschedule the messages.
  [TOLGA]For sent but not unacknowledged messages, we can't do anything if
the peer crashes, they will be dropped. We don't know which ones have been
received by peer and we prefer to loose messages rather than to replicate
them. This is also that way in SS7. OTOH, if we limit the number of sent but
unacknowledged messages to a failed host, we may limit number of messages
dropped.

  In practice, I have not seen an SCTP implementation yet that supports
this. The classical UNIX socket API does not seem to provide a way to
retrieve messages, and in other drivers the functionality was just not
implemented.
  [TOLGA]I have seen such implementations -actually RFC2960 Section10
defines such kind of functioanlity for the interface between SCTP and SCTP
user. As far as I know, also sockets API draft supports retrieving messages
when an association fails.

  And even if you can recover the messages, what do you want to do with
them? If the host failed, it is impossible to determine whether they were
processed before the failure, so you risk sending duplicates. If only the
association failed, and the host is still up, it would be possible to
retrieve the sequence number and find out. However, neither SCTP nor M3UA
support this (unlike MTP3). Is this what you ask for: a way to determine the
last received message, and a way to resend later messages?
  [TOLGA] Yes, there is nothing to be done for them, that is the reason why
I try to limit their number whenver a peer host crashes, because unless we
detect/are informed peer falure, we will continue to send messages to them.
And no, I personally am not asking for a way to retrieve sequence numbers
because -at least for now- I am on the "SCTP provides network/NIC
reliability" camp.
  OTOH -although I need to recheck SCTP socket API- , I believe SCTP gives
certain sequencing information related with retrieved and received messages
both for sender and receiver.

    ii. Now a little bit more dirty part of the problem. What to do about
failed
    SGPs? Use something like SGPId+ASPDN-ACK, SGPId+BEAT, IP Address/SCTP
    port+BEAT?

  That is a good question. With E1/T1 you get a carrier lost, but an IP
network cannot provide this information.  All the solution that I know for
IP only work in the local network, so maybe having a "status monitor" per
network segment would be an idea. Any idea how rstatd works?
  [TOLGA] Well, actually when  peer fails, SCTP association wil fail, but
the issue I was trying to address was, what to do for cases where SCTP is
not fast enough for that reason -the obvious answer is to adjust parmaeters
of SCTP but this solution is not applicable for the scenario I mentioned-. I
believe any solution -if necessary- shouldn't rely on OS/platform dependent
tools but on M3UA procedures themselves.

  Thomas