Subject: Re: [Tsvwg] SCTP applicability statement

From: Allison Mankin <[email-masked]>
Date: Sun, 04 Nov 2001 22:33:51 -0500

> A couble of remarks on the watchdog timer from AAA and its
> (lack) of applicability to SS7 UAs:
> 
> 1)  The timer is 30 to 60 seconds.  SS7 UAs must normally
>     failover with 0.1-0.5 seconds.
> 
You can't get this timing across arbitrarily placed boxes doing
the backup for each other - network failures that reliable
transports deal with don't lend themselves to that kind
of recovery in the Internet.  

Must-Ask Question: 
Why does this app want to use multiple associations (on multiple
boxes) rather than one association, lots of interfaces, lots
of redundancy, on (conceptually) one box.  (Conceptually because
it can be a cluster that looks like one box to its network peer).

AAA has mostly idempotent messages and values having a mesh
of redundant, unsynchronized servers.

> 2)  The watchdog timer is an application transaction timer.
>     SS7 UAs have no implicit acknowledgement or transaction
>     structure within the message flow that is usable by M2PA,
>     M2UA, M3UA or SUA in determining when to cancel the
>     watchdog timer.  Data in these UAs is unstructured (or
>     at least its structure is not known to the UA).  A sequence
>     number would need to be added to messages and acknolwedged
>     separately to cancel the timer.

You could cancel the timer just by any* data coming back from
the peer - it does not depend on transaction acks - the SCTP
reliability means that the messages are getting through.

> 
> Because there is no structure know by the UA (no separate
> transaction and response as there is in AAA), sequence numbers
> and acknowledgements would be required for each message.
> Then the watchdog timer reduces to a retransmission timer.
> 
> So, it appears that you are saying that SIGTRAN protocols must
> implement sequence numbers, acknowledgements, queueing and
> retransmission after all.
> 
No.   Please answer the Must-Ask Question.  

> Are you sure this is what you wish to recommend rather than
> fixing several problems in SCTP?

SCTP is far from perfect...but I don't think it set out to or
should provide a reliable protocol for Internet-wide fault tolerance.

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 4 Nov 2001 21:59:19 -0600

Allison,

Allison Mankin wrote:                                     (Sun, 04 Nov 2001 22:33:51)
> of recovery in the Internet.  

SCTP's application is also for the LAN and WAN.

> it can be a cluster that looks like one box to its network peer).

Because the SS7 network that it must interwork with is
a dual-plane network with redundant transfer/relay nodes
placed at a geographic distance.  Short answer: because
it must interface to two distinct and distant boxes.

> of redundant, unsynchronized servers.

SIGTRAN has telephone switches, MGCs, SCPs and real-time
control of MGs.

> the peer

During these failures message flow in one direction is ok.
Cancelling on any data coming back would not provide any
reliability for sent messages *across* associations.

> - it does not depend on transaction acks - the SCTP

But they do not get past the other end of SCTP.  That is
the application at the other end of SCTP can no longer
process messages via this association.  If the sender places
the messages on an alternate then things will be ok.  The
problem is in the switchover.  ABORTing the association
is not an options, becuase brief processor congestion is
one of the causes.

> No.   Please answer the Must-Ask Question.  

What is your solution?

> should provide a reliable protocol for Internet-wide fault tolerance.

It was certainly set out to handle SS7 changeover, but does not.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---