Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Thu, 3 Oct 2002 13:27:52 -0400

Howard,

> -----Original Message-----
> From: May, Howard [mailto:[email-masked]]
> Sent: Thursday, October 03, 2002 12:41 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] M2PA V6: T7
> 
> 
> 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.  
[TOLGA] I think, the best way is to stick, how it is done on MTP2. There
delay per message between MTP2 peers does not cause a link failure. Why
should we have it for M2PA? 
> 
> This presumes that SCTP has at least as stringent 
> requirements on RTT as M2PA - has this been explicitly discussed?
[TOLGA] Which requirements are you referring to exactly?
> 
> 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
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran