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

From: Tom George <[email-masked]>
Date: Thu, 11 Jul 2002 10:13:15 -0500

Me either. I will make that change in the next version.

tomG.

"Brian F. G. Bidulock" wrote:
> 
> Amish,
> 
> I have no problem with your proposed text change.
> 
> --brian
> 
> [email-masked] wrote:                       (Fri, 21 Jun 2002 10:38:24)
> >
> > 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.
> > *******************************************************************************
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
* Tom George          972-519-3168           [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* 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