RE: Traffic distribution semantics

Ooooppss typo (again)
where the ASPAC is sent to only one ASP ==>> where ASPAC is sent to all SGPs


> -----Original Message-----
> From: Tolga Asveren [mailto:[email protected]]
> Sent: Monday, February 27, 2006 12:54 PM
> To: [email protected]
> Subject: RE: [Sigtran] Traffic distribution semantics
>
>
> Barry,
>
> I think I couldn't express what I mean. I tried to say that you
> also belive
> that traffic distribution and NTFY semantics should be well defined in the
> RFC(?).
>
> I also believe RFC should give a good architectural explanation,
> why traffic
> distribution is on a global-AS state basis -based on the majority view-,
> where the ASPAC is sent to only one ASP.(the reason why I started this
> thread is mainly this)
>
>     Thanks,
>     Tolga
>
> > -----Original Message-----
> > From: Barry Nagelberg [mailto:[email protected]]
> > Sent: Monday, February 27, 2006 1:09 PM
> > To: [email protected]
> > Subject: RE: [Sigtran] Traffic distribution semantics
> >
> >
> > Tolga,
> >
> > Your assumption is incorrect. Your concerns are a NON-issue,
> > which will disappear once we update the RFC to reflect the
> > consensus expressed on the list.
> >
> > Barry Nagelberg
> > Adax, Inc.
> >
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[email protected]]
> > Sent: Monday, February 27, 2006 12:40 PM
> > To: [email protected]
> > Subject: RE: [Sigtran] Traffic distribution semantics
> >
> >
> > Barry,
> >
> > Based on your answer I assume you also consider them as possible
> > interoperability issue, which needs to be addressed by an
> > official document.
> >
> > In that case, I think we should be able to answer the questions(and
> > subquestions like if global AS state is used for traffic
> distribution, why
> > is ASPAC sent per SGP etc..) I asked in my first message in this
> > thread and
> > should be providing an architecturally sound explanation in the RFC.
> >
> >    Thanks,
> >    Tolga
> >
> > > -----Original Message-----
> > > From: Barry Nagelberg [mailto:[email protected]]
> > > Sent: Monday, February 27, 2006 12:52 PM
> > > To: [email protected]
> > > Subject: RE: [Sigtran] Traffic distribution semantics
> > >
> > >
> > > Tolga,
> > >
> > > Both #1 & #2 below will be a non-issue once we fix the RFC to
> > > clarify that the AS state is kept at a global level across
> > > the entire SG.
> > >
> > > I believe that there is a consensus on the mailing list, at least
> > > from Brian and Lincoln, that this clarification is
> > > necessary.
> > >
> > > Barry Nagelberg
> > > Adax, Inc.
> > >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email protected]]
> > > Sent: Monday, February 27, 2006 11:39 AM
> > > To: [email protected]
> > > Subject: RE: [Sigtran] Traffic distribution semantics
> > >
> > >
> > > Barry,
> > >
> > > If it is really implementation dependent, I 100% percently
> > agree with you.
> > > The reason why I thought it could have some interoperability
> > issues is as
> > > follows:
> > >
> > > 1)Traffic mode allows to effect the message distribution to ASPs. For
> > > example, if one ASP overrides the other one on one SGP, but not
> > the other
> > > one, the traffic they are going to receive will be different,
> > depending on
> > > whether the individual or global state is used in SGPs to
> distribute the
> > > traffic.
> > >
> > > 2)I believe it makes sense to send the NTFY for AS state
> > changes based on
> > > the state used for traffic distribution purposes, i.e. if
> > global state is
> > > used based on global state changes, if local state is used
> > based on local
> > > state changes. So, depending on SG is implemented, the NTFYs
> received by
> > > ASPs will be different.
> > >
> > > IMO, neither 1) nor 2) are part of core interoperability, none
> > of the main
> > > procedures will be broken. OTOH, it may create certain issues
> > in real life
> > > deployments. So, I personally am also not thinking strongly
> > that those are
> > > huge problems but tend to think it could be nice to have a common
> > > understanding.
> > >
> > >      Thanks,
> > >      Tolga
> > >
> > > > -----Original Message-----
> > > > From: Barry Nagelberg [mailto:[email protected]]
> > > > Sent: Monday, February 27, 2006 11:00 AM
> > > > To: [email protected]
> > > > Subject: RE: [Sigtran] Traffic distribution semantics
> > > >
> > > >
> > > > Tolga,
> > > >
> > > > This subject is implementation dependent and doesn't belong
> > in the RFC.
> > > >
> > > > Barry Nagelberg
> > > > Adax, Inc.
> > > >
> > > > -----Original Message-----
> > > > From: Tolga Asveren [mailto:[email protected]]
> > > > Sent: Monday, February 27, 2006 10:18 AM
> > > > To: [email protected]
> > > > Subject: [Sigtran] Traffic distribution semantics
> > > >
> > > >
> > > > After much discussion in "M3UA Notify Message" thread, I got
> > > more confused
> > > > and became unsure regarding what needs to be done (I wanted to
> > > start a new
> > > > thread because I doubt many people followed it and I can't blame
> > > > anybody, it
> > > > probably should be an off-line discussion for most of the time)
> > > >
> > > > The question to be answered is who is the owner of the traffic
> > > > distribution,
> > > > SG or SGP -here as traffic distribution, I refer to traffic
> > distribution
> > > > from M3UA point of view, selecting an ASP depending on loadshare
> > > > or override
> > > > traffic modes-. Practically it means, do we distribute traffic to
> > > > ASPs based
> > > > on the "global ASP states" kept SG-wide or the "local ASP
> > > states" kept in
> > > > each SGP individually? If global ASP state is used, SG would be
> > > > the owner of
> > > > traffic distribution, if local state is used, SGP would be
> > the owner of
> > > > traffic distribution.
> > > >
> > > > I believe there are two main parameters to be considered:
> > > > a)Are traffic characteristics different on SGPs belonging to
> > the same SG
> > > > b)The architectural robustness/elegance
> > > >
> > > > For a), the question to be answered is are messages coming from
> > > different
> > > > SGPs -in the context of this discussion, all SGPs in
> > > > consideration are part
> > > > of the same SG- treated in a different way at an ASP/have different
> > > > preference. At the first thought, my answer was "No" but I am not
> > > > ruling out
> > > > the possibility that things like geographical location could be a
> > > > parameter
> > > > here, where it would be desirable/preferrable to receive
> traffic from
> > > > certain SGPs and not so preferred from other ones, for example
> > > due to the
> > > > cost of IP routing.
> > > >
> > > > For b), the question of ownership of traffic distribution to
> > > ASP question
> > > > leads to who is the owner of ASPTM procedures. It doesn't sound
> > > > very clean,
> > > > to have different owners for traffic distribution and
> ASPTM. Actually
> > > > traffic distribution itself is an ASPTM procedure.
> > Considering this, one
> > > > would expect all logical execution associated with ASPTM to
> > > happen at the
> > > > same entity. I would expect ASPSM to be executed at same entity
> > > > as well from
> > > > architectual sanity point of view. Practically this means, if SG
> > > > is owner of
> > > > the traffic distibution, why is it not owner of ASPTM (and
> > > possibly ASPSM)
> > > > as well? Why is ASPAC sent to all SGPs, rather than just to one
> > > > of them? One
> > > > could even ask why is ASPUP sent to all SGPs, rather than
> to only one?
> > > >
> > > > I believe, from "necessity" point of view, we need to consider
> > > the answer
> > > > for a). If the answer for a) is "characteristics are not
> different for
> > > > messages coming from different SGPs", then for b) both
> > options are open.
> > > > There is no exact need to send ASPAC to all SGPs. In such a
> > case I would
> > > > expect all  ASPTM procedures -including traffic distribution- to
> > > > be executed
> > > > based on the states kept per SG or per SGP but not in a
> > > mix-match way. In
> > > > this situation, my preference would be using states kept in
> each SGP,
> > > > providing a more simplistic architecture, where all ASPSM/ASPTM
> > > > is executed
> > > > in the context of a single SGP -please note this does mean
> disallowing
> > > > internal routing or not creating a uniqie SPMC view-.
> > > >
> > > > If the answer to a) is "Yes", then it seems preferrable to
> > have traffic
> > > > distribution logic to use states kept in individual SGPs, because
> > > > this would
> > > > allow ASPs, to force different choices on different SGPs,
> > > > depending on their
> > > > needs. In this case I would expect all ASPTM to use states kept in
> > > > individual SGPs.
> > > >
> > > > Any comments/ideas?
> > > >
> > > >
> > > >     Thanks,
> > > >     Tolga
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>