Subject: [Sigtran] M2PA T7 timer again

From: Tom George <[email-masked]>
Date: Tue, 01 Apr 2003 17:15:39 -0600

I am sorry to bring this up again, but a co-worker was reading the M2PA
draft and questioned me about why we had made T7 a per-message timer in
M2PA. 

I showed him the thread where we discussed this. The problem was that
with a single T7 timer following the MTP2 requirements, there could be
an unbounded delay on the ack of any given message. (See below.)

He said that it was possible (though unlikely) that this scenario could
happen in MTP2, because of a retransmission. Nevertheless MTP2 does not
require a per-message T7 timer. 

He is of the opinion that by setting SCTP parameters appropriately (not
to the recommended values in the SCTP RFC), one can achieve the same
effect as with the T7 timer. 

Comments are welcome. 

tomG.

Here was the message that started the discussion last year. 
On Thu, 26 Sep 2002 "May, Howard" wrote:
Subject:  [Sigtran] M2PA V6: T7
> 
> Hi,
> 
> Please can you clarify my understanding of T7 by commenting on the following sequence of events as seen by one end of an M2PA link.
> 
> Let us pretend T7 is configured with a value of second.
> ***********************
> The M2PA link comes into service.
> Data Message 1 is transmitted and T7 is started
> Data Message 2 is transmitted
> Data Message 3 is transmitted
> 900 ms passes
> Data Message 1 is acknowledged and T7 is restarted
> 900 ms passes
> Data Message 2 is acknowledged and T7 is restarted
> 900 ms passes
> Data Message 3 is acknowledged
> ************************
> 
> Thank you
> 
> Howard

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 1 Apr 2003 19:28:04 -0700

Tom,

Fiddling with SCTP parameters has its own problems.  See the SCTP
applicability statement.  In general SCTP applications should no mess
with SCTP parameters to avoid implementing application-level timers.

The very reason we put acknowledgement into M2PA was because pushing
SCTP acknowledgements to the task was harmful to the transport protocol.
The cost to the transport protocol outweight putting a simple ack
mechanism into M2PA.

The same is true for pushing SCTP protocol parameters in an attempt to
avoid M2PA excessive delay of acknowledgement determination.  SCTP is no
longer doing the ack, M2PA is, so it is better for M2PA to time the ack.

Perhaps your co-worker could tell us this magic setting of SCTP
parameters which was not contributed to the SCTP applicability statement
or the SIGTRAN applicability statement?  Also and indication of what
environments such an approach is limited to?  (Let's see... would it
have anything to do with making SCTP act like a "wire"?)

Also, the result of the thread of discussion on T7 was not that one had
to implement per-message timers.  That would be an implementation
decision.  One need merely keep track of the age of the oldest message
in the retransmission buffer.  A single timer can still be used,
restarted to the value of T7 (e.g. 1 second) minus the age of the new
oldest message in the RTB when the previous oldest message(s) are acked.
It is not a big deal.  Messing with SCTP protocol parameters is.

IMHO we shoulds stick with what we agreed to on the thread.  We all gave
it careful consideration then, and arrived at some consensus.

--brian

Tom George wrote:                                                                      (Tue, 01 Apr 2003 17:15:39)

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

---

From: Tom George <[email-masked]>
Date: Wed, 02 Apr 2003 10:32:38 -0600

Brian,

I am for keeping the T7 timer as we agreed, too.

But just to clarify: Can the scenario in Howard's message happen in
MTP2? Is there some reason that it can be ignored in MTP2 (but not
M2PA)?

Thanks,
tomG.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 2 Apr 2003 10:08:44 -0700

Tom,

MTP2 does not trickle out acknowledgements in the manner shown.

SCTP might.

--brian

Tom George wrote:                                                                      (Wed, 02 Apr 2003 10:32:38)

---

From: David Lehmann <[email-masked]>
Date: Thu, 03 Apr 2003 09:30:09 -0500

> with SCTP parameters to avoid implementing application-level timers.

So the authors are recommending (requiring?) that M2PA implementations
use the default SCTP parameters as specified in RFC 2960, section 14?

(My understanding was that those parameters were designed
to make SCTP Internet friendly and not necessarily to preclude
SCTP users from fiddling to meet certain timing requirements.)

Also, can you be more specific about which section of the SCTP
applicability statement to which you are referring?

-- 

David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 3 Apr 2003 08:21:07 -0700

David,

David Lehmann wrote:                                                                 (Thu, 03 Apr 2003 09:30:09)
> use the default SCTP parameters as specified in RFC 2960, section 14?

I don't see any reason why M2PA cannot work with those settings.

Do you?

Also, the settings cannot be negotiated and the one end of the
link cannot place requirements outside the recommended range onto
the other end of the link.

> SCTP users from fiddling to meet certain timing requirements.)

What network need not be Internet friendly?

What IETF standard cannot be?

> applicability statement to which you are referring?

draft-ietf-sigtran-signalling-over-sctp-applic-07.txt sections 3.1,
3.2, 3.3, 3.4.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 3 Apr 2003 09:42:22 -0800 (PST)

Brian,
Please see some comments/questions below.
(not with the intention of starting T7 discussions
again, personally I still don't think that diversion
from MTP2 about how to use T7 was necessary at least
not mandatory)
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> David Lehmann wrote:                                
>                                 (Thu, 03 Apr 2003
> 09:30:09)
[TOLGA]I wouldn't use receommended values in RFC2960,
because I prefer to detect remote host failures as
quick as possible (not with T7) by adjusting SCTP
parameters, considering that I have a low latency IP
network.
> the other end of the link.
[TOLGA]Those are just recommended values for the big-I
Internet case. In a private network, one is free to
choose any value for those parameters and I would
consider this configuration rather than putting
requirement on a remote peer.
> What IETF standard cannot be?
[TOLGA]It is clear that IETF documents should consider
the big-I Internet case, but this is exactly the
reason why those recommended values are for the big-I
Internet case and are not necessarily
suitable/mandatory for private IP network case.

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 3 Apr 2003 11:13:38 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 03 Apr 2003 09:42:22)
> parameters, considering that I have a low latency IP

That's not a reason why M2PA cannot work with section 14
settings.  Do you see any reason why M2PA cannot work with
section 14 settings?

> requirement on a remote peer.

Sack delay at the peer can be 500 ms regardless of the latency
of your network.  Are you sure you are not placing requirements
on the peer by deviating from the recommended values?  What
values are you using?

> suitable/mandatory for private IP network case.

So, M2PA, being an IETF document, should also consider the big-I
case?  If M2PA cannot work on the big-I, why are we writing an
IETF document?

And what do we really mean by the big-I case?  Is it not
sufficient that TCP uses the same network (whether intranet or
internet)?  Adjusting SCTP parameters would then cause SCTP to
compete harmfully with TCP on the same network to the detriment
and degradation of TCP users.  Isn't it enough that some
"intranet" and "internet" traffic shares the same backbone?
M2PA was meant to be run between nodes at a distance from each
other.  Who owns a backbone that doesn't carry big-I traffic?

Does not draft-ietf-sigtran-signalling-over-sctp-applic-07.txt
speak to this?  Why did you not comment on this draft at LC if
you felt so strongly that the recommended parameters were so
unusable?

I think M2PA has to work with the parameters recommended for
SCTP.  As it may take minutes for SCTP to detect failures with
recommended parameters, T7 or some equivalent is necessary.  RFC
2960 does discuss message life times.  A per-message T7 could
easily be accomplished by setting the life time on each message
to T7.  Then M2PA does not depend upon deviating from
recommended parameters.  It will function equally well (all
other things being the same) regardless of whether it is your
low latency "intranet" or the big-I, or both running on the same
backbone.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 3 Apr 2003 12:51:16 -0800 (PST)

Brian,

[..snip..]
> settings.  Do you see any reason why M2PA cannot
[TOLGA] I just said, I would rely on adjusting SCTP
parameters to detect loss of association.

[..snip..]
> on the peer by deviating from the recommended
[TOLGA]I would consider using delayed acknowledgement
or not and if used the maximum acknowledgement delay
again as configuration options.

[..snip..]
> other.  Who owns a backbone that doesn't carry big-I
[TOLGA]IMO, important is whether one is operating in a
controlled network (probably a VPN) or in
uncontrolled/best-effort big-I Internet. 
I think, it is not a problem, if backbone is carrying
also Internet traffic,as long as the network itself is
controllable.
Yes, one could have a network where SIGTRAN traffic
has priority over Internet traffic, but I would
consider this network planning, rather than an
unintentional side effect.

[..snip..]
> low latency "intranet" or the big-I, or both running
[TOLGA]As far as I can see, using T7 as life time
value for SCTP messages won't work. Life time will
have a meaning only till the message can be sent from
the local SCTP and won't have anything to do with any
acknowledgement (even not on SCTP level) received for
that message (or maybe you mean something else?)
My opinion is, using T7 just for excessive delay of
acknowledgement is a good idea. As I said above, to
detect loss of association I would prefer to use SCTP
parameters. Of course, if one wants to use values as
referred in Secion14 of RFC2960, I can't say it is
forbidden. In such a case before one can detect loss
of association, association will be dropped because of
T7 expiry.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 3 Apr 2003 17:29:13 -0700

Tolga,

Please see comments below...

Tolga Asveren wrote:                                                                 (Thu, 03 Apr 2003 12:51:16)
> > That's not a reason why M2PA cannot work with
> > section 14 settings.  Do you see any reason why M2PA
> > cannot work with section 14 settings?

So do you think there is a reason why M2PA cannot work
with section 14 settings?  If so, what are those
reasons?

> 
> [..snip..]
> > Sack delay at the peer can be 500 ms regardless of
> > the latency of your network.  Are you sure you are
> > not placing requirements on the peer by deviating
> > from the recommended values?  What values are you
> > using?

That would be placing a requirement on the other end:
i.e, that it not use delayed acknowledgement when it is
an integral part of SCTP.

> 
> [..snip..]
> > So, M2PA, being an IETF document, should also
> > consider the big-I case?  If M2PA cannot work on the
> > big-I, why are we writing an IETF document?
> > 
> > And what do we really mean by the big-I case?  Is it
> > not sufficient that TCP uses the same network
> > (whether intranet or internet)?  Adjusting SCTP
> > parameters would then cause SCTP to compete
> > harmfully with TCP on the same network to the
> > detriment and degradation of TCP users.  Isn't it
> > enough that some "intranet" and "internet" traffic
> > shares the same backbone?  M2PA was meant to be run
> > between nodes at a distance from each other.  Who
> > owns a backbone that doesn't carry big-I traffic?

Is there any network that does not ultimately access or
share capacity with the big-I?  If there exists one, it
is not the concern of the IETF.

> also Internet traffic,as long as the network itself is

If you have QoS guarantees, you don't need SCTP.

> unintentional side effect.

So design your protocol for your network how you like.
M2PA is designed for the internet.

> 
> [..snip..]
> > 
> > I think M2PA has to work with the parameters
> > recommended for SCTP.  As it may take minutes for
> > SCTP to detect failures with recommended parameters,
> > T7 or some equivalent is necessary.  RFC 2960 does
> > discuss message life times.  A per-message T7 could
> > easily be accomplished by setting the life time on
> > each message to T7.  Then M2PA does not depend upon
> > deviating from recommended parameters.  It will
> > function equally well (all other things being the
> > same) regardless of whether it is your low latency
> > "intranet" or the big-I, or both running on the same
> > backbone.

Couple that with PR-SCTP to handle lifetimes in SCTP
retransmit buffer and the TB/RTB from SCTP is
effectively incorporated into M2PA.  Not requiring this
and permitting the application to implement its own
timer(s) just makes sense.

> parameters.

I think you misunderstand lifetimes.  Just because a
lifetime expires does not mean that the association is
torn down.  SCTP still determines when the association
is dead.  Lifetimes just inform the ULP when SCTP is not
meeting its expectations.

> Of course, if one wants to use values as referred in
> Secion14 of RFC2960, I can't say it is forbidden. In
> such a case before one can detect loss of association,
> association will be dropped because of T7 expiry.

You do not understand how M2PA works: M2PA's response to
T7 expiry is not to take down the SCTP association but
to place the (SS7) link out of service.  This has the
benefit of not necessarily going again through slow
start if the SCTP association remains viable.

Refer to Figure 7 in M2PA-07.  SCTP Comm Error and SCTP
Comm Lost are events separate and distinct from T7
expiry.

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 4 Apr 2003 15:13:22 -0800 (PST)

Brian,

   Tolga

[..snip..]

> meeting its expectations.
[TOLGA] What I meant was dropping of association(which
in fact should be putting link out of service as you
indicated) because of M2PA T7 expiry, not because of
life time expiry in SCTP.

[..snip..]
> Comm Lost are events separate and distinct from T7
[TOLGA]Let's assume one is using SCTP parameters as
recommended in RFC2960. When the association is lost,
first T7 of M2PA will expire, so link will be taken
out of service. Then again intial alignment will take
place. T2 (let's assume T2=5s) will expire, link will
be out of service, then again initial alignment
procedure. This will continue, till SCTP detects that
association is lost. Basically what I see is, it is
not a good idea to use RFC2960 recommended values, I
think relying to T7 does not help too much
here(afterall it is to detect excessive delay of
acknowledgement, not to detect loss of association).
I also have some questions about usefullness of not
dropping association when T7 expires, to bypass
slowstart procedure. Let's assume T2 expires (and
let's furthermore assume association is not lost)Link
alignment will take place. And most probably till link
alignment procedure is completed, most of the SCTP
messages sent before T2 expiry will be acknowledged, 
decreasing flightsize and because of
      if((flightsize + Max.Burst*MTU) < cwnd)
         cwnd = flightsize + Max.Burst*MTU

cwnd will still shrink, as far as I can see.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 4 Apr 2003 16:47:50 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 04 Apr 2003 15:13:22)
> acknowledgement, not to detect loss of association).

Your statements about how links are realigned are not correct.
Links are not immediately realligned after failure of alignment
attempts.  Failure to align causes the link to be put into
suspension for an interval and further alignement attempts will
not occur until the suspension period expires at MTP3.  Normal
selection of probation and suspension times at MTP3 will result
in the SCTP loss being detected before too many alignment
reattempts are made.  See ITU-T T17(0.8-1.5 sec) ANSI T32(5-120
sec), T33(60-600 sec) and T34(5-120 sec).  ITU-T flavors would
likely reattempt alignment every T17, or every 0.8-1.5 seconds,
(but only twice) before management is notified and manual
intervention is required on the link.  ANSI flavors  will
reattempt event T32/T34 5-120 sec (but only twice) before
management is notified and manual intervention required on the
link.

> cwnd will still shrink, as far as I can see.

Sorry but we already agreed to no drop SCTP associations when
links are put out of service for number of reasons.  Look back
in the archives to see the discussion.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 6 Apr 2003 14:11:15 -0700 (PDT)

Brian,

[..snip..]
> management is notified and manual intervention
[TOLGA]Considering that with recommended values in
SCTP2960 it might take many minutes to detect loss of
association and value for T17 in Q.704 is between
800-1500 ms, and for T2 10s as recommended value in
M2PA, I think, one migth try a lot of useless
alignment attempts, when SCTP association is lost.
(That MTP3 will try only twice to align the link is
coming from which section of Q.704? (just a question))
Furthermore Q.704 12.2.1.2 says
"The value of T17 should be greater than the loop
delay and less than timer T2, see 7.3/Q.703."
With RFC2960 recommended values, one can't assure this
-that T17 should be greater than loop delay part-. I
agree that plain SCTP parameters don't assure
roundtrip guarantees for single messages but without
PR-SCTP, adjusting SCTP parameters -and not using
RFC2960 recommended values- seems the best one can do
to comply with the above statement from Q.704.
> in the archives to see the discussion.
[TOLGA]As far as I remember the other reason was to
prevent any problems related with collision of
association initialization attempts from both sides.
If we are really sure that there are problem cases,
then I would think SCTP itself is the correct place to
address them.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 6 Apr 2003 15:31:43 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Sun, 06 Apr 2003 14:11:15)
> to comply with the above statement from Q.704.

Read Q.704 and T1.111.4.  There will not be "a lot" of
useless alignement attempts.  The procedures to prevent
oscillation of link alignment attempts will be sufficient.
Setting T17 to the normal loop delay will suffice.  Even
real SS7 links could exhibit greater than normal delay
in failure scenarios.  In SS7, MTP2 does not do all the
work.  MTP3 is the one responsible for aligning and
restoring links.

> then I would think SCTP itself is the correct place to

There is no collision problem.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 7 Apr 2003 12:04:13 -0700 (PDT)

Brian,

[..snip..]
> work.  MTP3 is the one responsible for aligning and
[TOLGA]What I see from Q.704 12.2.1.2 is until there
is manual intervention, every T17+T2(MTP2), a new link
restoration attempt will be done.
Also, don't we need to monitor the delay on SCTP
association -by adjusting SCTP parameters to proper
values- so that we can know that T17 is greater than
the actuasl loop delay, as indicated in Q.704? 

[..snip..]
> There is no collision problem.
[TOLGA]In the thread "M2PA v6: Two Out of Three Valid
BSN" in October2002 you presented cwnd shrinking and 
possible problems during association reestablishment
when ABORT from one side is lost, as reasons why not
dropping SCTP association when link failure happens is
a good idea. Now it seems to me that this won't help
too much to prevent cwnd shrinking and as I said
before, if we think that there might be some problems
during association reestablishment, this IMO is an
issue for SCTP itself. (probably there are other
threads about this topic, but it really would help if
you briefly inform us about other reasons for not
dropping the association)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Apr 2003 17:18:46 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Mon, 07 Apr 2003 12:04:13)
> the actuasl loop delay, as indicated in Q.704? 

See T1.111.4.

Q.704 does not measure loop delay, although it is
variable in the traditional case as well.

> dropping the association)

Perhap you could inform us some reasons for dropping it.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 8 Apr 2003 13:32:57 -0700 (PDT)

Brian,

[..snip..]
> variable in the traditional case as well.
[TOLGA]But it is variable between very tight bounds
assured by physicall characteristics of the medium. 

[..snip..]
> Perhap you could inform us some reasons for dropping
[TOLGA]Let me try. In 4.2.1 we have:
"M2PA SHOULD follow the criterion of Q.703 [Q.703],
section 5.3.1 for
incorrect BSNs: If any two BSNs in three consecutively
received User
Data messages are not the same as the previous one or
any of the FSNs
of the User Data messages in the M2PA transmit buffer
at the time they
are received, then MTP3 SHOULD be informed that the
link is faulty."
Now, isn't it possible that after link is dropped and
put again in service, SCTP messages belonging to the
old link context arrive and that they have different
BSN values from each other, which are not the same to
FSN of any messages in the transmit buffer of the
receiving M2PA? In such a case, link will be put again
out of service. IMO, dropping SCTP association when
link failure is detected, will prevent this.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Apr 2003 03:24:07 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Tue, 08 Apr 2003 13:32:57)
> assured by physicall characteristics of the medium. 

Not for satellite.

> link failure is detected, will prevent this. 

So what?  The connection is faulty.

With ANSI T1.111.4 the link will be put on suspension for
as long as 5 minutes before another attempt is made to
align the link.

With PR-SCTP the sender of these "stuck" MSUs could
recall them with an FSN.

Stuck packets was a reason to keep the 2 out of 3 rule.
It is not reason to drop the SCTP association.  Quite
the opposite: if the SCTP association were to be dropped,
M2PA could not detect such a "stuck packet" situation
and would assume that a SCTP association of good quality
exists where it indeed does not.

Do you have any other reasons?

--brian