Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Sat, 5 Oct 2002 11:53:25 -0400

Brian,
 
> > > > 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.
> 
> 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] I believe ping gives RTT, so no need to multiply with two the max
value I gave. Furthermore, it was just an example to show that even in big-I
Internet average RTT is not so bad, but to be fair, I am sure if I try this
at several different times, I might hit bigger max and average values. But
the real point is, M2PA is not expected to run on big-I Internet.
The SACK-delay problem, I answered in one of the previous messages, just
lower the value.
> 
> > > 
> > > > > 
> > > > > 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. 
> 
> 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.
[TOLGA]I think you are speaking about the scenario, where the same message
continuosly experiences a problem (like the continuous CRC fault). To deal
with that, T7 as it is now in M2PA (not a per message timer) is enough, like
in MTP2 case. For the worst case after T7+propogation delay time, it will
expire, and link will fail.
With RTO.max=RTO.min=150ms  Part.maxretransmit=2 Assoc.maxretransmit=4 (2
interfaces) one even can survive without HEARTBEAT, it would take 600ms to
detect failure of association.
For which scenario do you foresee M2PA to trigger HEARTBEATs by itself?
 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Oct 2002 14:26:18 -0600

Another thought on T7:

Consider what would happen if the receiver (for whatever reason)
stops acknowledging messages at M2PA.  SCTP is humming along nicely,
but the sending M2PA has messages stacking up in its retransmit
buffer.  In this case to protect itself the sending M2PA needs to
run a T7 timer, regardless of SCTP protocol parameter settings.
That timer should be per-message because of the points raised at
the onset of this thread.

--brian

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