Subject: DUNA, DAVA, SCON and DRST

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Oct 2001 16:05:12 -0500

Section 4.5.1 says:

  DUNA, DAVA, SCON, and DRST messages MUST be sent sequentially and 
  processed at the receiver in the order sent.  SCTP stream "0" is 
  used to provide the sequencing. The only exception to this is if the 
  international congestion method (see Q.704) is used.  If so, the 
  Unordered bit in the SCTP DATA chunk MAY be used for the SCON message.

This was discussed several versions ago.  The equivalent MTP3 messages
in the SS7 network are not only sent unreliably, they are sent unordered.
The MTP primitives which derive from them are also unordered.  This
is the reason for both responsive procedures and broadcast procedures
which are also applicable at the MTP user.  Whether these messages are
send ordered or unordered is completely an implementation matter and
is dependent upon specific SS7 network variant and operator policy.

Therefore, these messages MAY be sent ordered and MAY be sent unordered.

Please reword this paragraph to reflect this.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

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

---

From: Wodarz Juergen <[email-masked]>
Date: Tue, 16 Oct 2001 10:45:58 +0200

Hi Brian,

isn't it a MUST to send SNMM messages ordered?
I think it is a big difference for an ASP whether it receives
a DUNA(SPC=x) and then a DAVA(SPC=x) or vice versa.
It results in different final states of SPC=x viewed by the ASP.

Best regards,

	Juergen

> -----Urspr> üngliche Nachricht-----
> Von:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Gesendet am:	Donnerstag, 11. Oktober 2001 23:05
> An:	sigtran
> Betreff:	DUNA, DAVA, SCON and DRST
> 
> Section 4.5.1 says:
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 04:11:20 -0500

Juergen,

Consider that the TFPs and TFAs from which they are derived can
be reversed in the SS7 network (they are send unordered in the
SS7 network for some variants).

As they are sent unordered in some variants for SS7, the draft
should not place a MUST on sending them ordered in M3UA.  MTP-Users
already have means to deal with mis-ordering.  Sending to an
unavailable destination will illicit a responsive DUNA.

It is far more important that DUNA, DAVA, etc be expedited in
their delivery to stop the MTP-User from sending messages which
it should not, rather than worry about misordering.  The amount
of time that it takes a destination to shift from available to
unavailable and visa versa is much larger than the expected RTT
on an SCTP association.  It is extremely unlikely that two
SNMM messages for the same destination would ever be on the wire
at the same time (so there is nothing to mis-order).

Nevertheless, the draft cannot make statements here.  These are
performance related issues which cannot be addressed by the draft.

Please don't tell me (or even dare to recommend) that these need
to be ordered.  Even in catastrophic blackout of the SS7 network
it has taken seconds to TFPs to trickle in, and usually hours for
the TFAs.  The last link connecting an SP to the SS7 network cannot
go up an down fast at all.  The Q.704 basic procedures for signalling
link restoration indicate that it takes about 10 to 60 seconds for
the first link to be reestablished at L2 and then there are the
MTP Restart procedures for the node to go thru.

So, your example of a DUNA and DAVA getting switched in order is
absurd.  For SPC=x these messages are minutes (to hours) apart.
The same holds true for DRST and SCON.  Neither of these procedures
in the SS7 network permit thrashing back and forth in state so
fast that these messages could ever be misordered.  They are
never close enough together.

Please remove the ordered requirement for all SNMM messages.

--brian

Wodarz Juergen wrote:                                      (Tue, 16 Oct 2001 10:45:58)
> > To unsubscribe send a blank email to [email-masked]
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 17 Oct 2001 14:21:45 +0200

Hi Brian, 

I think that the TDM network offers less possibilities to get messages in the wrong order, doesn't it? Maybe that is the main reason to send these messages in a ordered basis...

Cheers // Javier.

> -----Original Message-----
> From: Wodarz Juergen [mailto:[email-masked]]
> Sent: Tuesday, October 16, 2001 10:46 AM
> To: sigtran
> Subject: AW: DUNA, DAVA, SCON and DRST
> 
> 
> Hi Brian,
> 
> > To unsubscribe send a blank email to 
> [email-masked]
> 
> 
> ---
> 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: Wed, 17 Oct 2001 07:49:13 -0500

Javier,

On the contrary, the TDM network is a complex set of paths over which
messages can get reordered quite easily.  SS7 TFx are not treated any
differently than user messages under changeover and changeback: both
which allow ample opportunity for reordering.  In fact, just the fact
that TFA and TFP are being sent means that changeover and changeback
are occuring.

The same is true for SSP/SSA.  Both responsive and broadcast procedures
are implemented because of the possibility of reordering.  Responsive
procedures catch any transient state mismatches due to reordering.
Otherwise, there would be little need for responsive procedures.

There is no reason for M3UA or SUA to force ordering on these messages
if the implementation sees fit to send them unordered.

For a single stream implementation (why??? don't ask me) it may even
be necessary to expedite SNMM around DATA to achieve performance goals.

The implementation should be permitted to do it either way as it has
little to no effect on the peer and does not affect interoperability.
The MTP-User interface is defined with responsive procedures as well.

These are implementation specifics an there is no call for a MUST here.

Also there is no reason to send SNMM on stream '0'.  In fact, the
implementation SHOULD NOT send DATA or SNMM on stream '0': it should
send them on the same stream that it sends DATA messages for the
affected RC.  This is particularly true if per-stream congestion
windows are used.

I can think of no justification for the "MUST".  And sending SNMM on
stream '0' is counter-indicated.

--brian

Javier Pastor-Balbas (ECE) wrote:                          (Wed, 17 Oct 2001 14:21:45)
> Hi Brian, 
> 
> I think that the TDM network offers less possibilities to get messages in
> the wrong order, doesn't it? Maybe that is the main reason to send these
> messages in a ordered basis...
> 
> Cheers // Javier.
> 
> > [email-masked]

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

---

---

From: Angermayr Manfred <[email-masked]>
Date: Wed, 17 Oct 2001 15:08:42 +0200

Hello Brian,
in ITU Q.706 you can find 'Not more than one in 10000000000 messages will be delivered out-of-sequence to the User Parts due to failure in the MTP. This value also includes duplication of messages.' 
I don't think you can call this a quite easy reordering.

Regards,
Manfred

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Mittwoch, 17. Oktober 2001 14:49
An: sigtran
Cc: [email-masked]
Betreff: Re: DUNA, DAVA, SCON and DRST

Javier,

--brian

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

---
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: Wed, 17 Oct 2001 13:38:02 -0500

Manfred,

Just learning SS7?

That objective only applies to messages that are sent with the
same SLS value.  Messages sent with different SLS values have
no such assurance.  TFP/TFA messages (particularly broadcasts)
can be loadshared over the SLS range and have no assurance of
sequencing.

Quite frankly it is directly equivalent to sending DUNA/DAVA
with the Unordered bit set.

--brian

Angermayr Manfred wrote:                                (Wed, 17 Oct 2001 15:08:42)
> Hello Brian,
>
> in ITU Q.706 you can find 'Not more than one in 10000000000 messages will be
> delivered out-of-sequence to the User Parts due to failure in the MTP. This
> value also includes duplication of messages.' I don't think you can call
> this a quite easy reordering.
> 
> Regards,
> Manfred
> 

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

---