Subject: AW: WG: [Sigtran] M2PA: T7 and dropping SCTP association after li nk f ailure

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Thu, 8 May 2003 11:56:28 +0200

Brian,

your explanation fully meets what I would have done when implementing it.
I fully agree with your proposed wording at the end of your mail.

greetings

HannsJuergen

> -----Ursprüngliche Nachricht-----
> Von: Brian F. G. Bidulock [mailto:[email-masked]]
> Gesendet: Donnerstag, 8. Mai 2003 11:25
> An: Schwarzbauer Hanns Juergen
> Cc: List: IETF sigtran (E-Mail)
> Betreff: Re: WG: [Sigtran] M2PA: T7 and dropping SCTP 
> association after
> li nk f ailure
> 
> 
> Hanns Juergen,
> 
> Well, what made you think you needed hundreds of timers where 
> one would
> do?
> 
> One needs to time the oldest message in the retransmission 
> buffer.  One
> T7 can be started when the first message is placed in the 
> retransmission
> buffer.  When subsequent messages are added to the retransmission
> buffer, they are timestamped (tick clock is accurate enough as SS7
> timers are +-0.10 seconds).  When messages are acknowledged 
> and messages
> remain in the buffer, T7 is set to its value (say 1.0 second) 
> minus the
> difference between the timestamp of the oldest message and the current
> time.  In this fashion T7 will expire when the oldest message has been
> in the retransmission buffer for 1.0 second.
> 
> Of course this is implementation dependent and there are many 
> ways to do
> this.  Systems that use delta timers can have a delta timer in a T7
> timer list set for for each message (but only one actual 
> system timer is
> used).  SCTP lifetimes is another possibility.  Because implementation
> of T7 is a local matter, and has no bearing on iteroperability if used
> correctly, implementation should not be specified in M2PA.
> 
> The draft perhaps should not say that "a T7 timer SHALL be started for
> each message in the M2PA buffer."  Perhaps there is a better 
> way to say
> that without implying an implementation.  Say:
> 
> "When the oldest message in the retransmission buffer is time T7 old,
> the T7 timer will expire."
> 
> Or something similar.
> 
> This has been covered before on the threads discussing the need to
> alter T7 behavior.
> 
> --brian
> 
> Schwarzbauer Hanns Juergen wrote:                             
>                 (Thu, 08 May 2003 10:00:41)
> > your response is too kryptic. Please provide more details. 
> I would like to
> > make sure to have the correct understanding.
> > 
> > HannsJuergen
> > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Gesendet: Mittwoch, 7. Mai 2003 18:17
> > > An: Schwarzbauer Hanns Juergen
> > > Cc: List: IETF sigtran (E-Mail)
> > > Betreff: Re: WG: [Sigtran] M2PA: T7 and dropping SCTP 
> > > association after
> > > link f ailure
> > > 
> > > 
> > > Schwarzbauer,
> > > 
> > > There is no need to start hundreds of T7 timers.  Only one 
> > > timer is required,
> > > even if T7 is on a per-message basis.
> > > 
> > > --brian
> > > 
> > > Schwarzbauer Hanns Juergen wrote:                             
> > >                 (Wed, 07 May 2003 16:40:52)
> > > > resending...
> > > > 
> > > > I haven't found a thourough discussion on the list in the 
> > > past on the variations we are effectively expecting in an IP 
> > > network transporting SS7 messages. Variations in the 100ms 
> > > range do not justify this requirement. In case of voice over 
> > > IP jitter in the range of 100ms and more is also not 
> > > acceptable. Are we going to send SS7 messages over an IP 
> > > network worse than that used to transport voice?
> > > > 
> > > > Unless having real values, I see no need for having 
> > > hundreds of T7 timers.
> > > > 
> > > > greetings
> > > > 
> > > > HannsJuergen
> > > > 
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Schwarzbauer Hanns Juergen
> > > > [mailto:[email-masked]]
> > > > Gesendet: Donnerstag, 24. April 2003 08:27
> > > > An: 'TOLGA ASVEREN'; [email-masked]
> > > > Betreff: AW: [Sigtran] M2PA: T7 and dropping SCTP 
> > > association after link failure
> > > > 
> > > > 
> > > > Dear all,
> > > > 
> > > > see my comments below
> > > > 
> > > > Greetings
> > > > 
> > > > HannsJuergen
> > > > 
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: TOLGA ASVEREN [mailto:[email-masked]]
> > > > > Gesendet: Donnerstag, 24. April 2003 08:00
> > > > > An: [email-masked]
> > > > > Betreff: [Sigtran] M2PA: T7 and dropping SCTP association 
> > > after link
> > > > > failure
> > > > > 
> > > > > 
> > > > > Hi Tom,
> > > > > 
> > > > > 1) In M2PA 4.2.1
> > > > > "Because propagation delays in IP networks are more 
> > > variable than in
> > > > > traditional SS7 networks, a single T7 timer 
> (excessive delay of
> > > > > acknowledgement) is inadequate. A T7 timer SHALL be 
> > > started for each
> > > > > message in the M2PA retransmit buffer."
> > > > > 
> > > > > I think this explanation might be confusing -or better said 
> > > > > not complete-
> > > > > for people, which did not follow the threads related with T7. 
> > > > > IMO, it could
> > > > > be better to mention about possibility of SCTP delaying 
> > > > > acknowledgements
> > > > > for a specific message. Furthermore, based on what it stands 
> > > > > in RFC2960 6.1
> > > > > "This document is specified as if there is a single 
> > > > > retransmission timer
> > > > > per destination transport address, but 
> implementations MAY have a
> > > > > retransmission timer for each DATA chunk." , I would 
> > > think it could be
> > > > > better to revise the above section of M2PA, reflecting that 
> > > > > based on how
> > > > > the underlying SCTP handles T3, how to use M2PA T7 might 
> > > be different.
> > > > 
> > > > [HJS] 
> > > > in case the delay variations of an IP network used to 
> > > transfer SS7 messages are so volatile to justify starting a 
> > > T7 timer for every retransmitted message, then you should 
> > > think about your IP network design before putting more 
> > > functionality in M2PA. 
> > > > What granularity do you want to have for such a message 
> > > individual T7 timer? 10 ms? 
> > > > I'm definitely not heading for the transport of SS7 
> > > messages over the public IP network. Having multiple T7 
> > > timers should be considered an option only, as Tolga 
> proposed below.
> > > > [HJS]
> > > > ---snip---
> > > > _______________________________________________
> > > > 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/
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Fri, 9 May 2003 10:14:00 +0200

Tom,

agreed

HannsJuergen

> Von: Tom George [mailto:[email-masked]]
> Gesendet: Freitag, 9. Mai 2003 00:34
> An: SIGTRAN e-mail list
> Here is my reworded paragraph from 4.2.1: 
> 
> Because propagation delays in IP networks are more variable than in
> traditional SS7 networks, a single T7 timer (excessive delay of
> acknowledgement) as in MTP2 is inadequate. If any message is
> unacknowledged after a period equal to the T7 value, the T7 timer
> SHALL expire.
> 
> Here is the old text for comparison: 
> 
> Because propagation delays in IP networks are more variable than in
> traditional SS7 networks, a single T7 timer (excessive delay of
> acknowledgement) is inadequate. A T7 timer SHALL be started for each
> message in the M2PA retransmit buffer.
> 
> tomG.
> 
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Hanns Juergen,
> > 
> > Well, what made you think you needed hundreds of timers 
> where one would
> > do?
> > 
> > remain in the buffer, T7 is set to its value (say 1.0 
> second) minus the
> > Of course this is implementation dependent and there are 
> many ways to do
> > each message in the M2PA buffer."  Perhaps there is a 
> better way to say
> > > your response is too kryptic. Please provide more 
> details. I would like to
> * Tom George       PB7-24001 (near B-21)      
> [email-masked]  *
> * 972-519-3168   Intranet:  
http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran