RE: 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
>