RE: RE: Message loss in SIGTRAN networks

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


  On 10/4/05, Tolga Asveren <[email protected]> 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

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