Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Fri, 4 Oct 2002 16:39:48 -0400

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 4:14 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> Tolga,
> 
> Tolga Asveren wrote:                          (Fri, 04 Oct 
> 2002 16:00:35)
> > > 
> > > But not quickly enough when on other than a per-message 
> > > basis, as already discussed on this thread.
> > [TOLGA] As I said previously, this corner-case problem is 
> better to be
> > addressed by SCTP (forcing bundling, trying the other 
> interface while
> > fast-retransmitting, dropping association after a number of 
> CRC failures,
> > dropping association after certain fast-retransmit retires 
> for the same
> > message etc...)
> 
> 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). 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. 
> 
> 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.
> 
> 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.
> 
> This makes the M2PA case *very* different from the MTP2 case.  
> This is why M2PA needs per-message while MTP2 gets away with per-ack.
> 
> --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 16:36:50 -0600

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.
> 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.
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.

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.

> For the scenario you represented, it will take T7+propogation

50ms realistic if all you are doing is traversing the CO floor.  If you
are out in the wild...

> > 
> > 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

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.

> > 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

But neither M2PA nor SCTP will state how good the IP network needs to be.

--brian