Subject: Re: [Sigtran] Re:n+k issue

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 27 Jun 2003 16:22:25 -0600

Lyndon,

Lyndon Ong wrote:                                                                   (Fri, 27 Jun 2003 14:28:35)
> Hi Brian,
> 
> I did not mean to imply that you had misinterpreted anything
> (and my email says "interpreted n+k differently").  No one is
> at fault, however the definition of n+k appears to be causing
> confusion.
> 
> Right now the behavior of the SG depends on the individual
> implementation depending interpretation of the RFC.

The RFC is not open to interpretation.  The behavior is specified.
The SG activates on the first ASP, but MAY, as an OPTION, choose
to withhold until it determines that sufficient ASPs are active.
In the case that it waits, it SHOULD withhold the NTFY(AS-Active)
until such a determination is made.  There is no room for
interpretation.  We agreed on several occasions the text is clear.

> If we tighten up the definition of n+k, this should allow
> both behaviors (send on 1 active or send on N active)
> but they would be identified as different cases.

Activating on the 1st ASP is not optional.  That the SG MAY wait
for sufficient ASPs active is the OPTIONAL behavior.

If someone wants to describe this OPTIONAL behavior in the IG,
please do.  However, the current proposal and Section 3.15
presumes to make the behavior MANDATORY rather than OPTIONAL.
That is against the long line of consensus.

Please start by striking the current proposal and section 3.15 and
follow with a new proposal that clarifies, rather than changes, the
requirements.

--brian

> 
> This seems to fit at least the latest rough consensus, but
> please chime in people if you disagree.
> 
> Cheers,
> 
> Lyndon
> 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 27 Jun 2003 14:28:35 -0700

Hi Brian,

Cheers,

Lyndon

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, June 27, 2003 12:45 AM
To: Ong, Lyndon
Cc: [email-masked]
Subject: Re: [Sigtran] Re:n+k issue

Lyndon,

I don't think that I have misinterpreted anything as I authored half the text
in question and helped with the other half.  Consider the history of consensus
on this issue:

This began with the thread that I initiated entitled

  "M3UA-10: Example 5.1.4" that extended from Jan 2, 2002 to Jan 7, 2002.

This was a LC issue on M3UA.  The example showed in the "n+k" case the SG
sending NTFY(AS-Active) after this first (yes, the first) ASP activated for
the AS even thought "n=2" in the example.  I asked why the SG did not withhold
NTFY(AS-Active) until after "n=2" ASPs were active for the AS.

Greg proposed the text:

  An SGP or IPSP, upon reception of an ASP Active message for the first ASP in
  a Load-share AS, MAY choose not to direct traffic to a newly active ASP
  until it determines that there are sufficient resources to handle the
  expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the
  AS)."

The MAY was intentional to permit the SG to activate on the first ASP.

I proposed that the SG then withhold the NTFY(AS-Active) until after it
directs traffic if the SG follows the MAY and waits for sufficient ASPs.  (The
point of the original issue.)

It was agreed on this thread that some implementations would want to wait for
'n' and some would want to activate immediately, relying on the congestion and
flow controls of the ASP and MTP-User parts to handle any potential traffic
overloads.

Consensus was reached in the LC process and the text was adopted in M3UA-11.

On the thread:

  "n+k redundancy + NTFY  changes" from Jan 30, 2002 to Feb 1, 2002.

Tolga (surprising now) asks John Loughney to echo the changes of these two
passages into SUA and the same procedures are incorporated into SUA by
consensus.

On the thread:

  "m3ua-implementors-guidev00,  OPC list + missing issues" from March 31, 2002
  through April 10, 2002.

The discussion of "n+k" is brought up again by Tolga.  In this thread, Vikas,
Ken Morneault, and I agree that the text is clear.  Vikas and I also defend
the text.  Tolga is the only dissenter.  Umesh asks for clarification in the
IG, but it is agreed that the text in the RFC is clear.

On the thread:

  "m3ua: IG : n+k redundancy" from Jun 21, 2002 to Jun 26, 2002
  and
  "m2ua: IG : n+k redundancy - AS state machine"

Tolga brings up the same arguments again.  Javier's conclusion from previous
discussion initially was that no change was necessary.  Javier and Tolga then
go on to have a discussion between the two of them.  (I would have disagreed
in the middle of this, as consensus was already reached twice, but I was in a
U-haul between Texas and Alberta for the remainder of their exchange).  No one
else commented on the matter.

On the next thread:

  "I-D ACTION:draft-ietf-sigtran-m3ua-implementors-guide-02.txt"

I initiated a number of issued on the new release of the IG including the
section 3.15 which was not included by consensus, but only on the basis of
this brief discussion between Javier and Tolga.   I pointed out to Ken the
previous consensus points on this matter and he agreed to review the mail
threads.  Ken did not comment further.

Next on the thread:

  "M3UA Notify message" from Feb 12, 2003 to Feb 26, 2003
  (rejoined recently and extending from Jun 18, 2003 to Jun 26, 2003)

Srini asks some questions about Notify messages and n+k comes up again.  Srini
agrees that active ASPs < n corresponds to the AS-ACTIVE state as in the RFC
and that the ASP should use congestion and flow control procedures to limit
traffic if it is presented with too much traffic.  Bijoy agrees as well.
Srivats agrees as well with not stopping traffic #ASPs < n.  Samuel also
agrees with not stopping traffic #ASPs < n.  Javier agrees to the MAY.

The thread is rejoined recently.  The only dissenting voice on the thread is
Tolga (and most recently Javier).

Now, it appears to me that Tolga has brought this up on 4 or 5 separate
occasions, on each occasion (except when I was in the U-Haul) consensus was
that the existing RFC text stands and that the SG can activate with the first
ASP active in the AS regardless of 'n' or MAY wait for 'n' and SHOULD withhold
then NTFY(AS-Active) is reiterated.

10 separate individuals have come to consensus 4 times on this issue,
including last call, and the result was always that the RFC stands.  This text
also appears by consensus (as proposed by Tolga!) in SUA.  In subsequent
discussions Tolga was the only dissenting voice.  It appears Tolga wants 'n'
to be required (only) and never preferred.

The existing text allows it to be preferred or required depending on SG
implementation or configuration.  Although Tolga states that "1+k" required is
the same as preferred, the Notify(Insufficient ASPs Active in AS) behavior is
different for "1+k" required than it is for "n+k" preferred.

10 separate individual disagree with Tolga's proposals over the cited threads
(he disagrees with himself on a couple of occasions too).

Section 3.15 was NOT included on the consensus of the WG and stands against
the consensus of the WG.  There is no rough consensus to adopt the proposal as
evidenced by the archive.

As the WG has consistently spoken against these changes over the last 18
months, please do the right thing and strike Section 3.15 from the IG.

Thank you.

--brian

Lyndon Ong wrote:                                                                   (Thu, 26 Jun 2003 18:16:18)
> Hi Folks,
> 
> At the risk of blowing up the issue (although I think we
> are there already), I would like to make the following
> points:
> 
> -- the issue of n+k is in fact confusing in the RFC text
>   - n+k as defined in the introduction is subject to multiple
>     interpretations
>   - n+k has the following procedure defined in 4.3.4.3 -
>   "For the n+k redundancy case, ASPs which are in that AS should
>    coordinate among themselves the number of active ASPs in the AS, and
>    should start sending traffic only after n ASPs are active."
>     This seems to imply that traffic should only be resumed after
>     n ASPs are active, even if traffic is sent from the SG the ASPs
>     should not reply.
>   - the examples in 5.1.4 and 5.2.3 also appear to reflect this usage.
>   - n+k is not clearly reflected in the current state diagrams
> 
> Given that this appears to be a valid issue with the RFC and
> there seems to be a greater weight of opinion on the side of
> the proposed text I believe that the rough consensus exists
> supporting the proposed text in the M3UA implementor's guide draft.
> 
> However, I understand the concern on the part of some folks
> that have interpreted n+k differently.  As a result I think
> we also should add clarifying text to the n+k definition in
> 1.4.4.1 stating that in this definition, traffic is not sent
> until "n" ASPs are active, and that the "k" ASPs may be either 
> active at the same time as "n" or kept inactive until needed
> due to a failed or unavailable ASP.  Hopefully that will 
> cover other situations acceptably.
> 
> Cheers,
> 
> L. Ong

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/