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

From: [email-masked]
Date: Fri, 21 Jun 2002 10:38:24 +0100

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 21 Jun 2002 10:30:42 -0500

Amish,

I have no problem with your proposed text change.

--brian

[email-masked] wrote:                       (Fri, 21 Jun 2002 10:38:24)

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