Subject: RE: [Speermint] Source-based routing

From: "Shawn Pouliotte" <[email-masked]>
Date: Wed, 08 Nov 2006 20:44:41 -0800

Hey Adam,
  
  Can you elaborate some on that? I understand the requirements for  source based routing and it makes sense but deriving geographic  locality is tough beyond mapping querier's IP address. If thats all you  meant then its all good and makes perfect sense to me. If its more than  that please elaborate. 
  
  Thanks
  Shawn
  _____  

From: Uzelac, Adam [mailto:[email-masked]]
To: Pfautz, Penn L, GBLAM [mailto:[email-masked]], Reinaldo Penno [mailto:[email-masked]], [email-masked]
Sent: Wed, 08 Nov 2006 20:33:00 -0800
Subject: RE: [Speermint] Source-based routing

Penn,
  
Thanks for setting me straight with regards to the requirements  citation.  I believe that we indeed do need to add a provision in  the requirements to account for geography.  That criteria would  not pertain to mobile scenarios, but in geographically static  environments where the request originates is pertinent.  I am  thinking originating network not user, at this stage.
  
  -AU
  
   -----Original Message-----
  From:   Pfautz, Penn L, GBLAM [mailto:[email-masked]]
  Sent:   Wed Nov 08 22:07:54 2006
  To:     Reinaldo Penno; Uzelac, Adam; [email-masked]
  Subject:        RE: [Speermint] Source-based routing
  
  I thought we did have a requirement that addressed at least part of this
  issue in
  draft-ietf-speermint-requirements-01.txt:
  
  o  Variability of the Call Address Data:
        A terminating VSP/ASP or user SHOULD be able to indicate its
        domain ingress points (Signaling Path Border Element(s)) based on
        the identity of the originating VSP/ASP or user.
        The mechanisms recommended for the use and resolution of the call
        addressing data SHOULD allow for variability or customization of
        the response(s) depending on various elements, such as the
        identity of the originating or terminating user or user domain.
  
  Are you asking just to add geographic origin info to this?
  I see originating entity and location info helping to determine routing
  but it's not clear to me that this isn't a multi-stage (and maybe
  multi-protocol) process.
  And by location, are we talking originating user location  or
  originating network element location?
  
  Penn
  -----Original Message-----
  From: Reinaldo Penno [mailto:[email-masked]]
  Sent: Wednesday, November 08, 2006 7:24 PM
  To: Uzelac, Adam; [email-masked]
  Subject: RE: [Speermint] Source-based routing
  
  Although I'm not a VSP I agree. At some point we discussed on this the
  fact that identity/geography/others should be taken into account when
  discovering/returning next-hop. That kind of faded way but seems a real
  problem to be tackled.
  
  Regards,
  
  Reinaldo
  
  > -----Original Message-----
  > From: Uzelac, Adam [mailto:[email-masked]]
  > Sent: Wednesday, November 08, 2006 4:18 PM
  > To: [email-masked]
  > Subject: [Speermint] Source-based routing
  >
  > Folks,
  >
  > I would like to propose that we add to the list of
  > requirements for SPEERMINT that any session routing proposal
  > that is proposed take into account the ability to use some
  > source criteria to return next-hop routes. I just re-read the
  > requirements draft, and I did not see anything specifically
  > addressing source-based routing.
  >
  > Speaking as a VSP, it's important that the ingress session
  > border element that is returned to the originator of the
  > request be based on, among other things, who's asking and
  > from where.  In practice, we do not return next-hop
  > information irrespective if the request comes from Alice/Bob,
  > or from China/Brazil.  This may be a matter of local policy,
  > but the tools and IDs that address session next-hop
  > determination need to account for this.
  >
  > -AU
  >
  > _______________________________________________
  > Speermint mailing list
  > [email-masked]
  > https://www1.ietf.org/mailman/listinfo/speermint
  >
  
  _______________________________________________
  Speermint mailing list
  [email-masked]
  https://www1.ietf.org/mailman/listinfo/speermint

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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Sat, 11 Nov 2006 15:34:15 -0500

Chasing down this thread.

In general, I think that intertwining the signaling point entry and
media point entry might be a mistake.  I would prefer to keep these
decisions decoupled.  What do you do if the media location is unknown at
initial setup time, but perhaps known later in the flow?  What do you do
if the media location changes during the call setup?  What if the media
crossing point is from one access network, but the signaling crossing
point is from the home provider?

Maybe it won't make a difference, but creating such constraints seems to
make the solution more brittle.

Mike

> From: Patrick Melampy [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 2:21 PM
> To: 'Michael Haberler'; 'Reinaldo Penno'
> Cc: [email-masked]; 'Uzelac, Adam'
> The real issue here affects signaling and media. It appears 
> to me that the correct algorithm to use would be based on the 
> offered addresses in the SDP, and which border signaling 
> point is closest. The reasons for this are:
> 
> 1.) The signaling originator may not be co-located with the 
> source of media.
> This is often the case with Softswitch/Media Gateway sources 
> of traffic. Its also like to be true with Softswitch Based 
> endpoints (MGCP/NCS) where the call controller is centrally 
> located, but the endpoints are widely distributed.
> 
> 2.) The signaling crossing point that is closes to the source 
> of the media provides a "best crossing point" for the media as well.
> 
> Although I've resisted talking about the media --- its truly 
> important. The location of the media crossing point, and the 
> control of the media, are as important as any other aspect in 
> peering. 
> 
> There are some that would suggest the signaling crossing 
> points and media crossing points are un-related. But to 
> subsequently setup, manage, and control the media with a 
> middle box requires the same determination of the best media 
> crossing point. The mechanisms for doing this "locate the 
> best middle box" are weak at best. Some say use a policy 
> server. However none of the policy server interfaces I have 
> seen proposed by ETSI TISPAN, 3GPP, seem to include a "source 
> ip address" in the request to help choose a destination ip 
> address. While out of the scope of this working group, one 
> should consider the utility of the following suggestion.
> 
> I propose that the best signaling crossing point be 
> determined based on the source of the media. This would 
> provide for a defined crossing point that then could manage 
> the media flows by association.
> 
> From: Michael Haberler [mailto:[email-masked]]
> Sent: Thursday, November 09, 2006 2:38 AM
> To: Reinaldo Penno
> Cc: [email-masked]; Uzelac, Adam
> Subject: Re: [Speermint] Source-based routing
> 
> Reinaldo Penno schrieb:
> > I guess the problem statement is:
> >
> > For a certain call, how to I find the most appropriate 
> egress/ingree 
> > peering point?
> >   
> 
> I'm not sure wether that was what Adam meant - need to clarify
> 
> I see two interpretations:
> - topological optimization of next hop (IP adress, distance..)
> - a parameter into policy application - for resolution 
> services which might give different answers to different originators
> 
> 
> 
> -Michael
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Sat, 11 Nov 2006 16:16:35 -0500

Somehow the idea of "pairing" seems overly restrictive.  While there may
exist a pair of proxies that regularly communicate with each other, I
would not expect those proxies to be monogamous. :)  That is, the same
proxy communicating to SP A may also be a point of entry for SP B.

Mike

> Sent: Saturday, November 11, 2006 4:10 PM
> To: Michael Hammer (mhammer); [email-masked]
> Forgetting media for now --
> 
> But what we need to focus on.....
> 
> Imagine you run a network....and so do I
> 
> We both have many proxies -- lets just say 100.
> 
> We both want to run our networks independently....
> a.) Add new proxies
> b.) Service proxies
> c.) remove proxies
> 
> What is important for this standard body is to define 
> protocols and BCPs that will let carriers communicate the 
> aspects of adjacency that are necessary -- no more.
> 
> I would suggest minimally we need to exchange lists of 
> proxies I would also suggest we might improve our 
> efficiencies of routing if we also exchanged some attributes 
> based on our service level agreement
> 	a.) Rates and speeds
> 	b.) volumes by location
> 
> The question is...are all proxies equal? Should the call 
> originating side care which destination side proxy is chosen? 
> Should it be consistent if possible? Is there benefit to 
> having it controllable and definable? 
> 
> If I were a carrier, I would want the following
> 1.) I would want my proxies logically paired with the proxies 
> on the other side. This would improve detection of service 
> impairments and route-around logic. It would also be easier 
> to debug and maintain.
> 2.) I would want secondary proxies for backup on both sides. 
> 3.) I would want to know what the "offered capacity" the 
> destination proxy is offering to me for my use. This includes 
> counts of calls, and kilobytes of media.
> 
> It seems to me that selection of a proxy on the "local" side 
> would then be logically selecting a proxy on the "far" side. 
> This is actually congruent with what ETSI TISPAN and MSF are 
> proposing for their Peering Edges between carriers. Both 
> sides would have a proxy specifically used for Peering. So 
> the logic for selecting a crossing point is all local to each network.
> 
> So maybe it is truly out of scope if we can agree that there 
> are edge proxies that establish a real or logical "pairing" 
> at peering borders?
> 
> Is this reasonable? Or am I once again smoking crack.
> 
> 
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Saturday, November 11, 2006 3:51 PM
> To: Patrick Melampy; Michael Haberler; Reinaldo Penno
> Cc: Uzelac, Adam
> Subject: RE: [Speermint] Source-based routing : PRIVATE
> 
> This may really be an implementation detail that does not 
> need standardization.
> 
> Mike
>  
> 
> > Sent: Saturday, November 11, 2006 3:46 PM
> > To: Michael Hammer (mhammer); 'Michael Haberler'; 'Reinaldo Penno'
> > Cc: 'Uzelac, Adam'
> > Subject: RE: [Speermint] Source-based routing : PRIVATE
> > 
> > Your of course correct. In an ideal world, we would just let the 
> > source and destination stream packets directly to each 
> other. However, 
> > there may be a desire to use a middle box of some kind for business 
> > and security reasons.
> > If one is to use a middle box or media relay, the algorithm for 
> > selecting one (when there are many possible) is very difficult.
> > 
> > In the ETSI TISPAN and MSF groups, they are proposing a 
> "policy" layer 
> > between the signaling layer, and the media relays. This 
> policy layer 
> > would in theory be able to "figure out" where the best 
> media location 
> > is. I find this mechanism horrible for the reasons you 
> suggest. Lots 
> > of spread out state, that can easily get screwed up with 
> complex call 
> > flows.
> > 
> > It might be heresy to suggest this....but a Transparent B2BUA that 
> > also transparently manages the MEDIA could be very effective and 
> > simple. Lets define transparency as a device that does not 
> modify any 
> > data that defines a dialogue. This is in effect a Session Border 
> > Controller. Some day, the standards bodies will come to 
> grips with the 
> > business realities that carriers have, and the desire that 
> simpler is 
> > better.
> > 
> > Although I wouldn't propose this to the spearmint group as its not 
> > really in scope, I just wanted to suggest that we focus on 
> selection 
> > of the best proxy with the assumption that it is "nearby" where the 
> > media should cross. This will work with any solution being proposed 
> > (ETSI TISPAN/MSF/IETF).
> > Seems reasonable.
> > 
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Saturday, November 11, 2006 3:34 PM
> > To: Patrick Melampy; Michael Haberler; Reinaldo Penno
> > decisions decoupled.  What do you do if the media location 
> is unknown 
> > at initial setup time, but perhaps known later in the flow? 
>  What do 
> > you do if the media location changes during the call setup? 
>  What if 
> > the media crossing point is from one access network, but 
> the signaling 
> > crossing point is from the home provider?
> > 
> > Maybe it won't make a difference, but creating such 
> constraints seems 
> > to make the solution more brittle.
> > 
> > Mike
> > 
> > 
> > to me that
> > > the correct algorithm to use would be based on the offered
> > addresses
> > > in the SDP, and which border signaling point is closest. 
> > The reasons
> > > for this are:
> > > 
> > source of
> > > media.
> > > This is often the case with Softswitch/Media Gateway sources of 
> > > traffic. Its also like to be true with Softswitch Based endpoints
> > > (MGCP/NCS) where the call controller is centrally 
> located, but the 
> > > 2.) The signaling crossing point that is closes to the
> > source of the
> > > media provides a "best crossing point" for the media as well.
> > > 
> > > important. The location of the media crossing point, and
> > the control
> > > of the media, are as important as any other aspect in peering.
> > > 
> points and 
> > > media crossing points are un-related. But to subsequently setup, 
> > > manage, and control the media with a middle box requires the same 
> > > determination of the best media crossing point. The 
> mechanisms for 
> > > doing this "locate the best middle box" are weak at best.
> > Some say use
> > > a policy server. However none of the policy server
> > interfaces I have
> > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip 
> > > address" in the request to help choose a destination ip
> > address. While
> > > out of the scope of this working group, one should consider the 
> > > utility of the following suggestion.
> > > 
> > determined based
> > > on the source of the media. This would provide for a
> > defined crossing
> > > point that then could manage the media flows by association.
> > > 
> > services which
> > > might give different answers to different originators
> > > 
> > > 
> > > 
> > > -Michael
> > >

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 13 Nov 2006 12:19:43 -0500

Yes getting 2-way media is in scope.  Seeing as how you cannot really
have a meaningful multimedia session with media working, I'd say this is
perhaps stating the obvious.  ;-)

Jason 

> Sent: Thursday, November 09, 2006 3:11 PM
> To: Reinaldo Penno; Patrick Melampy; Michael Haberler
> Cc: [email-masked]
> Is there consensus around the notion that media 
> considerations are in scope of SPEERMINT?  It's not always 
> the case, but it should be a consideration when determining 
> next-hops route responses to a location function look-up.  I 
> would like to point out that this becomes very difficult in 
> ENUM/DNS next-hop determinations.  Hence the existence of the 
> INVITE/3XX next-hop determination method.
> 
> -AU
> 
> PS - please read "media considerations" as _NOT_ meaning 
> exclusively CODECs. 
> 
> Sent: Thursday, November 09, 2006 11:56 AM
> To: Patrick Melampy; Michael Haberler
> As I side note I mentioned in the IETF meeting that we keep 
> pushing media aside and only talking about signaling but what 
> mostly matters in terms of user experience is the media.  So, 
> I agree with you that media is important.
> 
> About your suggestion below, that's a nice insight, but it is 
> still not clear to me how from the source IP address the 
> proxy finds the notion of "distance". Of course the first 
> peering proxy that receives the signaling can look at number 
> of Vias or TTL or others.  But how would this proxy find out 
> the distance between the endpoint and other peering proxies 
> in order to send a correct 302, for instance? 
> 
> So, the "default" peering proxy can try to find that out 
> (even if consulting some external DB) or the endpoint could 
> try itself. The endpoint could send OPTION messages with 
> increasing Max-Forwards to a coupld of proxies, or some other 
> funky method.
> 
> Thanks,
> 
> Reinaldo
> 
>  
> 
> > Sent: Thursday, November 09, 2006 11:21 AM
> > To: 'Michael Haberler'; Reinaldo Penno
> > (MGCP/NCS) where the call controller is centrally located, but the 
> > endpoints are widely distributed.
> > 
> > There are some that would suggest the signaling crossing points and 
> > determination of the best media crossing point. The mechanisms for

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 13 Nov 2006 12:22:02 -0500

Excellent find...  Perhaps I can observe that we keep asking if stuff is
in scope or not and that we spend a lot of time on this and suggest that
it is not terribly helpful.  Let's keep focusing on developing the
documents and work at hand.  :-)

Jason 

> Sent: Thursday, November 09, 2006 3:46 PM
> To: Stastny Richard; Uzelac, Adam; Patrick Melampy; Michael Haberler
> Cc: [email-masked]
> It is in scope
> "However, in order to achieve real-time Session PEERing, both 
> signaling and media flows must be taken into consideration. 
> In addition, the working group recognizes that there will be 
> use cases that require SPEERMINT to focus on the interaction 
> between the application layer and lower network layers, or 
> the dependence of specific application layer use cases on 
> lower layers, so SPEERMINT will have to be prepared to solve 
> these problems as they arise."
> 
> Thanks,
> 
> Reinaldo 
> 
> > From: Stastny Richard [mailto:[email-masked]]
> > Sent: Thursday, November 09, 2006 12:33 PM
> > To: Uzelac, Adam; Reinaldo Penno; Patrick Melampy; Michael Haberler
> > Cc: [email-masked]
> > IMO it is in scope, but our first priority is to get a 
> peering going 
> > at all
> > 
> > media is only relevant in some use cases and the problems 
> are not easy 
> > to resolve. So it should have second priority - it will 
> also take some 
> > time to work out the use cases, etc.
> >  
> > Richard
> > 
> > ________________________________
> > 
> > Von: Uzelac, Adam [mailto:[email-masked]]
> > Gesendet: Do 09.11.2006 21:11
> > An: Reinaldo Penno; Patrick Melampy; Michael Haberler
> > Cc: [email-masked]
> > Betreff: RE: [Speermint] Source-based routing
> > 
> > 
> > 
> considerations are in 
> > scope of SPEERMINT?  It's not always the case, but it should be a 
> > consideration when determining next-hops route responses to 
> a location 
> > function look-up.  I would like to point out that this becomes very 
> > difficult in ENUM/DNS next-hop determinations.  Hence the 
> existence of 
> > the INVITE/3XX next-hop determination method.
> > 
> > -AU
> > 
> exclusively 
> > CODECs.
> > As I side note I mentioned in the IETF meeting that we keep pushing 
> > media aside and only talking about signaling but what 
> mostly matters 
> > in terms of user experience is the media.  So, I agree with 
> you that 
> > media is important.
> > 
> > About your suggestion below, that's a nice insight, but it is still 
> > not clear to me how from the source IP address the proxy finds the 
> > notion of "distance". Of course the first peering proxy 
> that receives 
> > the signaling can look at number of Vias or TTL or others.  But how 
> > would this proxy find out the distance between the endpoint 
> and other 
> > peering proxies in order to send a correct 302, for instance?
> > 
> > So, the "default" peering proxy can try to find that out (even if 
> > consulting some external DB) or the endpoint could try itself. The 
> > endpoint could send OPTION messages with increasing 
> Max-Forwards to a 
> > coupld of proxies, or some other funky method.
> > 
> > Thanks,
> > 
> > Reinaldo
> > 
> > 
> >