Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Fri, 4 Oct 2002 19:58:47 -0400

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 6:37 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> Tolga,
> 
> Tolga Asveren wrote:                              (Fri, 04 
> Oct 2002 16:39:48)
> > > 
> > > It will be a cold day in June before SCTP addresses this. 
>  I tried for
> > > over a year to get bounded delay into SCTP.  But you are 
> welcome to try on
> > > TSVWG.  Until then, M2PA needs T7.
> > [TOLGA]I still think one can control bounded delay for SCTP 
> with RTO.max,
> > Path.Maxretans and Assoc.Maxretrans. With RTO.max=150ms 
> Path.maxretrans=2,
> > Assoc.maxretrans=2, propogation delay will be kept under 
> 900ms (for lost and
> > retransmitted messages, it might be a bit higher with a very small
> > possiblity).
> 
> You are forgetting that successful HEARTBEAT/ACK clears the
> peg counts.
> 
> Even still RTO.max = 150ms is not recommended in the wild.  
> Others have
> found that even 200ms is hard to get down to.  Also 
> Path.Max.Retrans = 2
> and a Assoc.Max.Retrans of 2 (and I assume you mean two 
> interfaces) means
> that your association cannot handle a temporary network delay 
> of 300ms.
[TOLGA]Why do you think it can't handle a delay of 300ms? It will take
150+150+300+300=900ms till the association fails.(Path.MaxRetrans = 2,
Assoc.MaxRetrans = 4, two interfaces)
> This is far too drastic.  M2PA can allow 0.5 to 2.0 seconds but it is
> normally 1 second.  Dropping the association on every 300ms delay will
> cause changeover and increase in message loss and missequencing.
[TOLGA] Association won't be dropped at 300ms but at 900ms.
> 
> So you see, when counting retransmits with sliding window, 
> delay varies
> widely.  The definitive way is to time the message 
> acknowledgement itself
> at the M2PA level (which includes queueing delays in the remote M2PA
> that SCTP is completely unaware of).
> 
> If you set these values too low, you will just make the 
> association more
> brittle than desirable.  If you set them too high excessive delays can
> go undetected.  And with sliding windows there is really no middle
> ground.
[TOLGA]IMO, the values I gave are reasonable, i.e. 150ms is not too low and
900ms is not too high.
> 
> 
> > For the scenario you represented, it will take T7+propogation
> > time and normally I would think propogation delay -let's 
> call it average
> > RTT- around 50ms is not unrealistic. 
> 
> 50ms realistic if all you are doing is traversing the CO 
> floor.  If you
> are out in the wild...
[TOLGA]Do you mean using big-I Internet?(Just now I tried ping -s
www.ietf.org 0%packet loss min/avg/max=21/26/108) I don't think people will
use M2PA in big-I Internet.
> 
> > > 
> > > One more thing you will need to change about SCTP is that 
> it must not be
> > > allowed to clear peg counts when a HEARTBEAT ACK is 
> received.  Good luck
> > > at that too.  (Otherwise HEARTBEAT ACKs can indefinitely 
> pospone dropping
> > > the association due to propagation delays on a single message).
> > [TOLGA] If this happens to be a real problem for somebody, 
> it is possible to
> > turn heartbeat off.
> 
> I don't think that would help M2PA: quite the reverse.  M2PA needs to
> detect link failures during quite periods.  SNTM is widely spaced and
> unsufficient to detect link failures a low traffic levels or during
> quite periods.  MTP2 uses FISUs to detect these failures 
> rapidly.  MTP3
> requirements require that a changeover occur nominally in 0.5 seconds
> from the failure of the link.  The SUERM will detect failures 
> in 128ms.
> If you turn off HEARTBEATS it could be a long time before failures
> are detected.
[TOLGA]For the need for HEARTBEATS I agree. 
> 
> 
> > > 
> > > The mechanism of SCTP allows a stream to become blocked (even
> > > indefinitely) while allowing other streams to proceed.  
> The purpose of
> > > SCTP was to address the stringent delay requirements of signalling
> > > protocols.  Well, it doesn't really do that.  Fortunately 
> M2PA has acks
> > > and can determine end-to-end delays itself.  Thus T7.  
> SCTP cannot even
> > > provide M2PA with ULP acks and flow control, did you 
> think that it was
> > > going to somehow monitor ULP ack delay?
> > > 
> > > > Furthermore, even currently the situation is still not 
> very different than
> > > > from MTP2 case. One still needs to wait for the worst 
> case T7+propogation
> > > > delay, regardles whether MTP2 or M2PA is used.  
> > > 
> > > For MTP2: T7 >> PD is always true
> > > For M2PA: T7 << PD is possible and expected
> > [TOLGA] I disagree that for M2PA T7 << PD is to be 
> expected. One should have
> > a better IP network to run M2PA.
> 
> But neither M2PA nor SCTP will state how good the IP network 
> needs to be.
[TOLGA] It is not a suprise that SCTP does not say anything about it,
because necessary IP network quality depends on the need of the application.
Maybe M2PA should say that characteristics of the IP network are a very
important factor to meet SS7 requirements.
> --brian
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 4 Oct 2002 19:17:45 -0600

Tolga,

Sorry for the lengthly response: but you persist ;)

Tolga Asveren wrote:                                                                 (Fri, 04 Oct 2002 19:58:47)
> Assoc.MaxRetrans = 4, two interfaces)

Read above--you said: Assoc.MaxRetrans = 2.

Also, you calculation may be wrong unless you also in RTO.Min at 150ms
(which would be rather worthless).  Also, you said RTO.Max of 150ms.
Where did you get 300ms from?  RTO maxes out at 150ms.  Even with
Assoc.Max.Retrans = 4, the longest it will take is 150ms+QDR+150ms+
QDR+150ms+QDR+150ms.  Remember that there is a Queueing Delay before
Retransmit (QDR) that gets worse with each retransmit due to a closing
congestion window.  But at the minimum you get RTO.Min+2*RTO.Min+RTO.Min+
2*RTO.Min.  If RTO.Min is 50ms, that's 300ms anyway.

Also, it is foolish to lower RTO.Max below 200ms.  Why?  Because the
max sack delay is 200ms recommended and 500ms maximum.  You will be
retransmitting (and throttling for congestion) once every two packets
because t3-rtx will fire before the far end sends it delayed SACK.
This means that you will have 1 peg against each destination half of
the time.  When a real failure comes you can fail in 2*RTO.Min or
in your case 100ms.

> [TOLGA] Association won't be dropped at 300ms but at 900ms.

On the low end, even with RTO.Min = RTO.Max = 150ms, you can fail
in 300ms. (Because of the SACK delay problem.)

> [TOLGA]IMO, the values I gave are reasonable, i.e. 150ms is not too low and

300ms is too low because T7 is normally 1.0 seconds.  You are not allowed
in MTP2 to fail a link at 30% of T7.

> use M2PA in big-I Internet.

Gee, with an RTO.Max of 150ms not only would you be pegging each
delayed SACK, but you would fail the association on the above, when
108ms one-way (216ms round trip) maximum is fine.  But then, if the
maximum shifts up to over 500ms, due to congestive queueing delay,
you might still leave the association open with your values.

> [TOLGA]For the need for HEARTBEATS I agree. 

And they clear your pegs, lengthening the maximum delay even further
and without bound.  RFC 2960 permits the ULP to issue a heartbeat
at any time, as often as it likes, regardless of whether this clears
the pegs and keeps the asociation alive and delaying your packets
forever.

> important factor to meet SS7 requirements.

Read the SCTP applicability statement.

--brian