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

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 4 Oct 2005 09:19:56 -0400

Tolga,

"3)The need that SCTP association failure indicates host failure - we
don't want to be fooled by network errors/failures- "

This is the main area where you and I would disagree.  I believe Brian
also made this point.  If you are working in a private WAN with many
routers, cables, and extensive load, you will have failures and it may
have nothing to do with the endpoints.  It may be the network in
between.  I'm sure you've seen networks failures of all kinds that had
nothing to do with the hosts at either end going down.

Regards,
Lincoln

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tolga Asveren
Sent: Monday, October 03, 2005 6:07 PM
To: [email-masked]
Subject: RE: [Sigtran] RE: Message loss in SIGTRAN networks

While trying to look to the issue from a different perspective:

Imagine the following scenario:

1)A not so great IP network. It usually delivers what is expected but
not always.
2)SCTP with multihoming.
3)The need that SCTP association failure indicates host failure - we
don't want to be fooled by network errors/failures- 4)The need that host
failures are detected in a reasonable amount of time.

a)Because of 3) and 1), we want to set our SCTP parameters a little bit
loose, allowing several retransmissions on each path, before deciding
for a host failure. This would cause host failures to be detected
slower.

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.

What if:
i. If we allow ASPs to send ASPDN messages on behalf of other ASPs,
addressed by ASPId -the rationale here is that an ASP paired with
another one could -hopefully- detect failure of another one much quicker
than SGP with loose SCTP parameters-? Actually, for Override traffic
mode, we probably don't need to send anything at all, just the
previously standby ASP sends ASPAC and all traffic is diverted to it.

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?

    Thanks,
    Tolga

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

______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has
been found clean.

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 4 Oct 2005 09:08:43 -0400

Lincoln,

> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Tuesday, October 04, 2005 9:20 AM
> To: Tolga Asveren; [email-masked]
[TOLGA]To handle such failures is the reason, why there is multihoming
support in SCTP -to eliminate a single-point of failure in such devices- and
to provide failover between paths without message loss. Instead of
implementing some other mechanisms, going with SCTP multihoming seem to
solve all issues as far as I can see. Of course there will be network
problems -failed routers, cut cables etc..-, but SCTP multihoming will
handle them. That is the rationale behind the argument that loss of SCTP
association can be interpreted as peer host failure, because a multihomed
SCTP is supposed to cover all other types of problems reasonably.