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

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 25 Jun 2002 20:14:21 +0200

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...

> -----Original Message-----
> 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,
> 
> > -----Original Message-----
> > 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...

> 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.

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.
> >
> > > -----Original Message-----
> > > 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,
> > >
> > > > -----Original Message-----
> > > > 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.
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > 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,
> > > > >
> > > > > > -----Original Message-----
> > > > > > 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.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > 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,
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > 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.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > 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: Tue, 25 Jun 2002 14:43:23 -0400

Javier,

> Sent: Tuesday, June 25, 2002 2:14 PM
> 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):
>
> 	- 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)
>
> 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.
> 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.