Subject: [Sigtran] M2PA Comment: Multi-homing

From: [email-masked]
Date: Tue, 18 Jun 2002 10:31:29 +0100

Hi all,

Is there any reason why M2PA associations do not support multi-homing?

A.

*******************************************************************************
Important.
Confidentiality: This communication is intended for the above-named person and
may be confidential and/or legally privileged. Any opinions expressed in this
communication are not necessarily those of the company. If it has come to you
in error you must take no action based on it, nor must you copy or show it to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation.  Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.

Orange PCS Limited is a subsidiary of Orange SA and is registered in England No
2178917, with its address at St James Court, Great Park Road, Almondsbury Park,
Bradley Stoke, Bristol BS32 4QJ.
*******************************************************************************

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: [email-masked]
Date: Tue, 18 Jun 2002 08:32:03 -0400

Hello Amish,

M2PA associations support multihoming. That fact is behind the
claim that only one (multihomed) association is required between
peers in order to provide IP network redundancy. This applies to
all of the UA protocols.

Regards,

Jeff

[email-masked]@ietf.org on 06/18/2002 05:31:29 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  [Sigtran] M2PA Comment: Multi-homing

Hi all,

A.

Important.
Confidentiality: This communication is intended for the above-named person
and
may be confidential and/or legally privileged. Any opinions expressed in
this
communication are not necessarily those of the company. If it has come to
you
in error you must take no action based on it, nor must you copy or show it
to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation.  Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus
free.

Orange PCS Limited is a subsidiary of Orange SA and is registered in
England No
2178917, with its address at St James Court, Great Park Road, Almondsbury
Park,
Bradley Stoke, Bristol BS32 4QJ.
*******************************************************************************

---

From: [email-masked]
Date: Tue, 18 Jun 2002 14:06:33 +0100

Hello Jeff,

Where does the text in draft-v5 state that "only one multihomed association is
required"?
The text in draft-v5 also refers to an "IP address" and port number of an
association as if they were single homed (and not "IP addresses" of an
endpoint).

A grep of the mailing list, shows that this issue was mentioned in the thread
"M2PA association endpoint addresses" in July 2001.
It appears as if TomG was confused and thought there was the potential for
missequencing  when multiple paths are used.  Ken corrected this but the draft
still does not seem to imply that associations can be multi-homed.

Regards,
Amish

[email-masked] on 18/06/2002 13:32:03

To:   Amish CHANA/EN/HTLUK@HTLUK
cc:   [email-masked]

Subject:  Re: [Sigtran] M2PA Comment: Multi-homing

Hello Amish,

Regards,

Jeff

To:   [email-masked]
cc:

Hi all,

A.

Important.

Monitoring/Viruses

Monitoring/Viruses

---

From: [email-masked]
Date: Tue, 18 Jun 2002 09:55:08 -0400

Hello Amish,

The M2PA draft does not prohibit multihomed associations, therefore they
can be used.
The 'claim' I mentioned has to do with prior discussions. I was not quoting
from the draft.

Regards,

Jeff

[email-masked]@ietf.org on 06/18/2002 09:06:33 AM

To:   [email-masked]
cc:   [email-masked]
Subject:  Re: [Sigtran] M2PA Comment: Multi-homing

Hello Jeff,

Where does the text in draft-v5 state that "only one multihomed association
is
required"?
The text in draft-v5 also refers to an "IP address" and port number of an
association as if they were single homed (and not "IP addresses" of an
endpoint).

A grep of the mailing list, shows that this issue was mentioned in the
thread
"M2PA association endpoint addresses" in July 2001.
It appears as if TomG was confused and thought there was the potential for
missequencing  when multiple paths are used.  Ken corrected this but the
draft
still does not seem to imply that associations can be multi-homed.

Regards,
Amish

Hello Amish,

Regards,

Jeff

To:   [email-masked]
cc:

Hi all,

A.

Important.

Monitoring/Viruses

Important.

Monitoring/Viruses

---

From: [email-masked]
Date: Tue, 18 Jun 2002 15:07:08 +0100

Technically, I don't see any reason why multi-homing cannot be used and I argree
with you.
Maybe this is more of an editorial comment, in that the draft should better
reflect the multi-homed nature of endpoints.

A.

[email-masked] on 18/06/2002 14:55:08

Hello Amish,

Regards,

Jeff

Important.

Monitoring/Viruses

Important.

Monitoring/Viruses

Monitoring/Viruses

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 18 Jun 2002 10:26:16 -0700

Can someone volunteer some text changes to reflect this?

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, June 18, 2002 7:07 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sigtran] M2PA Comment: Multi-homing

Technically, I don't see any reason why multi-homing cannot be used and I
argree
with you.
Maybe this is more of an editorial comment, in that the draft should better
reflect the multi-homed nature of endpoints.

A.

Hello Amish,

Regards,

Jeff

****************************************************************************
***

Important.

Monitoring/Viruses

Orange PCS Limited is a subsidiary of Orange SA and is registered in
England No
2178917, with its address at St James Court, Great Park Road, Almondsbury
Park,
Bradley Stoke, Bristol BS32 4QJ.
****************************************************************************
***

****************************************************************************
***

Important.

Monitoring/Viruses

Orange PCS Limited is a subsidiary of Orange SA and is registered in
England No
2178917, with its address at St James Court, Great Park Road, Almondsbury
Park,
Bradley Stoke, Bristol BS32 4QJ.
****************************************************************************
***

****************************************************************************
***
Important.

Monitoring/Viruses

Orange PCS Limited is a subsidiary of Orange SA and is registered in England
No
2178917, with its address at St James Court, Great Park Road, Almondsbury
Park,
Bradley Stoke, Bristol BS32 4QJ.
****************************************************************************
***

---

From: [email-masked]
Date: Tue, 18 Jun 2002 16:05:32 -0400

Folks,

My recollection regarding this subject is that multi-homing is not
necessary for m2pa because fault tolerance would be obtained through the
use of changeover and changeback at the MTP3 level.  However, I am not
aware of any technical reason why multi-homing cannot be supported.  So I
am not opposed to changes indicating m2pa use of multi-homing provided it
is optional.

Regards
Ray

                    amish.chana@or                                                           
                    ange.co.uk            To:     [email-masked]                  
                                          cc:     [email-masked], (bcc: Ray P.             
                    06/18/02 10:07        Singh/Telcordia)                                   
                    AM                    Subject:     Re: [Sigtran] M2PA Comment:           
                                          Multi-homing                                       

A.

Hello Amish,

Regards,

Jeff

Important.

Monitoring/Viruses

Important.

Monitoring/Viruses

Important.

Monitoring/Viruses

---

From: Tuexen Michael <[email-masked]>
Date: Thu, 20 Jun 2002 13:30:31 +0200

Dear all,

the values given in RFC 2960 for RTM.min and so are
for the use in the Internet. To get the performance for
SS7 traffic different settings should be used. Then
you have different protocol behaviour. 

We did some measurements for a paper accepted at the
http://www.iiisci.org/sci2002/ conference where it is
show that you can meet the SS7 performance requirement.

Also two single homed associations are compared to a
dual-homed one.

We will put the .pdf version on the web when the paper
has be presented (20th July). This seems necessary due
to the copyright transform we had to make.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CC SE 7    e-Mail: [email-masked]

> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Thursday, June 20, 2002 12:59 PM
> To: [email-masked]'; Javier Pastor-Balbas (ECE)
> Cc: 'Tolga Asveren'; [email-masked]
> Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> 
> 
> Hi Brian, 
> 
> See below...
> 
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, June 19, 2002 8:15 PM
> > To: Javier Pastor-Balbas (ECE)
> > Cc: 'Tolga Asveren'; [email-masked]
> > Javier,
> > Javier Pastor-Balbas (ECE) wrote:                          
> > (Wed, 19 Jun 2002 18:38:32)
> > > Hi Tolga, 
> > > 
> > > See below...
> > > 
> > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > Sent: Wednesday, June 19, 2002 6:13 PM
> > > > To: [email-masked]
> > > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > 
> > > > 
> > > > Javier,
> > > > 
> > > > > From: Javier Pastor-Balbas (ECE)
> > > > > [mailto:[email-masked]]
> > > > > Sent: Wednesday, June 19, 2002 11:23 AM
> > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > >
> > > > >
> > > > > Hi Tolga,
> > > > >
> > > > > But, what is the difference between having two 
> > associations and a
> > > > > multihomed one that make the first approach advantageous?
> > > > [TOLGA] In fact with 2 associations one has 2 links. With 
> > > > that approach,
> > > > failure detection is done in parallel, whereas for 
> > > > multihoming case it is
> > > > done in a semi-serial way. With two associations, one will 
> > > > send data by
> > > > using both of them, for multihomed one for one destination 
> > > > only heartbeat
> > > > will be sent. So, unless the heartbeat is sent as frequent as 
> > > > data -which is
> > > > very unlikely- there will be a time difference between 
> > > > detecting the NIC
> > > > failures for 2 association and 1 multihomed association cases.
> > > 
> > > When SCTP's T3 timer expires, the retransmission is done 
> > towards another
> > > remote IP address. Also take into account the fact that 
> > Fast Retransmission
> > > procedures are part of SCTP what means that the frecuency 
> > will be bigger
> > > than T3. If it is a NIC failure it will be detected much 
> > faster by SCTP.
> > 
> > T3 does not expire in less than RTO.Min which is 1 second.  
> > MTP3 will have
> > already initiated changeover when T3 expires.
> > 
> > --brian
> > 
> 
> You are right, but I was now talking about FAST 
> RETRANSMISSION. Normal fast retransmission procedures are 
> faster than T3-rtx timer. Did you consider it in your reasoning?
> 
> Cheers // JAvier.
> 
> 
> > 
> > > 
> > > If it is a host failure, and the host is not the final 
> > recipient (i.e. it is a transfer node), a Rerouting procedure 
> > at MTP3 level will be triggered at the end in both cases.
> > > 
> > > 
> > > > >
> > > > > I would prefer to have a multihomed one since you can 
> send data
> > > > > in an independent way through two independent 
> channels (I refer
> > > > > to streams) and the change of remote IP address will be faster
> > > > > than the change of association. THe former is an SCTP 
> procedure,
> > > > > the latter involves also M2PA and MTP3 because it means a 
> > > > changeover...
> > > > [TOLGA] Sending data on streams is not a feature provided by 
> > > > multihoming,
> > > > one can do this also with non-multihomed SCTP. It is correct 
> > > > that when you
> > > > switch between assocaitions, this will involve MTP3, but you 
> > > > don't have any
> > > > idle path. 
> > > 
> > > The wire bandwidth is the same you use one or two 
> > associations between two hosts. so, what is the advantage?
> > > Having two associations do not improve the effectivity in 
> > sending DATA either. The same independency of paths can be 
> > obtained by using several streams. Moreover it will add more 
> > management to SCTP since it will need to handle two SCTP's TCBs.
> > > 
> > > > Afterall, for sure nobody can say using 
> > > > multihoming for SCTP is
> > > > forbidden for M2PA, it depends what one is looking for 
> > > > whether to use it or
> > > > not.
> > > 
> > > What I'm saying is that using SCTP should be a 
> > recommendation IMHO, at least when signaling is involved, as 
> > in this case.
> > > 
> > > 
> > > Cheers // Javier.
> > > 
> > > > >
> > > > > Cheers // Javier.
> > > > >
> > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > Sent: Wednesday, June 19, 2002 5:23 PM
> > > > > > To: [email-masked]
> > > > > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > > >
> > > > > >
> > > > > > Javier,
> > > > > >
> > > > > > For the problem you mentioned, I would think that 2
> > > > > > non-multihomed SCTP
> > > > > > associations instead of 1 multihomed one will work better.
> > > > > > Even if one has
> > > > > > Rto.Min less than 1 sec, in my opinion 2 
> association approach
> > > > > > is better,
> > > > > > because you can use both of them for data transfer, 
> > whereas with
> > > > > > multihoming, for one path only heartbeat messages 
> > will be sent.
> > > > > >
> > > > > >     Tolga
> > > > > >
> > > > > > > From: [email-masked]
> > > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > > Javier Pastor-Balbas (ECE)
> > > > > > > Sent: Wednesday, June 19, 2002 10:49 AM
> > > > > > > To: [email-masked]'
> > > > > > > Cc: [email-masked]
> > > > > > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > > > >
> > > > > > >
> > > > > > > Hi Brian,
> > > > > > >
> > > > > > > Do you mean that sending the message on a 
> > non-optimal route when
> > > > > > > SCTP detects that a remote address does not work is 
> > faster than
> > > > > > > retransmiting DATA towards the next remote IP address?
> > > > > > >
> > > > > > > Cheers // Javier.
> > > > > > >
> > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > Sent: Wednesday, June 19, 2002 3:44 PM
> > > > > > > > To: Javier Pastor-Balbas (ECE)
> > > > > > > > Cc: [email-masked]'; [email-masked];
> > > > > > > > [email-masked]; [email-masked]
> > > > > > > > Javier,
> > > > > > > > I highly doubt that SCTP with an Rto.Min of 1 
> second will
> > > > > > > > have anywhere
> > > > > > > > near the performance of MTP3 in detecting even 
> remote NIC
> > > > > > > > failures.  MTP3
> > > > > > > > will fail the link in 1 second whereas SCTP will only
> > > > > > start its first
> > > > > > > > retransmission in 1 second with an Rto.Min of 1 
> > second in the
> > > > > > > > case of a
> > > > > > > > remote NIC failure.  Any use of SCTP multihoming 
> > for M2PA is
> > > > > > > > marginal at
> > > > > > > > best, given the current recommended and 
> required protocol
> > > > > > > > parameters for SCTP.
> > > > > > > > IMO it would be foolish to accent SCTP 
> mutlihoming in the
> > > > > > > > draft as it is
> > > > > > > > rather useless for M2PA.  Because it is not forbidden,
> > > > > > however, it is
> > > > > > > > permitted.  We have arlready exchanged more 
> text that the
> > > > > > > > subject deserves.
> > > > > > > >
> > > > > > > > --brian
> > > > > > > >
> > > > > > > >
> > > > > > > > Javier Pastor-Balbas (ECE) wrote:
> > > > > > > > (Wed, 19 Jun 2002 10:08:33)
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Although the well-known MTP3 procedures such as 
> > changeover,
> > > > > > > > changeback,
> > > > > > > > > forced and controlled rerouting can give a 
> > certain degree
> > > > > > > > of reliability I
> > > > > > > > > would support to include the multihoming 
> host. Upon the
> > > > > > > > failure of a remote
> > > > > > > > > NIC, it will be a faster procedure to change 
> > the remote IP
> > > > > > > > address inside
> > > > > > > > > the association that triggering the MTP3 procedures.
> > > > > > > > Multihoming hosts would
> > > > > > > > > certainly improve the performance in those cases. It
> > > > > > would be then a
> > > > > > > > > desirable feature IMHO.
> > > > > > > > >
> > > > > > > > > Cheers // Javier.
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Brian F. G. Bidulock
> > > > > > > > [email-masked]
> > > > > > > > http://www.openss7.org/
> > > > > > > >
> > > > > > >
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 21 Jun 2002 11:37:01 +0200

Brian ,

You are now talking about T2. Read the following excerpt from Q.707:

"In case the signalling link test (SLT) is applied while the signalling link is in service the signalling link test message is sent at regular intervals T2"

"T2 = 30seg-90seg"

Cheers // Javier.

PS: The conclusion to this discussion is that you should take care of timers defined in MTP3 and SCTP to not duplicate transport functions in two different layers. Let's SCTP do its job. The upper layer are just applications from the IP architecture point of view...

Also you don't need to implement all the MTP2 timers (e.g. T7) within M2PA since reliability control is done below.

> Sent: Friday, June 21, 2002 10:44 AM
> Cc: [email-masked]'
> SLT procedure will still take the link out of service 
> (Q.707/T1.111.7) at
> MTP3 faster than SCTP's recommended protocol parameters.
> 
> --brian
> 
> (Fri, 21 Jun 2002 10:10:08)
> > Brian, 
> > 
> > The excerpt I copied below about T7 comes from Q.703, i.e. MTP2, 
> >                                                            ^^^^
> > which is in charge of flow control in the SS7 network. This 
> is the timer I
> > suppose you were referring to trigger the changeover based 
> on link failure.
> > (T7 = Timer "excessive delay of acknowledgement")
> > 
> > 
> > In Q.704 (MTP3) you will just find the next: 
> > 
> > -> T7:Waiting for signalling data link connection 
> acknowledgement.1 to 2 seconds.
> > It has nothing to do with SCTP's T3.
> > 
> > 
> > 
> > Cheers // Javier.
> > 
> > 
> > 
> > 
> > 
> > > Sent: Friday, June 21, 2002 9:54 AM
> > > Cc: [email-masked]'
> > > (Fri, 21 Jun 2002 09:39:13)
> > > > Hi Brian, 
> > > > 
> > > > My point was: I don't find any advantage in using the T7 
> > > timer since the
> > > > original function that this parameter has in MTP is well 
> > > performed by the
> > > > SCTP transport layer.
> > > 
> > > Poorly performed with the recommended SCTP protocol parameters.
> > > 
> > > > 
> > > > As I said before:
> > > > 
> > > > Why to use M2PA to deal with data recovery when in the IP 
> > > networks we
> > > > already have the means? Especially when SCTP was created 
> > > for that purpose.
> > > 
> > > But is deficient when used with the recommended protocol 
> parameters.
> > > 
> > > > It would need the involvement of more layers and the 
> > > mechanisms will be not
> > > > as efficient. We now have a RELIABLE transport layer under 
> > > "MTP2" (M2PA) and
> > > > not a wire as in the SS7 case...
> > > 
> > > MTP2, which M2PA provides the equivalent of, is also a RELIABLE
> > > layer: it provides for retransmissions, positive and negative
> > > acknowledgements.
> > > 
> > > > Many of changeovers and rerouting procedures can be avoided 
> > > and therefore
> > > > efficiency is improved.
> > > 
> > > MTP3 performance requirements, however, are not acheived by SCTP
> > > recommended protocol parameters.  These MTP3 procedures do no go
> > > away simply because M2PA is used instead of MTP2.  M2PA does not
> > > specify changes to be made to MTP3.
> > > 
> > > --brian
> > > 
> > > > 
> > > > Cheers // Javier.
> > > > 
> > > > > Sent: Thursday, June 20, 2002 6:46 PM
> > > > > Cc: [email-masked]'
> > > > > (Thu, 20 Jun 2002 13:35:52)
> > > > > > Hi Brian and others, 
> > > > > > 
> > > > > > Here are data from Q.703:
> > > > > > 
> > > > > > 
> > > > > > <start>
> > > > > > T7 = Timer "excessive delay of acknowledgement"
> > > > > > 	T7 (64) = 0.5-2 s	Bit rate of 64 kbit/s
> > > > > > 			For PCR method,	Values less than 0.8 s 
> > > > > should not be used
> > > > > > 	T7 (4.8) = 4-6 s	Bit rate of 4.8 kbit/s
> > > > > > <stop>
> > > > > > 
> > > > > > 
> > > > > > Therefore timer T7 has a recommended minimum value of 0.5 
> > > > > for a 64 kbps bit rate. 
> > > > > > 
> > > > > > Two main points here:
> > > > > > 
> > > > > > 1- SCTP's Fast Retransmission can be faster than that.
> > > > > 
> > > > > And will do so on a single-homed association.  There 
> is no benefit
> > > > > from multi-homing here.
> > > > > 
> > > > > --brian
> > > > > 
> > > > > > 
> > > > > > 2- Considering RTT (which is a function of the bit rate the 
> > > > > path has) you
> > > > > > can also configure T3-rtx from SCTP to a minor value. 
> > > This is NOT
> > > > > > recommended because fast retransmission is considered as 
> > > > > the default mode to
> > > > > > recover for data loss. Otherwise innecessary retransmission 
> > > > > could happen
> > > > > > oftenly. Same reasons used to keep T3=1 seg can be applied 
> > > > > to keep T7=1 seg
> > > > > > 
> > > > > > Why to use M2PA to deal with data recovery when in the IP 
> > > > > networks we
> > > > > > already have the means? Especially when SCTP was created 
> > > > > for that purpose.
> > > > > > It would need the involvement of more layers and the 
> > > > > mechanisms will be not
> > > > > > as efficient. We now have a RELIABLE transport layer under 
> > > > > "MTP2" and not a
> > > > > > wire as in the SS7 case... Many of changeovers and 
> > > > > rerouting can be avoided
> > > > > > improving the efficiency.
> > > > > > 
> > > > > > 
> > > > > > Cheers // Javier.
> > > > > > 
> > > > > > 
> > > > > > > Sent: Wednesday, June 19, 2002 8:16 PM
> > > > > > > On Wed, 19 Jun 2002, Javier Pastor-Balbas (ECE) wrote:
> > > > > > > 
> > > > > > > > Brian,
> > > > > > > > 
> > > > > > > > do you mean that M2PA has a timer to detect 
> message loss 
> > > > > > > whose value is less
> > > > > > > > than SCTP's T3?
> > > > > > > 
> > > > > > > T7.
> > > > > > > 
> > > > > > > --brian
> > > > > > > 
> > > > > > > > 
> > > > > > > > Cheers // Javier.
> > > > > > > > 
> > > > > > > > > Sent: Wednesday, June 19, 2002 6:02 PM
> > > > > > > > > M2PA includes acknowledgments.
> > > > > > > > > 
> > > > > > > > > --brian
> > > > > > > > > 
> > > > > > > > > (Wed, 19 Jun 2002 17:17:21)
> > > > > > > > > > Hi Brian,
> > > > > > > > > > 
> > > > > > > > > > Are you taking into account that in this 
> case MTP3 goes 
> > > > > > > > > over SCTP? How can
> > > > > > > > > > MTP3 detect a link failure if SCTP didn't 
> do it before?
> > > > > > > > > > 
> > > > > > > > > > Cheers // Javier.
> > > > > > > > > > 
> > > > > > > > > > > Sent: Wednesday, June 19, 2002 5:04 PM
> > > > > > > > > > > I mean that MTP3 detects non-optimal routes 
> > > as fast, and
> > > > > > > > > > > in many cases faster, than SCTP.
> > > > > > > > > > > 
> > > > > > > > > > > --brian
> > > > > > > > > > > 
> > > > > > > > > > > (Wed, 19 Jun 2002 16:48:59)
> > > > > > > > > > > > Hi Brian, 
> > > > > > > > > > > > 
> > > > > non-optimal route 
> > > > > > > > > > > when SCTP
> > > > > > > > > > > > detects that a remote address does not work is 
> > > > > faster than 
> > > > > > > > > > > retransmiting
> > > > > > > > > > > > > near the performance of MTP3 in detecting 
> > > > > even remote NIC 
> > > > > > > > > > > > > failures.  MTP3
> > > > > > > Brian F. G. Bidulock    ¦ The reasonable man adapts 
> > > > > himself to the ¦
> > > > > > > [email-masked]    ¦ world; the unreasonable one 
> > > > > persists in  ¦
> > > > > > > http://www.openss7.org/ ¦ trying  to adapt the  world  to 
> > > > > himself. ¦
> > > > > > >                         ¦ Therefore  all  progress  
> > > > > depends on the ¦
> > > > > > >                         ¦ unreasonable man. -- George 
> > > > > Bernard Shaw ¦
> > > > > > > 
> > > > > 
> > > > > -- 
> > > > > 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/
>

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 21 Jun 2002 12:09:44 +0200

Hi Amish, 

Sometimes there are two or more SLs between two telephony exchanges. It could be desirable, within the IP context, that the traffic sent on those different SLs were sent on one unique SCTP association using different streams. Only one association will be then needed between M2PA peers.

Cheers // Javier.

> Sent: Friday, June 21, 2002 11:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Even though the M2PA draft does not prohibit multi-homing the 
> entire document
> gives the impression that M2PA associations are only single homed.
> My comment is editorial and requires no protocol changes.
> 
> I would suggest following minor change to the 2nd paragraph of 4.1.2:
> "Each MTP link corresponds to an SCTP association. To prevent 
> duplicate
> associations from being established, it is recommended that 
> each endpoint know
> the IP address (or IP addresses if multi-homing is used) and 
> port number of both
> endpoints. SCTP prevents two associations with the same IP 
> addresses and port
> numbers from being established."
> 
> Amish
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 20/06/2002 22:15:36
> 
> Please respond to [email-masked]
> 
> 
> 
> 
> To:   "Ong, Lyndon" <[email-masked]>
> cc:   "'Michael Tuexen'" <[email-masked]>
>       Amish CHANA/EN/HTLUK@HTLUK
>       "Javier Pastor-Balbas (ECE)" 
> <[email-masked]>
>       "'Tolga Asveren'" <[email-masked]>
>       [email-masked]
> 
> 
> Lyndon,
> IMO an AS would be a better place to capture this information
> as it is mostly an operational consideration rather than a
> protocol function.  M2PA can clearly be run with or without
> multi-homing: without requiring any changes to the protocol.
> 
> --brian
> 
> Lyndon Ong wrote:                                          
> (Thu, 20 Jun 2002
> 14:05:59)
> > Folks,
> >
> > Indeed, you would be struck down by lightning bolts from IESG
> > if you put settings in an IETF Standard that posed a danger of
> > adding congestion to the Internet!
> >
> > However, I'm now unsure about the original comment against the
> > M2PA text - is there a consensus on whether any change needs
> > to be made?  Or is the discussion something that should be
> > captured in an AS?
> >
> > Cheers,
> >
> > Lyndon
> >
> > From: Michael Tuexen [mailto:[email-masked]]
> > Sent: Thursday, June 20, 2002 1:37 PM
> > To: [email-masked]
> > Cc: [email-masked]; Javier Pastor-Balbas (ECE); 'Tolga
> > Asveren'; [email-masked]
> > you are correct. We went through this discussion during an editing
> > session of an applicability statement (SCTP for signaling 
> transport, or
> > so).
> >
> > The result of the discussion was:
> > In an IETF document you MUST describe settings for the big 
> I Internet.
> > This applies to that applicability statement and also to 
> the M2PA draft.
> >
> > Now comes the difficult part of formulation:
> > But IF you are NOT using the Internet but an IP based 
> network used for
> > signaling you MAY use different parameter settings to 
> fulfill the SS7
> > requirements. Of course, this can not be standardized by the IETF.
> >
> > I expect that for carrier grade SS7/IP transport using the SIGTRAN
> > protocols the operators will use different parameters. But that is
> > out of scope for IETF.
> >
> > Best regards
> > Michael
> >
> > On Thursday, June 20, 2002, at 10:15 PM, Brian F. G. Bidulock wrote:
> >
> > > Michael,
> > >
> > > Michael Tuexen wrote:                                     
> (Thu, 20 Jun
> > > 2002 20:28:24)
> > >> Brian,
> > >> you are assuming the values of RFC 2960 which is not 
> necessary and
> > >> should not be the case when you are using SCTP for SS7 transport.
> > >> Best regards
> > >> Michael
> > >
> > > Huh?  We cannot recommend a non-internet-friendly setting of the
> > > SCTP parameters in the M2PA draft.  The minimum value of Rto.Min
> > > is 1 second.
> > >
> > > --brian
> > >
> > >> On Thursday, June 20, 2002, at 06:49 PM, Brian F. G. 
> Bidulock wrote:
> > >>
> > >>> amish.chana,
> > >>>
> > >>> [email-masked] wrote:                       
> (Thu, 20 Jun
> > >>> 2002
> > >>> 16:44:14)
> > >>>>
> > >>>> Michael/Tolga/Javier,
> > >>>>
> > >>>> This thread seems to be focused on which approach is 
> the FASTEST -
> > >>>> single homed
> > >>>> or dual homed?
> > >>>>
> > >>>> Would it not be more appropriate to determine if the 
> parameters for
> > >>>> each
> > >>>> configuration can be selected such the the failure detection is
> > >>>> within
> > >>>> a time
> > >>>> period that is tolerable by SS7? Both methods could be 
> suitable for
> > >>>> SS7
> > >>>> depending on how you select the SCTP parameters.
> > >>>>
> > >>>> T7 in Q.703 for example can have a value of up to 2 seconds!
> > >>>
> > >>> T3-rtx can have a value up to 60 seconds.
> > >>>
> > >>> --brian
> > >>>
> > >>>>
> > >>>> A.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> "Javier Pastor-Balbas (ECE)" 
> <[email-masked]>
> > >>>> on
> > >>>> 20/06/2002 16:18:39
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> To:   "'Tolga Asveren'" <[email-masked]>
> > >>>>       [email-masked]
> > >>>> cc:    (bcc: Amish CHANA/EN/HTLUK)
> > >>>>
> > >>>>
> > >>>> Tolga,
> > >>>> For the same Assoc.Max.Retrans value (=3):
> > >>>>
> > >>>> One monohomed assoc:
> > >>>> - T3+2*T3+4*T3 = 7*T3
> > >>>>
> > >>>> One dualhomed assoc:
> > >>>> - T3(1)+ T3(2)+ 2*T3(1) =5*T3   (between parenthesis the remote
> > >>>> address chosen)
> > >>>>
> > >>>>
> > >>>> Test with any other value different to 3 and you'll 
> find the same
> > >>>> conclusion.
> > >>>> (Path.max.retrans > Assoc.Max.Retrans/#remoteIPAddresses)
> > >>>>
> > >>>> Cheers // Javier.
> > >>>>
> > >>>>> Sent: Thursday, June 20, 2002 5:18 PM
> > >>>>> To: [email-masked]
> > >>>>>> Sent: Thursday, June 20, 2002 10:59 AM
> > >>>>>> Tolga,
> > >>>>>> Therefore we agree that multihoming has advantages 
> for non host
> > >>>>>> failures. :-)
> > >>>>>>
> > >>>>>> For host failures it will basically depend on the 
> configuration
> > >>>>>> you set with the following variable:
> > >>>>>>  - Assoc.Max.Retrans
> > >>>>>>
> > >>>>>> I also see too drastic to set this variable to 1. At 
> the first
> > >>>>>> time T3 expires or a heartbeat is not answered to 
> tear down the
> > >>>>> [TOLGA] In the context of this discussion 
> Assoc.Max.Retrans = 1
> > >>>>> means,
> > >>>>> retransmitting the message 1 time, so, after T3 
> expires, it will be
> > >>>>> retransmitted, the association won't be torn down.
> > >>>>>> association. It should not be a big deal to configure the
> > >>>>>> multihoming host in the way that it has the same
> > >>>>>> Assoc.Max.Retrans that your model, but for the case of
> > >>>>>> multihoming, retransmissions are split into the 
> different paths.
> > >>>>> [TOLGA] It is not related with setting Assoc.Max.Retrans = 1
> > >>>>> as I explained
> > >>>>> in my previous message. It is the same even if
> > >>>>> Assoc.Max.Retrans > 1. If one
> > >>>>> tries the paths the same in both approaches, singlehomed has
> > >>>>> a good chance
> > >>>>> of detecting host failures -depending on heartbeat-, faster
> > >>>>> than multihomed
> > >>>>> one.
> > >>>>>>
> > >>>>>> Then Multihoming will have a better behavior considering both
> > >>>>>> failure cases (path + host).
> > >>>>> [TOLGA] Not for host failures.
> > >>>>>>
> > >>>>>> Cheers // Javier.
> > >>>>>>
> > >>>>>>> Sent: Thursday, June 20, 2002 4:52 PM
> > >>>>>>> To: [email-masked]
> > >>>>>>>> Sent: Thursday, June 20, 2002 10:27 AM
> > >>>>>>>> Tolga,
> > >>>>>>>> If we are talking of a Path failure, it depends on the
> > >>>>>>> value to set in
> > >>>>>>>>   - T3
> > >>>>>>>>   - Path.Max.Retrans
> > >>>>>>>>
> > >>>>>>>> to perform the path change.
> > >>>>>>>>
> > >>>>>>>> Even though you set the same values in your two 
> associations
> > >>>>>>>> model than in a dual multihomed configuration to make it
> > >>>>>>>> equivalent, the multihomed one keeps the user out 
> of the problem
> > >>>>>>>> and it is the transport layer who solves it what 
> is faster as
> > >>>>>>>> less layers are involved.
> > >>>>>>> [TOLGA] For non-host failures, it is true that singlehomed
> > >>>>>>> has no advantage
> > >>>>>>> and requires involvement of MTP3 -like I said before-.
> > >>>>>>>>
> > >>>>>>>> Moreover, every time T3 expires and 
> Path.Max.Retrans has not be
> > >>>>>>>> reached, the dual multihomed model retransmit data 
> on the other
> > >>>>>>>> path. The two associations model will just wait to 
> reach the
> > >>>>>>>> maximum retrans value of the affected association to change
> > >>>>>>> to the other.
> > >>>>>>> [TOLGA] Yes. I don't say using two singlehomed
> > >>>>> associations is a magic
> > >>>>>>> bullet. My claim was that it is possible to detect
> > >>>>>>> host-failures faster than
> > >>>>>>> the multihomed case (depending on the parameters).
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Cheers / Javier.
> > >>>>>>>>
> > >>>>>>>>> Sent: Thursday, June 20, 2002 3:58 PM
> > >>>>>>>>> To: [email-masked]
> > >>>>>>>>> typo in the message below on my last comment:
> > >>>>>>>>>
> > >>>>>>>>> retransmit ----> fast retransmit
> > >>>>>>>>>
> > >>>>>>>>>    Tolga
> > >>>>>>>>>
> > >>>>>>>>>> Tolga Asveren
> > >>>>>>>>>> Sent: Thursday, June 20, 2002 9:49 AM
> > >>>>>>>>>> To: [email-masked]
> > >>>>>>>>>>> Sent: Thursday, June 20, 2002 8:49 AM
> > >>>>>>>>>>> Tolga,
> > >>>>>>>>>>>> Sent: Thursday, June 20, 2002 2:51 PM
> > >>>>>>>>>>>> To: [email-masked]
> > >>>>>>>>>>>>> Sent: Thursday, June 20, 2002 6:59 AM
> > >>>>>>>>> RETRANSMISSION.
> > >>>>>>>>>>>>> Normal fast retransmission procedures are faster
> > >>>>>>> than T3-rtx
> > >>>>>>>>>>>>> timer. Did you consider it in your reasoning?
> > >>>>>>>>>>>> [TOLGA] I think, FAST RETRANSMIT won't cause
> > >>>>> the association
> > >>>>>>>>>>>> to be declared
> > >>>>>>>>>>>> down, it is just to retransmit a DATA chunk.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Number of retransmissions variable is increased.
> > >>>>> The value of
> > >>>>>>>>>>> this parameter is one out of the possible causes for
> > >>>>>>>>> association abort.
> > >>>>>>>>>> [TOLGA] I couldn't find this in RFC2960 7.2.4. And apart
> > >>>>>>>>> from this, like
> > >>>>>>>>>> mentioned earlier, because no DATA will be received, no
> > >>>>>>> DATA will be
> > >>>>>>>>>> selected for retransmit in case of a path failure.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Cheers // JAvier.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I would prefer to have a multihomed
> > >>>>> one since you
> > >>>>>>>>>>>> can send data
> > >>>>>>>>>>>>>>>>> to streams) and the change of remote
> > >>>>> IP address
> > >>>>>>>>>>>> will be faster
> > >>>>>>>>>>>>>>>>> than the change of association. THe
> > >>>>> former is an
> > >>>>>>>>>>>> SCTP procedure,
> **********************************************************************
> > >>>> **
> > >>>> *******
> > >>>> Important.
> > >>>> Confidentiality: This communication is intended for 
> the above-named
> > >>>> person and
> > >>>> may be confidential and/or legally privileged. Any 
> opinions expressed
> > >>>> in this
> > >>>> communication are not necessarily those of the 
> company. If it has
> > >>>> come
> > >>>> to you
> > >>>> in error you must take no action based on it, nor must 
> you copy or
> > >>>> show it to
> > >>>> Orange may monitor all incoming and outgoing emails in 
> line with
> > >>>> current
> > >>>> legislation.  Although we have taken steps to ensure 
> that this email
> > >>>> and
> > >>>> attachments are free from any virus, we advise that in 
> keeping with
> > >>>> good
> > >>>> computing practice the recipient should ensure they 
> are actually
> > >>>> virus
> > >>>> free.
> > >>>>
> **********************************************************************
> > >>>> **
> > >>>> *******
> > >>>>
> > >>>>
> > [email-masked]
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > >
> >
> >

---

From: [email-masked]
Date: Fri, 21 Jun 2002 11:21:04 +0100

Hi Javier,

I refer you to section 4.2.6.1 of the draft.

Everyone agreed that there is no reason why multi-homing can not be used and it
is not prohibited. My comment is purely editorial to reflect this.

You are proposing significant protocol changes that apply not only to M2PA but
also to MTP3 - and it does not apply to multi-homing.

Amish

"Javier Pastor-Balbas (ECE)" <[email-masked]> on
21/06/2002 11:09:44

Hi Amish,

Sometimes there are two or more SLs between two telephony exchanges. It could be
desirable, within the IP context, that the traffic sent on those different SLs
were sent on one unique SCTP association using different streams. Only one
association will be then needed between M2PA peers.

Cheers // Javier.

> keeping with good

Monitoring/Viruses

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 21 Jun 2002 17:52:12 +0200

Hi Tolga, 

> [TOLGA] Are you proposing to use one SCTP association for 
> multiple links?

Yes, see the "Multiplexed M2PA links on an association" thread.

Cheers // Javier.

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 21 Jun 2002 17:41:49 +0200

Hi Tolga, 

Cheers // Javier.

> Sent: Friday, June 21, 2002 3:57 PM
> To: [email-masked]
> > Sent: Friday, June 21, 2002 6:32 AM
> > To: [email-masked]'; Javier Pastor-Balbas (ECE)
> > Cc: [email-masked]; [email-masked]
> > Sorry if I didn't explain myself... :-)
> > 
> > I agree on the multihoming issue (moreover I think it should be 
> > the recommended way to proceed). So I would be even clearer on 
> > this concern unless someone demonstrate the opposite.
> > 
> > This time I was referring to the first sentence in your proposal 
> > "Each MTP link corresponds to an SCTP association" which is 
> > already in section 4.1.2.
> > 
> > Section 4.2.6.1 is talking about having multiple stream per SL. I 
> > agree to what this section outlines and see this as a 
> problematic case.
> > 
> > But now, I'm proposing to modify the cited sentence because IMHO 
> > it would be desirable to have only one and only one association 
> > between two M2PA peers. If you have more than one link to 
> > emulate, you can use more than one link avoiding HOL blocking.
> > > Sent: Friday, June 21, 2002 12:21 PM
> > > Cc: [email-masked]; [email-masked]
> <[email-masked]> on
> > > 21/06/2002 11:09:44
> > > 
> > > 
> > > 
> > > 
> > > > > >>>>>>>>>>>>>>>> using both of them, for multihomed 
> one for one
> > > > > >>>>>>>>> destination
> > > > > >>>>>>>>>>>>>>>> only heartbeat
> > > > > >>>>>>>>>>>>>>>> will be sent. So, unless the 
> heartbeat is sent
> > > > > >>>>>>>>> as frequent as
> > > > > >>>>>>>>>>>>>>>> data -which is
> > > > > >>>>>>>>>>>>>> recipient (i.e. it is a transfer 
> node), a Rerouting
> > > > > >>>>>>>>> procedure
> > > > > >>>>>>>>>>>>>>>> one can do this also with 
> non-multihomed SCTP.
> > > > > >>>>>>>>> It is correct
> > > > > >>>>>>>>>>>>>>>> that when you
> > > > > >>>>>>>>>>>>>>>> switch between assocaitions, this 
> will involve
> > > > > >>>>>>>>> MTP3, but you
> > > > > >>>>>>>>>>>>>>>> don't have any
> > > > > >>>>>>>>>>>>>>>> idle path.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> management to SCTP since it will need 
> to handle two
> > > > > >>>>>>>>> SCTP's TCBs.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>> 2178917, with its address at St James Court, 
> Great Park Road,
> > > > > >>>> Almondsbury Park,