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

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 4 Oct 2005 10:04:25 -0400

Tolga,

At this time, I think I'll just have to respectively agree that I
disagree with you.  As I stated before, we are currently deployed in an
Wide Area Network with multihoming implemented.  And real life practical
experience tells me that:

1) The end customer doesn't not always implement their IP Network to
handle the load they are putting on it.

2) The remote switches sometimes behave in such a way as to not SACK
data (on any path!).  As a result of this, we will occasionally tear
down an association for the reason that we feel the remote switch may be
hung on one of it's interfaces (The end switch is not down, just one of
it's I/O boards where SCTP is implemented).  And we have a highly
distributed architecture (you may be familiar with it) and we are
running multiple associations (multi-homed).  

So...from my perspective, whether the RFCs want to handle these
scenarios are not, we are going to handle them (and we do).  If you
don't want to design your SW to handle them, that's OK with me.

You indicate that there is no need to run multiple associations and that
multihoming solves everything.  The reality is that if you have
implemented a highly distributed SG (multiple SGPs running on different
computing elements), then you will be running multiple associations to
the ASP.   And if you are going to tell me that multihomed-associations
NEVER fail, then I think you are not being practical.  So therefore, I
see a need for a retrieval mechanism.  Just my opinion based upon what
we are building and deploying in the networks.

Don't you guys develop a distributed Gateway that might run multiple
associations to a single ASP?

Regards,
Lincoln

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tolga Asveren
Sent: Tuesday, October 04, 2005 9:09 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 9:20 AM
> To: Tolga Asveren; [email-masked]
> Subject: RE: [Sigtran] RE: Message loss in SIGTRAN networks
>
>
> 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.
[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.
>
> 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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 4 Oct 2005 10:15:51 -0400

Lincoln,

> Sent: Tuesday, October 04, 2005 10:04 AM
[TOLGA] Maybe SCTP parmaeters need to be adjusted accordingly(?)
> running multiple associations (multi-homed).
[TOLGA]Like previously stated, this is a serious bug on the peer SCTP. I can
understand that we don't want to be stuck, i.e. to tear down SCTP
association is a good idea but IMHO, using this case as an argument to show
that SCTP association failre does not indicate peer host failure is not
fair. For such a case, they should be happy that you at least try to use the
other association.
> don't want to design your SW to handle them, that's OK with me.
[TOLGA]As said before, I agree with you that operational problems need to be
handled. I think the important point is trying to find a solution which is
consistent with the architecture of the protocol -if possible-. IMHO,
relaying on SCTP mechanisms for network/NIC redundancy is one of them. For
example it may be sometimes necessary to have loose SCTP parameters to
prevent associatio failures due to network caracteristics. The
solution -IMHO- should be inline with general M3UA principles if possible,
that was the rational behind the message I sent about using some
leightweight new mechanisms to inform peers about failure of a host.
> we are building and deploying in the networks.
[TOLGA]What I meant is that there is no need two run more than one
association between two peers. Otherwise, one can have multiple associations
between a SG and ASP, if SG consists of multiple SGPs.
> associations to a single ASP?
[TOLGA]I consider as M3UA peers ASP and SGPs -actually for SSNM type of
stuff it is SG and ASPs but in the context of this thread, I will hold on
ASP/SGP because we are talking about SCTP associations-. So, if a SG is
consisting of multiple SGPs, there will be  one association from a SGP to
each peer ASP -hence multiple associations from a SG to an ASP, but as said
I don't consider SG as peer of ASP in this context-. The arguments still
hold for a distributed SG case as well -like they hold for a distributed SS7
node-, host failures cause message loss -I believe by defining some more
complex mechanisms, SS7 could have minimized/avoided that message loss but
they didn't (please note I am speaking for host failure case)-.