Subject: M3UA v9: SCON message handling

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

In Section 3.4.4:

  The Affected Point Code parameter can be used to indicate congestion 
  of multiple destinations or ranges of destinations.  However, an 
  SCON message MUST not be delayed to "collect" individual congested 
  destinations into a single SCON message as any delay might affect 
  the timing of congestion indications to the M3UA Users.  One use for 
  including a range of Congested DPCs is when the SG supports an ANSI 
  cluster route set to the SS7 network that becomes congested due to 
  outgoing link set congestion. 

This MUST has to be removed.  M3UA does not address performance
concerns whatsoever and should not be establishing requirements
with regard to "delay".  Whatever dealys are interoducted by an
implementation is the business of the implementation and not to
be required in the spec.  Change to:

  "However, an implementation may choose to not delay the SCON to
   collect individual congestion destinations into a single SCON
   message might affect timingin of congestion indications to M3UA
   Users."

Or, better still, remove the sentence altogether.

--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: Greg Sidebottom <[email-masked]>
Date: Tue, 16 Oct 2001 16:50:31 -0400

Hi Brian,

See below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Thursday, October 11, 2001 4:15 PM
Subject: M3UA v9: SCON message handling

> Or, better still, remove the sentence altogether.

[Greg] Well, I'd certainly agree that the "MUST" is too strong.

This text is from way back but my memory is that it was felt that for the
ITU international congestion method, delaying indications may cause problems
for ISUP procedures and also for the ITU SCCP congestion method where I
believe timers are running (?).    Its been a while since I read the ITU
ISUP and SCCP congestion procedures so I might be wrong - maybe Richard
Adams remembers the discussion with BT?   In any case, the intention was not
to establish or meet a specific delay requirement but rather to get the
congestion indications to the MTP3-User as quickly as possible so as to mesh
better with the MTP3-User congestion procedures.  If some implementations
can collect indications and still get the SCON out without affecting the
MTP3-User procedures then I agree that "MUST" is not necessary.

But I don't think the sentence should be removed.  I could live with your
replacement sentence although I must say it seems a little bit weak to me.
I think that that implementations that choose to delay SCONs do so at some
peril, at least for some MTP3-User protocol versions/variants.   The
proposal seems to imply that a normal implementation would delay the SCON to
hopefully collect multiple indications and that some implementers may choose
to not delay the SCON for some undescribed cases.  This to me implies a
preference for a particular implementation.

But if nobody else has an issue with the text I can make the change.
Comments?

Cheers,

   Greg

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 17:55:54 -0500

Greg,

Your argument is based on "delay" which is a performance
consideration which is implementation dependent and outside
the scope of the draft.  There should be no MUSTs with
regard to performance.  That is the implementation's choice
and domain.  Remove it, it is an implementation consideration.

--brian

Greg Sidebottom wrote:                                       (Tue, 16 Oct 2001 16:50:31)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Wed, 17 Oct 2001 00:42:47 -0400

Hi Brian,

I'm confused - You proposed two options A (changing the sentence) and B
(removing the sentence) for this issue.  I said I could live with option A.
Then you come back and say it must be B.  If I didn't know better I'd say
you were pulling my chain 2;^)

More below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, October 16, 2001 6:55 PM
Subject: Re: M3UA v9: SCON message handling

> the scope of the draft.

[Greg2] I'm not seeing your point - are you really saying that we cannot
consider timing issues in the design of a protocol?   My argument was based
on not introducing an extra delay for the indications as this may in some
cases affect the congestion mechanisms of the user protocols.  That doesn't
seem to me to be implementation dependent.

There should be no MUSTs with
> regard to performance.

[Greg2] I already agreed to removing the MUST.  Your text proposal does not
contain a "MUST", only a "may".  Like I said I could live with that.

Cheers,

   Greg

That is the implementation's choice
> > To unsubscribe send a blank email to
[email-masked]
>
> --
> 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 00:20:49 -0500

Greg,

Greg Sidebottom wrote:                                       (Wed, 17 Oct 2001 00:42:47)
> seem to me to be implementation dependent.

I have no problems with mentioning delay considerations as an implementation
note.  It is the "MUST" that I object to.  It is rather foolish to say
that something "MUST" happen somewhere inside an unspecified implementation
specific function.  "MUST" is an RFC keyword which has to do with
interoperability requirements.  Certainly if an implementation decides to
delay to collect a few SCONs it is on its own merits to do so as the
implementation is responsible for performance (not the draft).

How about changing "MUST not" to "is not required to".

(It is just the RFC keyword that has to go.)

This brings up another point: particularly in the M3UA draft there are a
lot of places where the draft talks about tips or hints at implementation
(largely for clarification) and I agree with that because it makes the
draft more understandable: however, implementation notes and requirements
should be clearly separated.  RFC 2960 is really good for this.  It even
goes to the extent of placing "IMPLEMENTATION NOTE:" in front of such
ancillary comments.  They are clearly delineated as assisting with
understanding rather than providing requirements.

This is one of a large number of cases (over the last number of versions)
of M3UA where the RFC keyword "MUST" or "SHOULD" has found its way into
an implementation note.  Sometimes they have been replaced with MAY, but
I think I hounded you and the WG on TFCs and things until all the keywords
were removed from implementation-specific examples.

Could we mark these statements clearly with "IMPLEMENTATION NOTE:"
or "EXAMPLE:" or some such and ensure that there are no RFC keywords
in such passages?

--brian

> 
> 
> There should be no MUSTs with regard to performance.
> 

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Wed, 17 Oct 2001 01:48:56 -0400

Hi Brian ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 17, 2001 1:20 AM
Subject: Re: M3UA v9: SCON message handling

> (It is just the RFC keyword that has to go.)

[Greg3] Agreed.

> or "EXAMPLE:" or some such and ensure that there are no RFC keywords

[Greg] Sure - sounds like an excellent idea!  There are a couple of
Implementation Notes like this already, based on your previous input
(Sections 1.4.2.5 and 4.5.2.1).  If you have time can you point out other
places where this would be appropriate?   I'll try to run through the text
as well.  I guess we can start with an IMPLEMENTATION NOTE for the offending
text in Section 3.4.4    2;^)

Thanks,

   Greg

> > > Greg Sidebottom wrote:                                       (Tue, 16
Oct
> > 2001 16:50:31)

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 01:09:00 -0500

Greg,

Greg Sidebottom wrote:                                       (Wed, 17 Oct 2001 01:48:56)

[snip]
> > (It is just the RFC keyword that has to go.)

Good.

> text in Section 3.4.4    2;^)

Actually, if they are clearly delineated, it might be an idea to add a few.
That might thwart a lot of questions and confusions which have almost called
for a FAQ on M3UA.  I can make a list of sections and paragraphs and submit
them to you for the next incarnation, but really, this separation could also
be done with the draft closer towards IESG Last Call.  (Really just i. and t+)

--brian

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

---

---

From: [email-masked]
Date: Wed, 17 Oct 2001 16:54:08 +0100

Greg, Brian,

The 'must not' is required and is not an implementation dependant issue.
Saying that the SCON is 'not required to be delayed to collect individual
congested destinations into a single SCON' is not strong enough. 

The SS7 user parts expect congestion notifications within a set time and act
according to the frequency of receipt of these. Delaying the sending of the
SCON message (for whatever reason) could distort the TFC rate/frequency
which would destroy the function of the SS7 flow control. Obviously,
anything that could cause this needs to be avoided. This therefore cannot be
classified as implementation dependant, as any implementation that cannot
ensure that its congestion notification supports the SS7 flow control is not
providing an adequate MTP3 user adaptation layer. The approach to congestion
notification to the SS7 user parts needs to be consistent across
implementations.

I know this sounds a bit strong, but it needs to be kept in mind that in all
cases the SS7 user part functionality needs to be maintained, and within its
current timer ranges. This is not implementation negotiable.

I suggest the text relating to this remains as previously specified,
'... However, an SCON message must not be delayed to "collect" individual
congested destinations into a single SCON message as any delay might affect
the timing of congestion indications to the M3UA users....'.

Regards,

Karen

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]]
Sent: 17 October 2001 06:49
To: sigtran
Cc: bidulock
Subject: Re: M3UA v9: SCON message handling

Hi Brian ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 17, 2001 1:20 AM
Subject: Re: M3UA v9: SCON message handling

[Greg3] Agreed.

Thanks,

   Greg

Oct

---
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 14:14:09 -0500

karen.d.king,

Performance issues and thus delay is outside the scope of the
draft and the draft cannot place RFC keyword requirements on
things that are out of scope.

How much delay is acceptable?  1ms?  10ms?  2sec?

Well that would be IMPLEMENTATION DEPENDENT, now, wouldn't it?

--brian

[email-masked] wrote:                           (Wed, 17 Oct 2001 16:54:08)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: [email-masked]
Date: Fri, 19 Oct 2001 09:42:21 +0100

Brian,

I can't agree with you. 

Ensuring the correct operation of the SS7 flow control is neither a
performance nor implementation issue. An indication of congestion must be
given to the SS7 user parts in the same manner as they would have expected
from the MTP3, anything else is unacceptable. 

M3UA must work within the timer and functionality constraints of the upper
layer protocol it's supporting. This isn't a performance, but a functional
requirement. The rate of the congestion indications to the upper layers are
important. Any distortion of this (for example, delaying some to collect
multiple DPCs, whilst sending others immediately) could mean that the wrong
level of congestion control is used.

The scope of the document is to provide an interface to SS7 user parts, to
ensure their functionality is maintained - this is therefore within scope.

Regards,

Karen

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: 17 October 2001 20:14
To: [email-masked]
Cc: sigtran
Subject: Re: M3UA v9: SCON message handling

karen.d.king,

--brian

[email-masked] wrote:                           (Wed, 17 Oct 2001
16:54:08)
> > Greg Sidebottom wrote:                                       (Wed, 17
Oct
> 2001 00:42:47)
> > > (removing the sentence) for this issue.  I said I could live with
option
> A.
> > > [Greg2] I already agreed to removing the MUST.  Your text proposal
does
> not
> > > > > >   the timing of congestion indications to the M3UA Users.  One
use
> for
> > > > > >   cluster route set to the SS7 network that becomes congested
due
> to
> > > > > ITU international congestion method, delaying indications may
cause
> problems
> > > > > believe timers are running (?).    Its been a while since I read
the
> ITU
> > > > > Adams remembers the discussion with BT?   In any case, the
intention
> was not
> > > > > to establish or meet a specific delay requirement but rather to
get
> the
> > > > > congestion indications to the MTP3-User as quickly as possible so
as
> to mesh
> > > > > can collect indications and still get the SCON out without
affecting
> the
> > > > > But I don't think the sentence should be removed.  I could live
with
> your
> > > > > replacement sentence although I must say it seems a little bit
weak
> to me.
> > > > > proposal seems to imply that a normal implementation would delay
the
> SCON to

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 19 Oct 2001 04:08:37 -0500

Karen,

Please see comments below...

[email-masked] wrote:                           (Fri, 19 Oct 2001 09:42:21)

You say:

> > which would destroy the function of the SS7 flow control.

Gee, I have searched the SS7 standards specifications and can't see any
requirements (or even objectives) placed on delay from the moment that
congestion occurs somewhere in the network to the moment that the user
is notified.

Please instruct me on where in the specs this occurs?

I did not see that any of the queuing models included congestion at all.

Please instruct me on what queuing model equations you used to arrive
at this conclusion.

The SS7 specs tell me that a user may or may not even receive an MTP-STATUS
indication because it depends on the exact path taken by the user's last
message through the SS7 network.  So SCON will be like a "sampling" of the
path congestion status, and yet you seem to believe that somewhere there
are these hard delay requirements.  Please instruct me an point me to where
these requirements have been documented as an SS7 user expectation.

> requirement.

Why do you keep saying "delay," "timer," "congestion" and yet say that
this is not a performance issue?

> The rate of the congestion indications to the upper layers are
> important.

Delay does not affect rate.

> Any distortion of this (for example, delaying some to collect multiple DPCs,
> whilst sending others immediately) could mean that the wrong level of
> congestion control is used.

Bull.  The rate at which a user sends messages changes the rate at which
congestion status is sampled and returned to the user.

> ensure their functionality is maintained - this is therefore within scope.

It is not only out of scope, your perception of need is blurred and not
in line with SS7 specifications.  This is not how things work in the
SS7 network.  There is no reason to place these concocted requirements on
M3UA.

--brian

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

---

---

From: [email-masked]
Date: Fri, 19 Oct 2001 13:58:53 +0100

Brian,

Now I'm concerned - you previously had no problem with the technical reason
why you wouldn't want to delay a SCON message, but were worried about
whether 'must' implied an implementation method. What's made you change your
mind?

Regards,

Karen

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: 19 October 2001 10:09
To: sigtran
Subject: Re: M3UA v9: SCON message handling

Karen,

[email-masked] wrote:                           (Fri, 19 Oct 2001
09:42:21)

--brian

> > > > I'm confused - You proposed two options A (changing the sentence)
and
> B
> > > > Then you come back and say it must be B.  If I didn't know better
I'd
> > say
> > > > consider timing issues in the design of a protocol?   My argument
was
> > based
> > > > > > >   of multiple destinations or ranges of destinations.
However,
> an
> > > > > > >   including a range of Congested DPCs is when the SG supports
an
> > ANSI
> > > > > > This text is from way back but my memory is that it was felt
that
> > for the
> > > > > > I think that that implementations that choose to delay SCONs do
so
> > at some
> > > > > > hopefully collect multiple indications and that some
implementers
> > may choose

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

---

---

---

From: Greg Sidebottom <[email-masked]>
Date: Fri, 19 Oct 2001 14:40:50 -0400

Hi Karen, Brian,

Lets not get into a detailed discussion on congestion in SS7 networks and
standards - it is a "fertile" area of discussion with multiple methods and
understandings    2;^)

The issue as I see it really doesn't have anything to do with congestion
detection and delays and performance in SS7 networks.  It simply comes down
to when the MTP3 at an SG determines that it must send a congestion
indication up to the MTP3-User, how can that happen so that the MTP3-User
reactions are appropriate?  The MTP3 determines when to send an indication
up based on the criteria based on the relevant spec and we do not need to
re-describe it.  So the number and rate of indications are irrelevant to
M3UA - the issue to me is only delay and distribution in time.

There is no guidance in the SS7 specs (with the possible exception of North
American Telcordia GR-606 and GR-82?) but most people would probably imply
that an indication would be sent up "immediately".  But what does that
really mean?  To me this is implementation dependent - how fast this is done
today in SS7 nodes varies by implementation depending on their architecture
and internal protocols.   Because the current MTP3 to MTP3-User interface is
internal to a node and is not seen, and seems to work, we assume the best.

But in Sigtran the MTP3 to MTP3-User interface is to some extent now
exposed.  The rate of indications across the interface is the same but the
delay and distribution in time of the indications to the MTP3-User may be
"perturbed", compared to the current internal interfaces.   Now, on top of
that the protocol allows the possibility that the indications can be grouped
in a single message.   To take advantage of this, can an implementation hold
an indication in the hopes that I get another one quickly and send them
across the network together?   If so, how long can it wait: 1 msec, 10 msec,
100 msec, ...?  At what point will these perturbations (!) cause a problem
for the congestion algorithm of the MTP3-User?

I dare say that we don't know the answer.   Some implementations will
probably play it safe and not wait to group separate indications into single
message, if only to eliminate one variable.   But I don't think that we can
say for certain that an implementation cannot delay/group.  That is
essentially what the "MUST" in Issue 9 is saying, that an implementation
cannot delay/group.  This is why I agreed with Brian that we should get rid
of the MUST and put the point in an Implementation Note.  I agree with Karen
that it is now a little weak (I said as much before) but I can't see another
way as it really can't be a requirement.

Hope this helps,

    Greg Sidebottom

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Friday, October 19, 2001 5:08 AM
Subject: Re: M3UA v9: SCON message handling

09:42:21)
and
I'd
was
> > > based
> > > > > on not introducing an extra delay for the indications as this may
in
> > > some
> > > > > cases affect the congestion mechanisms of the user protocols.
That
> > > doesn't
> > > > interoperability requirements.  Certainly if an implementation
decides
> > > > > > Greg Sidebottom wrote:
(Tue,
> > 16
However,
> > > > > > > >   including a range of Congested DPCs is when the SG
supports an
> > > > > > > >   "However, an implementation may choose to not delay the
SCON
> > > > > > > >    message might affect timingin of congestion indications
to
> > M3UA
that
> > > > > > > for ISUP procedures and also for the ITU SCCP congestion
method
> > > where I
> > > > > > > ISUP and SCCP congestion procedures so I might be wrong -
maybe
> > > Richard
> > > > > > > I think that that implementations that choose to delay SCONs
do so
implementers

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 19 Oct 2001 13:51:19 -0500

Karen,

I have no problem with this being mentioned as an implementation note.
Remove the RFC keyword MUST and replace it with "could, for example,
choose to", whatever, but the draft cannot presume to tell the implementation
how to behave in this regard.  All SS7 interworking (the NIF function)
is unspecified and out of scope.  The draft can place implementation
notes for clarification with regard to NIF but cannot set RFC level
requirements.  If the NIF is to be specified in such a way there are
far more important delays.

Did you realize that there is no bounded or determinant delay once the
message has already been sent?  SCTP could delay it for up to several
minutes easily using RFC settings before delivering it.  SCTP can do
this for MTP-TRANSFER messages as well, which do have hard delay
objectives set out on the SS7 specifications and queueing model.
With SCTP RFC settings, these objectives can be easily missed.  That
is a "performance" concern that is outside the scope of the spec:
what makes you think that a minor matter of SCON delay is?

--brian

[email-masked] wrote:                           (Fri, 19 Oct 2001 13:58:53)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 19 Oct 2001 15:27:32 -0500

Greg,

As you agree, please consider the original
change proposal on this thread.

--brian

Greg Sidebottom wrote:                          (Fri, 19 Oct 2001 14:40:50)

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

---