Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Mon, 7 Oct 2002 17:54:59 -0400

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, October 07, 2002 5:32 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> Tolga,
> 
> Tolga Asveren wrote:               (Mon, 07 Oct 2002 17:12:55)
> > > 
> > > What if the receiver trickles out acks instead of stopping them
> > > altogether.
> > [TOLGA] IMO, what will happen in this case is the same what 
> would happen for
> > MTP2 case if receiver trickles out acks.
> 
> Well no, not exactly.  MTP2 Q.703 has a maximum 127 message 
> window.  M2PA
> has a much larger window.  MTP2 will eventually generate transmit
> congestion on the link because the 127 message window has 
> been exausted
> and the TB will fill.  M2PA, like MTP3b, has much larger 
> windows intended
> for higher data rates.  Therefore, MTP2 Q.703 will congest 
> quickly in such
> a case, where as M2PA will not.
[TOLGA]My point was that the mechanism is the same. Even for MTP2 case, one
can have unacceptable delays in such a scenario, if we don't rely that the
peer is going to acknowledge messages properly, and we know there there is
no T7 per message to handle this case in MTP2.
For M2PA case, the fact that SCTP works fine but M2PA behaves strange makes
this scenario more unlikely. Furthermore, I believe congestion mechanism for
M2PA is implementation dependent. If one wants to handle this case, one can
invent some sophisticated congestion mechanism -where one even might have a
timer per every message in the retransmit queue in M2PA, and when timer
expires congestion is indicated to user or something else-. IMO, even to
handle this case, a T7 timer per message is not necessary from protocol
point of view for M2PA.
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Oct 2002 16:20:36 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Mon, 07 Oct 2002 17:54:59)
> no T7 per message to handle this case in MTP2.

But in MTP2 messages delayed through retransmission are protected from
excessive delays through fixed bit rates and SUERM.  SCTP does not
fill this gap.  Messages which are lost due to errors or dropped due
to network congestion are delayed without detection by any other mechanism.
M2PA has no SUERM as a stop gap, so for M2PA the accent on T7 is greater.

> this scenario more unlikely.

How unlikely?  What number do I plug in to performance equations
for MTP3?

> Furthermore, I believe congestion mechanism for M2PA is implementation
> dependent.

Regarless, M2PA must make it possible to achieve MTP3 performance
requirements.

> If one wants to handle this case, one can invent some sophisticated
> congestion mechanism -where one even might have a timer per every message in
> the retransmit queue in M2PA, and when timer expires congestion is indicated
> to user or something else-.

No sophistication required.  Because SCTP stream is ordered, a message
cannot be acknowledged before the previously sent one is acknowledged.
One T7 timer will suffice which when a message is acknowledged is reset
to the T7 timeout minus the time elapsed since the next unacknowleged
message was deliver to SCTP rather than the full T7 timeout value.  That
is all that is necessary.  No sophistication required.  This results in
a per-message timeout, but only uses one timer.

> IMO, even to handle this case, a T7 timer per message is not necessary from
> protocol point of view for M2PA.

I don't think that M2PA should preclude the per-message approach above.  The
M2PA sender can managed its T7 timer to meet MTP3 performance requirements.
In the draft I think it is sufficient to say that a timer T7 SHOULD be used
to time the excessive delay of acknowledgement in accordance with MTP.  I
would even suggest in a IMPLEMENTATION NOTE, the above per-message procedure.

This is not a minor point.  Delay introduced into signalling links has been
shown both in theory and in the field to lead to catastrophic cascade failures
accross quad D-links.  This is a weakness of MTP2 which is caused precisely
from its treatement of T7 timers.  This is not a problem if no delay is
introduced into the link (drop-and-insert boxes, mediation boxes), however,
when delay is introduced into the link T7 does not fire properly and the
result is artificial transmit congestion.  With deep TB and RTB buffers,
eventual transmit congestion failure causes buffers to be transferred to the
next link in the linkset which immediately suffers the same fate.  I have
seen entire Quad D's go down in milliseconds resulting in total isolation.

Failure of a link due to transmit congestion must be restricted to occur only
in the case of true transmit congestion and not just because acknowledgements
are being delayed.

--brian

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