Subject: RE: [Sigtran] Re:[Sigtran]ASP load sharing..

From: "Schantz, John" <[email-masked]>
Date: Wed, 18 Dec 2002 11:07:28 -0600

Tolga,

	I could go with the uniqueness from an SG's point of view also.
It is easier to determine the IDs if they are only unique from an AS's
point of view.  What I don't like about making them unique from an SG's
point of view is the "20 questions" that an ASP would have to go through
to finally find a value that the SG would agree with.  Hence, statically
assigning it verse dynamically assigning it would be preferred if you
want it unique at an SG point of view.

John

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Wednesday, December 18, 2002 10:35 AM
To: [email-masked]
Subject: RE: [Sigtran] Re:[Sigtran]ASP load sharing..

John,
--- "Schantz, John" <[email-masked]> wrote:
> "By saying that the ASP ID must uniquely identify an
> ASP to an SG" does
> not mean that the ASP ID is globally unique.  It is
> a "local" reference
> number, hence it would only be unique between the AS
> and the SG.
> Therefore there is no need to globally administer
> the ASP ID.
[TOLGA]To some extent I agree. There is really no need
that ASPID is globally unique, but it should be unique
between all ASPs connected to a specific SG -from the
SG point of view-, not just between the AS and SG(of
course if the goal is using ASPDN from ASP to SG to
inform about failure of other ASPs). In fact, even so, practically one
migth end up with a system, where ASPID is really gloablly unique, but
this is besides the point.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock
> [mailto:[email-masked]]
> Sent: Wednesday, December 18, 2002 6:20 AM
> To: PSK Chakravarthi
> Cc: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] Re:[Sigtran]ASP load
> sharing..
> 
> 
> Chak,
> 
> By saying in the IG that the ASP Id must uniquely
> identify
> and ASP to an SG.
> 
> --brian
> 
> PSK Chakravarthi wrote:                    (Wed, 18
> Dec 2002 17:49:38)
> > Brian,
> > 
> > As per RFC 3332 (3.5.1 Asp Up)
> >       The optional ASP Identifier parameter
> contains a unique value
> that
> >       is locally significant among the ASPs that
> support an AS.
> > 
> > 
> > How ASP1 knows that an ASP ID 1 is already used by
> another ASP2 when
> > ASP1 and ASP2 are controlling different ASs?
> > 
> > 
> > thanks
> > Chak
> > 
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock"
> <[email-masked]>
> > To: "PSK Chakravarthi"
> <[email-masked]>
> > Cc: "Tolga Asveren" <[email-masked]>;
> <[email-masked]>
> > Sent: Wednesday, December 18, 2002 5:17 PM
> > Subject: Re: [Sigtran] Re:[Sigtran]ASP load
> sharing..
> > 
> > 
> > > Chak,
> > >
> > > By sayin in the IG that the ASP Id must uniquely
> identify and ASP to
> 
> > > an SG, which it already must in many cases.
> > >
> > > --brian
> > >
> > > PSK Chakravarthi wrote:
> > (Wed, 18 Dec 2002 17:19:15)
> > > > Tolga,
> > > >
> > > > How do we make ASP ID globally unique?
> > > >
> > > > regards
> > > > Chak
> > > >
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
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: Sat, 21 Dec 2002 16:51:11 -0800 (PST)

John,
> want it unique at an SG point of view.
[TOLGA]I understand your concern, but for the
scenario, where sending AspID in ASPUP is really
usefull (where IP address and/or port for ASP is not
known by SGP) is there any other alternative than
making it globally unique, where it is preconfigured
both at ASP and SGP?
BTW, when you proposed to report failues of other ASPs
from ASP to SGP, I think we were too much focused on
network failure scenarios, did not pay attention that
this really might be usefull for host failures, anyway
at least now I think there is a broader consensus on
the possible benefits of such a procedure.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 21 Dec 2002 18:24:55 -0700

Tolga, John,

Huh?  What's the difference from the SG's perspective
of a Host failure and a network failure.  Actually,
the SG cannot distinguish between the two.

The intention of "ASP Failure" was so that at least
the ASPs could distinguish between ASP-ASP communication
failure and both ASP-ASP and SG-ASP communication failure. 
The later case just happens to also occur during host
failure.

So how is this so different than putting ASP Id in ASP
Down?

Also, where the ASP Id is local to ASPs in an AS, how is
one ASP in the pool to know the ASP Ids of the other ASPs
in the pool if there are not configured?  ASP-ASP
communications?  Then why doesn't the ASPs communicate
the id which is global to the SG rather than only within
the scope of the AS?

Where does the "20 questions" come in?

--brian

Tolga Asveren wrote:                                                                 (Sat, 21 Dec 2002 16:51:11)

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 21 Dec 2002 18:03:08 -0800 (PST)

Brian,
> the SG cannot distinguish between the two.
[TOLGA] When John proposed that it might be usefull
that ASPs report about failure of other ASPs, we were
more looking to network failure scenarios and the
counter argument was that it is mainly responsibility
of SCTP multihoming.
> Tolga Asveren wrote:                                
>                                 (Sat, 21 Dec 2002
> 16:51:11)
> > > 	I could go with the uniqueness from an SG's
> point
> > > of view also.
> > > It is easier to determine the IDs if they are
> only
> > > unique from an AS's
> > > point of view.  What I don't like about making
> them
> > > unique from an SG's
> > > assigning it verse dynamically assigning it
> would be
> > > preferred if you

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 21 Dec 2002 23:21:37 -0700

Tolga,

Tolga Asveren wrote:                  (Sat, 21 Dec 2002 18:03:08)
> counter argument was that it is mainly responsibility

Yes, I saw the discussion.  But the fact is that it is quite
easy to build ASP pools that can detect failure of an ASP (even
network failures local to an ASP) far quicker than SCTP can
resonably detect them.

ASPs and SGs are indeed expected to be somewhat remote from each
other (otherwise no transport protocol would be necessary),
whereas, the ASPs (MGC) are expected to be local (because they
are expected to share call state, which is not so easy to do at
a distance--except using Broadcast Mode).  It is very reasonable
to expect that an ASP can detect all manner of failures faster
than an SG.

At the end of that discussion, the more persuasive argument was
that of Al Varney, which lays out that SS7 itself does not
expect perfection under failure conditions, but, rather, a
controlled amount of message loss.

But, as implementation and performance (and even message loss
and mis-sequencing) responsibilities are passed like the
proverbial buck from M3UA to the implementer, it is not the
place of M3UA to say that one procedure is better or worse than
another with regard to message loss, unless it takes the
responsibility back (as does the CORID draft).

Still, I don't see how the ASP Down proposal is so different
from Notify("ASP Failure") itself.  In the Notify("ASP Failure")
case the SG notifies remaining ASPs that it has lost
communication with an ASP (the ASP has moved to the ASP-DOWN
state in all AS).  In the ASP Down proposal, one of the
non-failed ASPs is telling the SG the same thing.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 22 Dec 2002 07:15:05 -0800 (PST)

Brian,
> Tolga Asveren wrote:                  (Sat, 21 Dec
[TOLGA] I still would think dealing with network
failures with SCTP multihoming is a better approach.
If all of the network paths are really broken from SGP
to ASP, then I would expect also other ASPs in the
pool can't reach the SGP, i.e. tightly coupled ASPs
will most probably have a similar IP connectivity. But
for host failures, that another ASP reports it, might
be really usefull.
> non-failed ASPs is telling the SG the same thing.
[TOLGA] From procedure point of view, I also don't see
a big difference. But because NTFY has RC inside, one
might live with a less restrictive AspID uniqueness,
whereas in ASPDN there is no RC.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 22 Dec 2002 14:34:10 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sun, 22 Dec 2002 07:15:05)
> for host failures, that another ASP reports it, might

There is quite a range of NIC an partial failures which
can cause the ASP to loose communication without other
ASPs being affected, which do not include total failure
of the ASP.

> whereas in ASPDN there is no RC.

For this "less unique" case that you subscribe to,
how does one ASP know the ASP Id of another?

If by configuration, what is the point of no having
ASP Id unique for a pool of ASPs rather than within
an AS?

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 23 Dec 2002 05:18:26 -0800 (PST)

Brian,
> Tolga,
> 
> Tolga Asveren wrote:                                
>                                 (Sun, 22 Dec 2002
> 07:15:05)
> > Brian,
> > > Tolga,
> > > 
> > > Tolga Asveren wrote:                  (Sat, 21
> Dec
> > > 2002 18:03:08)
> > > > Brian,
> > > > > Tolga, John,
> > > > > 
> > > > that ASPs report about failure of other ASPs,
> we
> > > were
> > > Yes, I saw the discussion.  But the fact is that
> it
> > > is quite
> > > easy to build ASP pools that can detect failure
> of
> > > an ASP (even
> > > network failures local to an ASP) far quicker
> than
> > > SCTP can
> > > resonably detect them.
[TOLGA] Maybe I better should have said non-host
related(which includes NIC failures on the host)
failures are better handled with SCTP. In fact if
multople NICs are present on a host, SCTP can also
handle NIc failures quite well.
> > > are expected to share call state, which is not
> so
> > > easy to do at
> > > At the end of that discussion, the more
> persuasive
> > > argument was
> > > that of Al Varney, which lays out that SS7
> itself
> > > does not
> > > and mis-sequencing) responsibilities are passed
> like
> > > the
> > > proverbial buck from M3UA to the implementer, it
> is
> > > not the
> > > place of M3UA to say that one procedure is
> better or
> > > worse than
> > > another with regard to message loss, unless it
> takes
> > > the
> > > Still, I don't see how the ASP Down proposal is
> so
> > > different
> > > communication with an ASP (the ASP has moved to
> the
> > > ASP-DOWN
> > > state in all AS).  In the ASP Down proposal, one
> of
> > > the
[TOLGA]I don't have a problem with "less unique"
AspIDs. Just the opposite, they make sense to me,
especially considering the dynamic address/pot case,
where AspId is needed in ASPUP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 23 Dec 2002 06:32:00 -0700

Tolga,

Tolga Asveren wrote:                            (Mon, 23 Dec 2002 05:18:26)
> > There is quite a range of NIC an partial failures which can
> > cause the ASP to loose communication without other ASPs
> > being affected, which do not include total failure of the
> > ASP.
> [TOLGA] Maybe I better should have said non-host related(which
> includes NIC failures on the host) failures are better handled
> with SCTP. In fact if multople NICs are present on a host,
> SCTP can also handle NIc failures quite well.

If only one of several multi-homed NICs fail, communication
will not fail with the SGP and no failure procedure would
be used in any event.  So, that's beside the point.

So. you're basically saying that any failure which the ASP
cannot detect (other than via SCTP), then that is a case where
the SGP will detect the SCTP failure just as fast?

Or that because one ASP cannot communicate with an SGP due to
a network failure, that all ASP will not be able to communicate
with that SGP?

I don't think that either of these statements necessarily hold
in all configurations.

> > For this "less unique" case that you subscribe to, how does
> > one ASP know the ASP Id of another?
> > 
> > If by configuration, what is the point of no having ASP Id
> > unique for a pool of ASPs rather than within an AS?
> [TOLGA]I don't have a problem with "less unique" AspIDs. Just
> the opposite, they make sense to me, especially considering
> the dynamic address/pot case, where AspId is needed in ASPUP.

But is there an argument for "less unique" ASP Ids?

I don't see one.

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 23 Dec 2002 05:47:32 -0800 (PST)

Brian,
> Tolga,
> 
> Tolga Asveren wrote:                           
> (Mon, 23 Dec 2002 05:18:26)
> related(which
[TOLGA] I agree that none of these are applicable for
all configurations (although I would think that with a
very high probability tightly coupled ASPs will have
similar IP network connectivity), like there is also
no guarantee that another ASP in a cluster detects
failure of ASP faster than SGP(again this depends on
implementation). 
> AspIDs. Just
[TOLGA] On the curretn RFC/IG there is nothing
mandating "less unique" AspIds. But if one wants to
use dynamic address/port configuration then one will
need this.
Now, because there are discussions about using ASPDN
to report failure about another ASP, IMO this creates
another case, where AspId should be "less unique".