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

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

Tolga,

Just to be clear....are you saying that the ONLY way that a multihomed
association can fail is through peer host failure?

Regards,
Lincoln 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tolga Asveren
Sent: Tuesday, October 04, 2005 10:16 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:04 AM
> To: Tolga Asveren; [email-masked]
> Subject: RE: [Sigtran] RE: Message loss in SIGTRAN networks
>
>
> 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.
[TOLGA] Maybe SCTP parmaeters need to be adjusted accordingly(?)
>
> 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).
[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.
>
> 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.
[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.
>
> 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.
[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.
>
> Don't you guys develop a distributed Gateway that might run multiple 
> 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)-.

_______________________________________________
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:35:35 -0400

Lincoln,

> Sent: Tuesday, October 04, 2005 10:45 AM
[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.