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

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

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.

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 25 Jun 2002 10:29:28 -0400

Javier,

> Sent: Tuesday, June 25, 2002 9:52 AM
> The sentence refers to "not enough resources (e.g. n active
> ASPs)". So it tends to have a wider scope.
>
> SHOULD NOT means:
> 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.