Subject: RE: [Sigtran] Multiplexed M2PA links on an association

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

Brian, 

Could you specify a scenario where having more associations has a clear advantage?

Cheers // Javier.

PS: (I've changed the "subject" to name the refer to the right thread)
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, June 21, 2002 5:34 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] M2PA Comment: Multi-homing
> 
> 
> Tolga,
> 
> Tolga Asveren wrote:                                        
> (Fri, 21 Jun 2002 09:56:47)
> > Javier,
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > > Javier Pastor-Balbas (ECE)
> > > Sent: Friday, June 21, 2002 6:32 AM
> > > To: [email-masked]'; Javier Pastor-Balbas (ECE)
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > 
> > > 
> > > Hi Amish, 
> > > 
> > > 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.
> > [TOLGA] Are you proposing to use one SCTP association for 
> multiple links?
> 
> We agreed that multiple links living and dying together would have
> a drastic effect on existing MTP3 implementations which view links
> as independent.  Much changeover thrashing could result when an
> association fails.
> 
> --brian
> 
> > > 
> > > Cheers // Javier.
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Friday, June 21, 2002 12:21 PM
> > > > To: Javier Pastor-Balbas (ECE)
> > > > Cc: [email-masked]; [email-masked]
> > > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > 
> > > > 
> > > > 
> > > > 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
> > > > 
> > > > 
> > > > 
> > > > 
> > > > To:   Amish CHANA/EN/HTLUK@HTLUK
> > > >       [email-masked]
> > > > cc:   [email-masked]
> > > > 
> > > > 
> > > > Subject:  RE: [Sigtran] M2PA Comment: Multi-homing
> > > > 
> > > > 
> > > > 
> > > > 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.
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: [email-masked] 
> [mailto:[email-masked]]
> > > > > Sent: Friday, June 21, 2002 11:38 AM
> > > > > To: [email-masked]
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [Sigtran] M2PA Comment: Multi-homing
> > > > >
> > > > >
> > > > >
> > > > > Brian,
> > > > >
> > > > > 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]
> > > > >
> > > > >
> > > > > Subject:  Re: [Sigtran] M2PA Comment: Multi-homing
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > > >
> > > > > > -----Original Message-----
> > > > > > 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]
> > > > > > Subject: Re: [Sigtran] M2PA Comment: Multi-homing
> > > > > >
> > > > > >
> > > > > > Brian,
> > > > > >
> > > > > > 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)
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> Subject:  RE: [Sigtran] M2PA Comment: Multi-homing
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> 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.
> > > > > > >>>>
> > > > > > >>>>> -----Original Message-----
> > > > > > >>>>> From: Tolga Asveren [mailto:[email-masked]]
> > > > > > >>>>> Sent: Thursday, June 20, 2002 5:18 PM
> > > > > > >>>>> To: [email-masked]
> > > > > > >>>>> Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>> Javier,
> > > > > > >>>>>
> > > > > > >>>>>> -----Original Message-----
> > > > > > >>>>>> From: Javier Pastor-Balbas (ECE)
> > > > > > >>>>>> [mailto:[email-masked]]
> > > > > > >>>>>> Sent: Thursday, June 20, 2002 10:59 AM
> > > > > > >>>>>> To: 'Tolga Asveren'; [email-masked]
> > > > > > >>>>>> Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> 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.
> > > > > > >>>>>>
> > > > > > >>>>>>> -----Original Message-----
> > > > > > >>>>>>> From: Tolga Asveren [mailto:[email-masked]]
> > > > > > >>>>>>> Sent: Thursday, June 20, 2002 4:52 PM
> > > > > > >>>>>>> To: [email-masked]
> > > > > > >>>>>>> Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>> Javier,
> > > > > > >>>>>>>
> > > > > > >>>>>>>> -----Original Message-----
> > > > > > >>>>>>>> From: Javier Pastor-Balbas (ECE)
> > > > > > >>>>>>>> [mailto:[email-masked]]
> > > > > > >>>>>>>> Sent: Thursday, June 20, 2002 10:27 AM
> > > > > > >>>>>>>> To: 'Tolga Asveren'; [email-masked]
> > > > > > >>>>>>>> Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> 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.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>> From: Tolga Asveren [mailto:[email-masked]]
> > > > > > >>>>>>>>> Sent: Thursday, June 20, 2002 3:58 PM
> > > > > > >>>>>>>>> To: [email-masked]
> > > > > > >>>>>>>>> Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> typo in the message below on my last comment:
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> retransmit ----> fast retransmit
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>    Tolga
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>>> From: [email-masked]
> > > > > > >>>>>>>>> [mailto:[email-masked]]On Behalf Of
> > > > > > >>>>>>>>>> Tolga Asveren
> > > > > > >>>>>>>>>> Sent: Thursday, June 20, 2002 9:49 AM
> > > > > > >>>>>>>>>> To: [email-masked]
> > > > > > >>>>>>>>>> Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> Javier,
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>>>> From: Javier Pastor-Balbas (ECE)
> > > > > > >>>>>>>>>>> [mailto:[email-masked]]
> > > > > > >>>>>>>>>>> Sent: Thursday, June 20, 2002 8:49 AM
> > > > > > >>>>>>>>>>> To: 'Tolga Asveren'; [email-masked]
> > > > > > >>>>>>>>>>> Subject: RE: [Sigtran] M2PA Comment: 
> Multi-homing
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> Tolga,
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>>>>> From: Tolga Asveren 
> [mailto:[email-masked]]
> > > > > > >>>>>>>>>>>> Sent: Thursday, June 20, 2002 2:51 PM
> > > > > > >>>>>>>>>>>> To: [email-masked]
> > > > > > >>>>>>>>>>>> Subject: RE: [Sigtran] M2PA Comment: 
> Multi-homing
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> Javier,
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>>>>>> From: Javier Pastor-Balbas (ECE)
> > > > > > >>>>>>>>>>>>> [mailto:[email-masked]]
> > > > > > >>>>>>>>>>>>> Sent: Thursday, June 20, 2002 6:59 AM
> > > > > > >>>>>>>>>>>>> To: [email-masked]'; Javier 
> > > > Pastor-Balbas (ECE)
> > > > > > >>>>>>>>>>>>> Cc: 'Tolga Asveren'; [email-masked]
> > > > > > >>>>>>>>>>>>> Subject: RE: [Sigtran] M2PA Comment: 
> Multi-homing
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> Hi Brian,
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> See below...
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>>>>>>> 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]
> > > > > > >>>>>>>>>>>>>> Subject: Re: [Sigtran] M2PA Comment: 
> Multi-homing
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> Javier,
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> Javier Pastor-Balbas (ECE) wrote:
> > > > > > >>>>>>>>>>>>>> (Wed, 19 Jun 2002 18:38:32)
> > > > > > >>>>>>>>>>>>>>> Hi Tolga,
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> See below...
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>>>>>>>>> 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,
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>>>>>>>>>> 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?
> > > > > > >>>>>>>>>>>> [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.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> 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.
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>>>>>>>>>>> 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
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>>>>>>>>>>>> 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.
> > > > > > >>>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>>>> -----Original Message-----
> > > > > > >>>>>>>>>>>>>>>>>>>> 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]
> > > > > > >>>>>>>>>>>>>>>>>>>> Subject: Re: [Sigtran] M2PA Comment:
> > > > > > >>>>>>>>> Multi-homing
> > > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>>>> 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/
> > > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>> _______________________________________________
> > > > > > >>>>>>>>>>>>>>>>>>> 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
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> --
> > > > > > >>>>>>>>>>>>> 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
> > > > > > >>>>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> _______________________________________________
> > > > > > >>>> Sigtran mailing list
> > > > > > >>>> [email-masked]
> > > > > > >>>> https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > >>>>
> > > > > > >>>> _______________________________________________
> > > > > > >>>> Sigtran mailing list
> > > > > > >>>> [email-masked]
> > > > > > >>>> https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > 
> > > > 
> **********************************************************************
> > > > > > >>>> **
> > > > > > >>>> *******
> > > > > > >>>> 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
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>> Brian F. G. Bidulock
> > > > > > >>> [email-masked]
> > > > > > >>> http://www.openss7.org/
> > > > > > >>>
> > > > > > >>> _______________________________________________
> > > > > > >>> Sigtran mailing list
> > > > > > >>> [email-masked]
> > > > > > >>> https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > >>>
> > > > > > >>>
> > > > > > [email-masked]
> > > > > > >
> > > > > > > --
> > > > > > > Brian F. G. Bidulock
> > > > > > > [email-masked]
> > > > > > > http://www.openss7.org/
> > > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > --
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > **************************************************************
> > > > > *****************
> > > > > 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
> > > > >
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > **************************************************************
> > > > *****************
> > > > 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
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 21 Jun 2002 11:46:12 -0500

Javier,

In all scenarios.  I cannot think of one where it would
not have an advantage.

--brian

Javier Pastor-Balbas (ECE) wrote:              (Fri, 21 Jun 2002 18:23:02)

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