Subject: RE: [Sigtran] M3UA: IG: ASP IDs & a proposal to solve a network equipment failure scenario

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 1 Jul 2002 09:15:50 -0400

Michael,

Although host redundancy will be provided by ASP/SGP concept, it is also
important to limit message loss during switching from one SCTP association
to another one.
http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-corid-00.txt
explains possible problems in such a case and provides solutions.  Unless
such a mechanism is implemented, I think it is also important to limit cwnd
value, apart from the other parameters you mentioned.

   Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Michael Tuexen
> Sent: Saturday, June 29, 2002 2:48 PM
> To: Al Varney
> Cc: [email-masked]
> Subject: Re: [Sigtran] M3UA: IG: ASP IDs & a proposal to solve a network
> equipment failure scenario
>
>
> Dear all,
> see my comments below.
> Best regards
> Michael
>
> On Saturday, June 29, 2002, at 01:30 AM, Al Varney wrote:
>
> > At 06:17 PM 6/28/02 -0400, Tolga Asveren wrote:
> >> John,
> >> > -----Original Message-----
> >> > From: Schantz, John [mailto:[email-masked]]
> >> > Sent: Friday, June 28, 2002 2:33 PM
> >> >
> >> > Javier,
> >> >
> >> > I think you are giving multi-homing more credit than it is due.  The
> >> > scenario happens whether multi-homing is implemented or not.  And it
> >> is
> >> > not just my problem, it's a general problem.  The issue is that the
> >> AS
> >> > or SG that is not next to the failure can not detect it via M3UA or
> >> SCTP
> >> > until several seconds (and lots of traffic) has passed.  Why not let
> >> the
> >> > side that can immediately detect the problem inform the side that
> >> can't
> >> > so the other associations or multi-home IP addresses can be used to
> >> go
> >> > around the problem.  Test it in your lab, connect 2 systems via a LAN
> >> > and pull the Ethernet Cable from one of the interfaces on one system.
> >> > How long did it take the other system to detect the problem and move
> >> the
> >> > traffic?
> >> [TOLGA] IMO, for M3UA SCTP multi-homing is a good choice to deal with
> >> network problems. Even if it might take several seconds to detect a
> >> path-failure -based on the values of SCTP parameters- still no message
> >> will
> >> be lost when traffic is switched to the other path.
> >
> >    Unfortunately, SS7 isn't TCP -- message loss (at a low rate) is
> > acceptable in SS7.  What is less acceptable is excessive delay.  [TCP
> > accepts delay and tries to prevent message loss.]  Unfortunately,  IP
> > can do nothing to address delay.  Only the engineering of the network
> > and the intrinsic network reliability and failure handling can do it
> > (below the IP layer), with virtually no assistance from the IP protocol
> > layer.  Perhaps MPLS or other end-to-end "connection-oriented
> > transport" can fix the delay problem, but SCTP must (at least in RFCs)
> > assume a generic "Internet".
> >
> >    So ... SCTP + M3UA assures no message is lost over the
> > several-second path hunt for a working association.  Unfortunately, in
> > doing so it doesn't assure that no CALLS are lost as a result.  An IAM
> > (requesting a continuity test) delayed by 2 seconds will almost always
> > result in an IAM re-attempt.  Another 2-second delay could fail the
> > call entirely.  Plus it ties up connections waiting on timers to
> > expire.  SCCP/TCAP delays to SCPs are often limited to about 3 second
> > round-trip delays -- and a call failure after that time-out.
> >
> >    Worse, telephone users themselves have been trained (by decades of
> > call-setup-time reductions) to just hang up if audible ring tone is
> > delayed by more than a few seconds.  How long do you wait on a call?
> > So SCTP "re-homing" due to spotty network congestion could not only
> > cause some call attempts to be dropped by call servers, but could also
> > trigger lots of abandons by callers (I've found adjusting THEIR timer
> > values rather difficult).  And the side-effect of lots of user
> > abandons?  They try the call AGAIN!  And thus increase the short-term
> > signaling traffic load.  The last thing you need during those events
> > are "old messages" eating up your messaging resources (buffers, SCTP
> > associations, transmission facilities, etc.).
> >
> >    SCTP/M3UA would be much better off if "old messages" (say, queued
> > for more than a second or two) were just discarded from transmit
> > buffers.  It takes a rare combination of multiple failures for the
> > traditional SS7 network to delay messages more than a couple of
> > seconds.  The higher-layer protocols (ISUP, IN, etc.) are built on the
> > assumption that messages may be occasionally lost, but delayed very
> > rarely.  Late-arriving messages can interfere with other calls -- lost
> > ones usually affect at most one call.
> As I have written several times, you have to use others SCTP parameters
> than given in RFC 2960. But
> you are right saying that it makes no sense (at least, may it hurts)
> that the SIGTRAN layers still
> retransmits messages which are than retransmitted from the SIGTRAN user
> (ISUP) in your case. That is
> one of the reasons the ID
> http://www.ietf.org/internet-drafts/draft-stewart-prsctp-00.txt
> does exist. It allows you exactly what you want to do: You can specify a
> lifetime for your data.
> >
> >>  The real problem case
> >> is, when there is a host failure. In such a case, multihoming won't
> >> help,
> >> nor will changeover-like mechanisms, so this is also a problem case for
> >> traditional SS7.
> >
> >    Traditional SS7 hosts rarely fail, and provide multiple independent
> > interfaces to independent network elements/interfaces.  M3UA hosts
> > probably need to do the same.  Unfortunately, SCTP multihoming can't
> > convert unreliable hosts and a few NICs into a real SS7 SEP.  Maybe
> > M2PA with several NICs, each connected to totally independent private
> > networks, would come close to fixing the NIC/network path issue.  The
> > unreliable host issue will persist until SS7/ISUP/SCCP are replaced
> > with protocols designed for stateless, multiple-copy servers --
> > assuming such protocols can really support the voice call expectations
> > of most users.  But then you wouldn't need SCTP....
> >
> SCTP helps you in case of network failures, not in case of host
> failures. For handling host failures
> the adaptation layers use the ASP/SGP stuff. There is even a whole WG
> (Reliable Server Pooling) dealing with
> this problem. And guess, the people working in the RSerPool WG are
> mainly from the SIGTRAN WG...
> > Al Varney -- just my usual ranting
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> [email-masked]
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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