Subject: RE: [Sigtran] M2PA V6: T7

From: "May, Howard" <[email-masked]>
Date: Thu, 3 Oct 2002 17:41:02 +0100

Consider an M2PA link which:
	1) Has an acceptable SCTP <-> SCTP RTT.
	2) Has an unacceptable M2PA <-> M2PA RTT.

Unless T7 is per message this may go undetected.  I presume if we have an unacceptable delay at the M2PA level we would want to fail the link.  M2PA knows that if such a delay were caused by IP losses or delays then SCTP would fail the association.  

This presumes that SCTP has at least as stringent requirements on RTT as M2PA - has this been explicitly discussed?

Howard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 03 October 2002 16:24
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> I disagree. If we accept Howard's proposed modification (that 
> T7 become a 
> "per-message" timer), we WOULD fail the link in his example 
> below, because 
> message #3 was acknowledged only after 2.7 seconds, which 
> would exceed T7 
> (1 second).
> 
> The M2PA that is waiting for the ack doesn't know what is the 
> cause of the 
> 2.7 second delay. It could have been caused by a problem at 
> the peer M2PA, 
> which would be a legitimate reason to fail the link. Or it 
> could have been 
> caused by the accumulation of normal packet delays or losses 
> in the IP 
> network, which would NOT be a legitimate reason to fail the link.
> 
> I think we should stick with the text in v6, which follows 
> the letter of 
> Q.703:
> 
> "A timing mechanism, timer T7, shall be provided which generates an 
> indication of excessive delay of acknowledgement if, assuming 
> that there 
> are at least one outstanding MSU in the retransmission buffer, no 
> new-acknowledgement has been received within a time-out T7."
> 
> Barry Nagelberg
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]>
> Sent by: [email-masked]
>  09/26/2002 09:30 AM
>  Please respond to bidulock
> 
>  
>         To:     "May, Howard" <[email-masked]>
>         cc:     [email-masked]
>         Subject:        Re: [Sigtran] M2PA V6: T7
> 
> 
> Howard,
> 
> Sounds good to me.
> 
> --brian
> 
> May, Howard wrote:                                   (Thu, 26 
> Sep 2002 
> 13:53:01)
> > Excellent.  May I propose the following modification to the spec.
> > 
> > The per User Data message Timer T7 provides an indication 
> of excessive 
> delay
> > of acknowledgement.  If the following conditions are true:
> > (a) A User Data message is not acknowledged within the span of T7.
> > (b) The remote M2PA is not in a Busy condition.
> > 
> > Howard
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: 26 September 2002 13:42
> > > To: May, Howard
> > > Cc: [email-masked]
> > > Subject: Re: [Sigtran] M2PA V6: T7
> > > 
> > > 
> > > Howard,
> > > 
> > > Well, no.  T7 in Q.703 is not intended to handle acknowledgement
> > > delays in the receiver.  The receiver is expected to acknowledge
> > > messages immediately upon receipt.  In Q.703 if messages 1, 2
> > > and 3 are sent in a group, they are expected to be acknowledged
> > > at the same rate at which they were emitted: i.e., no 900 ms
> > > delay between acknowledgements.  Also, in the Q.703 
> queueing model,
> > > one-way propagation delays are never greater than about 30ms for
> > > the basic method.  In this way, T7 is used as a guard timer.
> > > If RTT is variable and does not satisfy the relationship that
> > > PD << T7 then you will not get the results expected by the
> > > Q.703 model.
> > > 
> > > For M2PA it might be better, as Jeffrey puts, to view T7 as a
> > > per-message timer as the PD << T7 relationship cannot be
> > > guaranteed.
> > > 
> > > --brian
> > > 
> > > May, Howard wrote:                                 (Thu, 26 
> > > Sep 2002 13:25:27)
> > > > So in effect there is no bound on the length of time it 
> may take to
> > > > acknowledge a message.  My previous example demonstrated 
> > > that it took 2.7
> > > > seconds to acknowledge Data message three even though T7 is 1s.
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: 26 September 2002 13:05
> > > > > To: May, Howard
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [Sigtran] M2PA V6: T7
> > > > > 
> > > > > 
> > > > > Howard,
> > > > > 
> > > > > Close enough.
> > > > > 
> > > > > --brian
> > > > > 
> > > > > May, Howard wrote:                                     (Thu, 
> > > > > 26 Sep 2002 12:24:59)
> > > > > > 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
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > 
> > > > > -- 
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > > 
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran