Subject: [Sigtran] m3ua: IG : n+k redundancy

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 21 Jun 2002 12:08:31 -0400

Javier,

Could you also summarize the latest situation about n+k redundancy.

  Tolga 

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

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

Brian, 

let's do it well.

The message where the proposal is was:

Subject: RE: [Sigtran] m3ua-implementors-guidev00 n+k traffic mode
   Date: Mon, 8 Apr 2002 11:56:37 -0400
   From: "Tolga Asveren" <[email-masked]>
     To: [email-masked]

Answers with possitive/negative results are appreciated. They can be on text, diagram or both.

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, June 21, 2002 6:52 PM
> To: Javier Pastor-Balbas (ECE)
> Cc: 'Tolga Asveren'; [email-masked]
> Subject: Re: [Sigtran] m3ua: IG : n+k redundancy
> 
> 
> Javier,
> 
> Javier Pastor-Balbas (ECE) wrote:                          
> (Fri, 21 Jun 2002 18:17:50)
> > Hi Tolga, 
> > 
> > The conclusion I got from the mails is:
> > 
> > 	- You proposed a diagram for AS
> > 	- And also text changes to consider n as required
> > 	- But some folks preferred the text as it is now leaving the MAY
> > 
> > Then I didn't find consensus for the change. At the end of 
> the discussion
> > both parts (mainly Brian and you) had an opposite vision. 
> Then I would
> > consider that no text change is included.
> 
> Well, let's build concesus: does anyone have a problem with 
> this change?
> 
> --brian
> 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 26 Jun 2002 16:34:00 +0200

Hi Tolga, 

I would say:
	- Change it to MUST (mandatory behavior)
	- Change it to SHOULD (recommended behavior)

:-)

Cheers // Javier.

> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Wednesday, June 26, 2002 4:46 PM
> To: [email-masked]
> Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> 
> 
> After looking to some other passages in the draft, it seesm 
> it is best to
> describe the behavior for ASPAC n+k case with a special 
> paragraph -like it
> is already done in the draft-. So, please ignore my last message, what
> should be decided is ,as Javier stated, to change the MAY to 
> MUST or leave
> it as it is.
> 
>   Tolga
> 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Tolga Asveren
> > Sent: Wednesday, June 26, 2002 10:21 AM
> > To: [email-masked]
> > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> >
> >
> > Javier,
> >
> > > From: Javier Pastor-Balbas (ECE)
> > > [mailto:[email-masked]]
> > > Sent: Wednesday, June 26, 2002 9:48 AM
> > > To: [email-masked]
> > > Cc: 'Tolga Asveren'
> > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> > >
> > >
> > > Hi folks,
> > >
> > > Who is in favour/against of setting a MUST here?
> > [TOLGA] I agree it is best to stop arguing just among us 
> two but just to
> > clarify a little bit more, my proposal is to remove the paragraph
> > on page74
> > beginning with  the sentence"An SGP or IPSP upon reception of an
> > ASP Active
> > message for the first ASP in a ..."
> > >
> > > Cheers // Javier.
> > >
> > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > Sent: Tuesday, June 25, 2002 8:43 PM
> > > > To: [email-masked]
> > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> > > >
> > > >
> > > > Javier,
> > > >
> > > > > From: Javier Pastor-Balbas (ECE)
> > > > > [mailto:[email-masked]]
> > > > > Sent: Tuesday, June 25, 2002 2:14 PM
> > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> > > > >
> > > > >
> > > > > Tolga,
> > > > >
> > > > > I know that the proposal does not change nothing when 
> using n=1
> > > > > case... But IMO is too stringent without being a protocol key.
> > > > > With the recommendation (SHOULD):
> > > > >
> > > > > 	- Two different implementations will make it work as the
> > > > > "SHOULD NOT" strongly recommends
> > > > > 	- Otherwise they should get in touch to each 
> other to test
> > > > > if they have any major problem for their specific behavior
> > > > > (different to the recommended one)
> > > > >
> > > > > See more comments inline...
> > > > >
> > > > >
> > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > Sent: Tuesday, June 25, 2002 8:12 PM
> > > > > > To: [email-masked]
> > > > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> > > > > >
> > > > > >
> > > > > > Javier,
> > > > > >
> > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, June 25, 2002 1:50 PM
> > > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> > > > > > >
> > > > > > >
> > > > > > > Tolga,
> > > > > > >
> > > > > > > Imagine that you set n+k in your configuration, 
> but for any
> > > > > > > reasons you also have time requirements. At a
> > > > particular time you
> > > > > > > need your SG working and handling traffic because 
> the traffic
> > > > > > > could be less at that particular time that the 
> peak traffic what
> > > > > > > n is needed for. With the "SHOULD" statement you 
> could develop
> > > > > > > something like this but not otherwise.
> > > > > > [TOLGA] With SHOULD there is always the possibility that ASP
> > > > > > and SGP choose
> > > > > > the opposite sides, one withholds traffic and the other one
> > > > > > not. For the
> > > > > > scenario you described , I would say n = 1 and then 
> SGP sends
> > > > > > NTFY("Insuff.
> > > > > > ASP Active") if traffic is more than a threshold. If no ASP
> > > > > > answers with
> > > > > > ASPAC in a predefined period, SGP can send ASPIA-ACK and
> > > > > > inactivate AS.
> > > > >
> > > > > This would be implementation dependant and it is what we are
> > > > > trying to avoid in the general case. In principle NTFY is just
> > > > > informative...
> > > > [TOLGA] What I describe is, how a SGP might behave for the
> > > > scenario you
> > > > described, without assuming any special behavior from ASP.
> > > > >
> > > > > > So,
> > > > > > n > 1 is only necessary, when one is sure, one ASP is not
> > > > > > enough to handle
> > > > > > the traffic at any time.
> > > > >
> > > > > You have different traffics at different times. Maybe n is
> > > > > required in some hours but not others.
> > > > [TOLGA] Then as I explained above, n = 1 and you make use of
> > > > NTFY("Insuff.
> > > > ASP Active") or alternatively ASPs inactivate themselves when
> > > > traffic is too
> > > > high. With changing traffic, how should it work 
> according to you?
> > > > In fact, one of my initial two proposals was, to get 
> rid of n+k case,
> > > > because its use seems limited. If people think, that is
> > > > better, no problem
> > > > for me. But, changing MAY to SHOULD NOT is still not good. As
> > > > I said several
> > > > times, there is the possiblity that ASP and SGP interprete it
> > > > different.
> > > > According to protocol, it is clear, if AS is active traffic
> > > > flows, otherwise
> > > > not. So, let's either have a nicely defined n+k procedure or
> > > > forget about
> > > > it.
> > > > >
> > > > >
> > > > > Cheers // Javier.
> > > > >
> > > > >
> > > > > > >
> > > > > > > It is not a key point in the protocol since an ASP can
> > > > > > > theoretically handle traffic as soon as it gets 
> the ASP_ACTIVE
> > > > > > > state. It has to do with allowing special and 
> specific behavior.
> > > > > > > IMHO you need to give guidelines to handle it but also be
> > > > > > > permissive in possible other uses.
> > > > > > [TOLGA] But the proposal does not break, nor does it change
> > > > > > anything for n =
> > > > > > 1 case.
> > > > > > >
> > > > > > > Anyway, this is my thought.  I would also like to 
> see other's
> > > > > > > opinions about this issue. :-)
> > > > > > >
> > > > > > >
> > > > > > > Cheers // Javier.
> > > > > > >
> > > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > > Sent: Tuesday, June 25, 2002 4:29 PM
> > > > > > > > To: [email-masked]
> > > > > > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> > > > > > > >
> > > > > > > >
> > > > > > > > Javier,
> > > > > > > >
> > > > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > > > [mailto:[email-masked]]
> > > > > > > > > Sent: Tuesday, June 25, 2002 9:52 AM
> > > > > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Tolga,
> > > > > > > > >
> > > > > > > > > The sentence refers to "not enough resources 
> (e.g. n active
> > > > > > > > > ASPs)". So it tends to have a wider scope.
> > > > > > > > >
> > > > > > > > > SHOULD NOT means:
> > > > > > > > >    there may exist valid reasons in particular
> > > > > > > > circumstances when the
> > > > > > > > >    particular behavior is acceptable or even useful,
> > > > > > but the full
> > > > > > > > >    implications should be understood and the case
> > > > > > carefully weighed
> > > > > > > > >    before implementing any behavior described with
> > > > this label
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I don't see the need to put a more strict 
> requirement since
> > > > > > > > > SHOULD orders the general behavior unless 
> there are very
> > > > > > > > > understandable scenarios. Note that it is 
> similar to other
> > > > > > > > > document's paragraphs, e.g. sending SSNM in 
> ASP-INACTIVE.
> > > > > > > > > Therefore the general rule is set. MAY was just an
> > > > open option.
> > > > > > > > [TOLGA] The point is, there is no need for such a
> > > > > > > > flexibility. There are two
> > > > > > > > different things going on here:
> > > > > > > > 1- Either 1 Active ASP is enough but n are preferred
> > > > > > > > Because n=1, with the first active ASP, AS 
> becomes active and
> > > > > > > > traffic starts
> > > > > > > > to flow. NTFY("Insuff. ASP Active") is sent, if more
> > > > > > active ASPs are
> > > > > > > > preferred. For this case, SHOULD NOT is not appropriate,
> > > > > > because AS is
> > > > > > > > active, traffic MUST be started.
> > > > > > > > 2- Or m active ASPs are mandatory.
> > > > > > > > Because n = m, till there are m active ASPs, AS is not
> > > > > > > > active, so traffic is
> > > > > > > > not started. Also for this case SHOULD NOT is not
> > > > > > > > appropriate, because AS is
> > > > > > > > not active, traffic MUST NOT be started.
> > > > > > > >
> > > > > > > > With the changes I propose, both of those cases 
> are covered
> > > > > > > > without any
> > > > > > > > ambiguity. What is the advantage of not 
> defining the behavior
> > > > > > > > strictly? I
> > > > > > > > don't see any loss of generality.
> > > > > > > >
> > > > > > > > BTW, for other "semi-open" points in the draft, 
> I think it is
> > > > > > > > not a good
> > > > > > > > practice, to follow such an approach, just to find a
> > > > consensus.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Cheers // Javier.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > > > > Sent: Tuesday, June 25, 2002 3:25 PM
> > > > > > > > > > To: [email-masked]
> > > > > > > > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Javier,
> > > > > > > > > >
> > > > > > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > > > > > [mailto:[email-masked]]
> > > > > > > > > > > Sent: Tuesday, June 25, 2002 9:04 AM
> > > > > > > > > > > To: [email-masked]
> > > > > > > > > > > Cc: 'Tolga Asveren'; [email-masked]'
> > > > > > > > > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi guys,
> > > > > > > > > > >
> > > > > > > > > > > What about doing the following?:
> > > > > > > > > > > 	- Add the new AS state machine with n+k
> > > > information
> > > > > > > > > > > 	- Change "MAY choose not to direct traffic" to
> > > > > > > > "SHOULD NOT
> > > > > > > > > > > direct traffic" in both loadsharing and 
> broadcast modes.
> > > > > > > > > > [TOLGA] IMO, changing MAY to SHOULD NOT does not
> > > > help much,
> > > > > > > > > > because it still
> > > > > > > > > > leaves an open door. In fact nothing is 
> special about this
> > > > > > > > > > case. Traffic is
> > > > > > > > > > started when AS is active, and AS is active when
> > > > n ASPs are
> > > > > > > > > > active, for n =
> > > > > > > > > > 1, traffic will be started with the first 
> active ASP. This
> > > > > > > > > > does not break
> > > > > > > > > > anything about n = 1 case.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Cheers // Javier.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > From: Tolga Asveren 
> [mailto:[email-masked]]
> > > > > > > > > > > > Sent: Monday, June 24, 2002 7:53 PM
> > > > > > > > > > > > To: [email-masked]
> > > > > > > > > > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Javier,
> > > > > > > > > > > >
> > > > > > > > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > > > > > > > [mailto:[email-masked]]
> > > > > > > > > > > > > Sent: Monday, June 24, 2002 12:08 PM
> > > > > > > > > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > > > > > > > > Subject: RE: [Sigtran] m3ua: IG : n+k 
> redundancy
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Tolga,
> > > > > > > > > > > > >
> > > > > > > > > > > > > The current text gives total 
> flexibility. I agree
> > > > > > > > with you that
> > > > > > > > > > > > > it is not clear what to do in every 
> case where a
> > > > > > > > n+k model has
> > > > > > > > > > > > > been set. It will require that both 
> nodes make an
> > > > > > > > agreement and
> > > > > > > > > > > > > statically configure it..
> > > > > > > > > > > > [TOLGA] IMO, the "flexibility" the current text
> > > > > > gives is just
> > > > > > > > > > > > an attempt to
> > > > > > > > > > > > cover two different things with one mechanism. I
> > > > > > think, that
> > > > > > > > > > > > 1 active ASP is
> > > > > > > > > > > > enough but more than this is desireable and
> > > > that n active
> > > > > > > > > > > > ASPs are mandatory
> > > > > > > > > > > > are two different cases. It even might happen
> > > > > > that n ASPs are
> > > > > > > > > > > > mandatory but
> > > > > > > > > > > > n+m are preferred.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I see it as if n+k redundancy has 
> been added as
> > > > > > an optional
> > > > > > > > > > > > > feature but not a strict requirement for the
> > > > > > > > protocol. In fact
> > > > > > > > > > > > > the state machine is depicted for the 
> case where n+k
> > > > > > > > > > > > > configuration is not present. And the 
> "MAY" that
> > > > > > > > you refer is
> > > > > > > > > > > > > what gives you the opportunity to make an
> > > > > > > > > > implementation based on
> > > > > > > > > > > > > that. It also say that n+k is an optional
> > > > feature and
> > > > > > > > > > > > > implementations are not enforce to include it.
> > > > > > > > > > > > [TOLGA] If we change the AS state 
> machine for n+k
> > > > > > case, for
> > > > > > > > > > > > n=1 it will be
> > > > > > > > > > > > the same like the original AS state machine.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Then it would be correct to think as the
> > > > regular M3UA
> > > > > > > > > > > > > implementations not including this 
> feature. If an
> > > > > > > > specific one
> > > > > > > > > > > > > implements n+k redundancy (added value)
> > > > then it should
> > > > > > > > > > agree with
> > > > > > > > > > > > > the peer about its use.
> > > > > > > > > > > > [TOLGA] IMO, if we want n+k to be part of the
> > > > > > protocol (even
> > > > > > > > > > > > as optional)
> > > > > > > > > > > > procedures for it should be clearly 
> defined (like the
> > > > > > > > > > optional dynamic
> > > > > > > > > > > > registeration procedures) to let two nodes
> > > > interoperate
> > > > > > > > > > > > without ambiguity.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > I see here two options:
> > > > > > > > > > > > > 	1- Leave the text as it is and n+k
> > is an option
> > > > > > > > > > > > > 	2- Clarify the n+k procedure and base
> > > > > > the regular
> > > > > > > > > > > > behaviour on it
> > > > > > > > > > > > >
> > > > > > > > > > > > > I see the following problem: nr 2 changes
> > > > the current
> > > > > > > > > > > > > requirements in the protocol. I don't 
> see as a good
> > > > > > > > > > idea to force
> > > > > > > > > > > > > some implementations change at this time.
> > > > Probably they
> > > > > > > > > > have been
> > > > > > > > > > > > > commercialized and arecurrently  
> compliant with the
> > > > > > > > standard...
> > > > > > > > > > > > [TOLGA] If we are carefull enough, I 
> think we can
> > > > > > define n+k
> > > > > > > > > > > > procedures
> > > > > > > > > > > > without breaking anything on the special 1+k
> > > > case. Just AS
> > > > > > > > > > > > state machine
> > > > > > > > > > > > needs to be changed and the sentence "SGP MAY
> > > > choose to
> > > > > > > > > > > > withhold traffic"
> > > > > > > > > > > > should be reformed saying that if AS is
> > > > active (n ASPs are
> > > > > > > > > > > > active), traffic
> > > > > > > > > > > > will start to flow, otherwise not.
> > > > > > > > > > > > >
> > > > > > > > > > > > > What do others think?
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Cheers // Javier.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > From: Tolga Asveren 
> [mailto:[email-masked]]
> > > > > > > > > > > > > > Sent: Monday, June 24, 2002 3:55 PM
> > > > > > > > > > > > > > To: [email-masked]
> > > > > > > > > > > > > > Subject: RE: [Sigtran] m3ua: IG : 
> n+k redundancy
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Let me explain in a little bit more 
> in detail
> > > > > > > > about possible
> > > > > > > > > > > > > > changes for n+k
> > > > > > > > > > > > > > redundancy:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The original method of activating 
> AS with one
> > > > > > ASP active
> > > > > > > > > > > > and sending
> > > > > > > > > > > > > > NTFY("Insuff. ASP Act") if more 
> active ASPs are
> > > > > > > > desireable is
> > > > > > > > > > > > > > fine. But in
> > > > > > > > > > > > > > such a case, that "SGP MAY choose 
> not to direct
> > > > > > > > traffic" is
> > > > > > > > > > > > > > not the correct
> > > > > > > > > > > > > > behavior, because AS is active with 
> the first
> > > > > > active ASP,
> > > > > > > > > > > > > > traffic shouldn't
> > > > > > > > > > > > > > be withhold afterwards. I am not against
> > > > this mode of
> > > > > > > > > > > > > > operation, might be
> > > > > > > > > > > > > > usefull for some cases.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > But it is also clear that the above 
> method lacks
> > > > > > > > the ability
> > > > > > > > > > > > > > to wait for n
> > > > > > > > > > > > > > ASPs to be active, before statrting to
> > > > > > > > send/receive traffic
> > > > > > > > > > > > > > for this AS. In
> > > > > > > > > > > > > > such a case, AS will switch to 
> active state only
> > > > > > > > after n ASPs
> > > > > > > > > > > > > > are active.
> > > > > > > > > > > > > > Again there is no need for the sentence "SGP
> > > > > > MAY choose
> > > > > > > > > > > > not to direct
> > > > > > > > > > > > > > traffic" because, it shouldn't start
> > > > traffic before
> > > > > > > > > > AS is active.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Similar comments apply also for the sentence
> > > > > > "ASPs should
> > > > > > > > > > > > > > coordinate number
> > > > > > > > > > > > > > of active ASPs among themselves". 
> This is not
> > > > > > > > necessary for
> > > > > > > > > > > > > > case1 -but still
> > > > > > > > > > > > > > not wrong- but is necessary for case2. In
> > > > > > fact even for
> > > > > > > > > > > > > > case2, it might be
> > > > > > > > > > > > > > added that SGP shouldn't send DATA before
> > > > > > sending NTFY("AS
> > > > > > > > > > > > > > Active") but this
> > > > > > > > > > > > > > would be a diversion from the approach that
> > > > > > NTFY is only
> > > > > > > > > > > > > > advisory (and also
> > > > > > > > > > > > > > DATA and NTFY are sent on separate streams,
> > > > > > which might
> > > > > > > > > > > > cause loss of
> > > > > > > > > > > > > > sequence between them)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Another small open point for case2 
> is, whether
> > > > > > > > "n" should be
> > > > > > > > > > > > > > a part of the
> > > > > > > > > > > > > > traffic mode or not (for example when
> > > > traffic mode is
> > > > > > > > > > > > present in ASPAC
> > > > > > > > > > > > > > message). I tend to think that this 
> would be nice
> > > > > > > > (by adding
> > > > > > > > > > > > > > an optional
> > > > > > > > > > > > > > subparameter) but also I am not sure whether
> > > > > > this could be
> > > > > > > > > > > > > > considered as a
> > > > > > > > > > > > > > too big change for this moment.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    Tolga
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >