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

From: Tuexen Michael <[email-masked]>
Date: Thu, 20 Jun 2002 17:11:22 +0200

Tolga,

in the multihoming case one should use 
Max.Assoc.Retrans <= Sum_{all paths} Max.Path.Retrans_{path}
This means that the assoc should be closed when all
paths are INACTIVE.

And in the multihomed case I would use
Max.Assoc.Retrans < Sum_{all paths} Max.Path.Retrans_{path}
but this seems the point where we have different opinions.

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 5:04 PM
> To: [email-masked]
> Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> 
> 
> Michael,
> 
> > -----Original Message-----
> > From: Tuexen Michael [mailto:[email-masked]]
> > Sent: Thursday, June 20, 2002 10:26 AM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> >
> >
> > Tolga,
> >
> > it seems that we agree on the principles but have different
> > views on parameter setups. Having MaxAssocRetransmit=1 seems
> > not to be a good choice for me. But we agree on the protocol
> > behaviour...
> [TOLGA] But even for MaxAssocRetransmit > 1 let's consider 
> the following
> scenario:
> Case1: pathretransmit = 2   assocretransmit = 5 (every path is tried 3
> times)
> T3+T3+2*T3+2*T3+4*T3+4*T3 = 14*T3
> Case2: pathretransmit = assocretransmit = 2  singlehomed  
> (the path is tried
> 3 times)
> T3+2*T3+4*T3 = 7*T3
> 
> In my opinion, if the paths are tried for the same time for 
> both of the
> approaches, the result will always be Tmultihomed = 
> n*Tsinglehomed where n =
> number of addresses in multihomed case. But I agree, one 
> might think that it
> is not necessary to have all of the paths down, before declaring that
> communication is lost -although personally I wouldn't think 
> like this-, so
> for example one could assign assocretransmit < 5 for Case1 above.
> >
> > 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 4:29 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > >
> > >
> > > Michael,
> > >
> > > > -----Original Message-----
> > > > From: Tuexen Michael [mailto:[email-masked]]
> > > > Sent: Thursday, June 20, 2002 9:46 AM
> > > > To: 'Tolga Asveren'; [email-masked]
> > > > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> > > >
> > > >
> > > > 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
> > > >
> > > [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.
> > > >
> > > > 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
> > >
> 
> 
> _______________________________________________
> 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 12:12:20 -0400

Michael,

> Sent: Thursday, June 20, 2002 11:11 AM
[TOLGA] I agree. In my example it was 5 because for Assoc.Max.Retransmit I
counted number of retransmissions instead of T3 expiries -so I was wrong-.
You can consider it 4. Time needed to detect that connection is lost won't
change.
> but this seems the point where we have different opinions.
[TOLGA] Yes. My point was, to try each path the same amount of times for
both approaches, so I would use Max.Assoc.Retrans = Sum_{all paths}
Max.Path.Retrans_{path}, but I agree this is not mandatory so it can be
Max.Assoc.Retrans < Sum_{all paths} Max.Path.Retrans_{path} like you said.