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

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

Tolga,

pathMaxRetransmits=1 may not be a good choice...

Let us assume 
Case 1: pathMaxRetransmits = 2; AssocMaxRetranmits = 3 for dualhoming
and
Case 2: pathmaxRetransmits = AssocMaxRetransmitss = 3 for singlehoming

Case 1:

Data on path 1;
after T3
Data on path 2 (first retransmission);
after T3
Data on path 1 (secon retransmission);
after 2*T3
Data on path 2 (third retransmission);
after 2*T3
Comm Lost (AssocMaxRetransmits=3) -> total time 6 T3.

Case 2:
Data on path
after T3;
Data on Path (first retransmission)
after 2 T3
Data on path (second retransmission)
after 4 T3
Data on path (third retransmision)
after 8 T3
Comm Lost -> total time 15 T3

So the dualhomed assoc wins ...

Best regards
Michael

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

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, June 20, 2002 3:36 PM
> To: [email-masked]
> Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> 
> 
> Michael,
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Tuexen Michael
> > Sent: Thursday, June 20, 2002 9:08 AM
> > To: [email-masked]'
> > Subject: FW: [Sigtran] M2PA Comment: Multi-homing
> > 
> > 
> > Sorry, I forget to include the list...
> > 
> > Michael Tuexen    Tel.:   +49 89 722 47210
> > Siemens AG        Fax:    +49 89 722 48212
> > ICN WN CC SE 7    e-Mail: [email-masked]
> >  
> > 
> > -----Original Message-----
> > From: Tuexen Michael 
> > Sent: Thursday, June 20, 2002 3:07 PM
> > To: 'Tolga Asveren'
> > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > 
> > 
> > Tolga,
> > 
> > assume a dualhomed  assoc. If the peer goes down, both
> > paths are used for retransmissions. So is much like two
> > single homed assocs, not a kind of 'serial' behaviour.
> > If there is some data for transmission the heartbeat time
> > does not have a (major) impact on the time to detect that
> > the communication is lost. 
> [TOLGA] The scenario is as follows: (path max retransmit = 1)
> 
> multihomed:
> 
>   --------DATA--on path1---->
> 
> T3 expires
> 
>   ---------DATA  on path 2-->
> 
> T3 expires
> 
> Association declared down. Time needed is 2*T3.
> 
> 
> non multihomed 2 associations:
> 
> ------DATA  on path 1---->             ------DATA  on path 1->
> T3 expires                             T3 expires
> Association declared down              Association declared down.
>                    Time needed is T3
> 
> > 
> > Best regards
> > Michael
> > 
> > Michael Tuexen    Tel.:   +49 89 722 47210
> > Siemens AG        Fax:    +49 89 722 48212
> > ICN WN CC SE 7    e-Mail: [email-masked]
> >  
> > 
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Thursday, June 20, 2002 3:08 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > 
> > > 
> > > Michael,
> > > 
> > > Depending on the heartbeat period, it might be the case that 
> > > it is not true,
> > > but I would expect, with two non-multihomed associations(just 
> > > one path per
> > > association), detection of loss of association will hapeen in 
> > > parallel,
> > > whereas for multihomed case, it might be close to serial 
> (depending on
> > > heartbeat period).
> > > 
> > >     Tolga
> > > 
> > > > -----Original Message-----
> > > > From: Tuexen Michael [mailto:[email-masked]]
> > > > Sent: Thursday, June 20, 2002 8:45 AM
> > > > To: 'Tolga Asveren'; [email-masked]
> > > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > >
> > > >
> > > > Dear Tolga,
> > > >
> > > > why would two single homed associations detect a host
> > > > failure faster than a dual homed association?
> > > > For me host failure detect time depends on the configuration
> > > > (number_of _retranmission per assoc path and so on), but
> > > > I do not see a reason why the global statement above is true.
> > > >
> > > > Best regards
> > > > Michael
> > > >
> > > > Michael Tuexen    Tel.:   +49 89 722 47210
> > > > Siemens AG        Fax:    +49 89 722 48212
> > > > ICN WN CC SE 7    e-Mail: [email-masked]
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > Sent: Thursday, June 20, 2002 2:46 PM
> > > > > To: [email-masked]
> > > > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > > >
> > > > >
> > > > > Amish,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > [email-masked]
> > > > > > Sent: Thursday, June 20, 2002 5:01 AM
> > > > > > To: [email-masked]
> > > > > > Cc: [email-masked]
> > > > > > Subject: Re: [Sigtran] M2PA Comment: Multi-homing
> > > > > >
> > > > > >
> > > > > >
> > > > > > Brian/Tolga,
> > > > > >
> > > > > > You'll mentioned that "MTP3 will reroute faster 
> than SCTP can
> > > > > > retransmit" and
> > > > > > "MTP3 changes over faster than SCTP can retransmit".
> > > > > [TOLGA] Sorry, but I didn't say this. What I said was, for
> > > > > detecting host
> > > > > failures, using two non-multihomed associations will 
> most probably
> > > > > outperform a single multihomed association . But it won't
> > > > > come for free, for
> > > > > non-host failures (where there is still a healthy path) MTP3
> > > > > involvement
> > > > > will be needed. Two non-multihomed associations will 
> also have the
> > > > > advantage, not to transmit heartbeat messages, but I wouldn't
> > > > > consider this
> > > > > as a major advantage, assuming that heartbeats won't be sent
> > > > > very frequent.
> > > > > >
> > > > > > Let say that we have no path failures, NIC 
> failures, etc., but
> > > > > > one SCTP packet
> > > > > > was unfortunate enough to be lost or corrupted in the 
> > > IP network.
> > > > > > Would this
> > > > > > result in a changeover because SCTP is too slow?
> > > > > >
> > > > > > If SCTP's retransmissions are too slow is it 
> appropriate to keep
> > > > > > the following
> > > > > > text in the draft "Note that since SCTP provides reliable
> > > > > > delivery and ordered
> > > > > > delivery
> > > > > > within the stream, M2PA does not need to perform 
> > > retransmissions"?
> > > > > >
> > > > > > Amish.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Brian F. G. Bidulock" <[email-masked]> on 
> > > 19/06/2002 19:12:38
> > > > > >
> > > > > > Please respond to [email-masked]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > To:   Amish CHANA/EN/HTLUK@HTLUK
> > > > > > cc:   [email-masked]
> > > > > >
> > > > > >
> > > > > > Subject:  Re: [Sigtran] M2PA Comment: Multi-homing
> > > > > >
> > > > > >
> > > > > >
> > > > > > Amish,
> > > > > >
> > > > > > MTP3 will reroute messsages as well: as fast or, in 
> the case of
> > > > > > retransmission, faster.
> > > > > >
> > > > > > --brian
> > > > > >
> > > > > > > MTP3 changes over faster than SCTP can retransmit.
> > > > > > >
> > > > > > > --brian
> > > > > > >
> > > > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 
> > > ******************************************************************
> > > > > > *************
> > > > > > 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
> > > > >
> > > 
> > > 
> > > _______________________________________________
> > > 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 20 Jun 2002 10:28:35 -0400

Michael,

> Sent: Thursday, June 20, 2002 9:46 AM
[TOLGA] I understand your point but the parameters you have choosen are not
fair :-) For example , I would say
Case 1: pathMaxRetransmit = 1; AssocMaxRetransmit = 2 (in fact 3 to be able
to try path2 2 times) for dualhoming
and
Case 2: pathMaxRetransmit = AssocMaxRetransmit = 1 for singlehoming

Case1: T3+T3+2*T3 = 4*T3
Case1(with AssocMaxRetransmit = 3) : T3+T3+2*T3+2*T3 = 6*T3 (every path is
tried 2 times)

Case2: T3+2*T3 = 3*T3  (the path is tried 2 times)

IMHO, the parameters for my example are not unrealistic, but well with other
parameters (like yours below) the result is different.