Subject: RE: [Speermint] Source-based routing

From: "Patrick Melampy" <[email-masked]>
Date: Sat, 11 Nov 2006 16:09:39 -0500

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.

-----Original Message-----
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

> -----Original Message-----
> From: Patrick Melampy [mailto:[email-masked]] 
> 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.
> 
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Saturday, November 11, 2006 3:34 PM
> To: Patrick Melampy; Michael Haberler; Reinaldo Penno
> Cc: [email-masked]; Uzelac, Adam
> Subject: RE: [Speermint] Source-based routing
> 
> 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
> 
> 
> > -----Original Message-----
> > From: Patrick Melampy [mailto:[email-masked]]
> > Sent: Thursday, November 09, 2006 2:21 PM
> > To: 'Michael Haberler'; 'Reinaldo Penno'
> > Cc: [email-masked]; 'Uzelac, Adam'
> > Subject: RE: [Speermint] Source-based routing
> > 
> > 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.
> > 
> > -----Original Message-----
> > 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
> > 
> > _______________________________________________
> > 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: Andrew Newton <[email-masked]>
Date: Sat, 11 Nov 2006 18:19:03 -0500

> I would suggest minimally we need to exchange lists of proxies

All of this can be done with the already defined SRV and NAPTR  
mechanism.  I don't see a need to invent something new here.  As I  
suggested before, the SRV/NAPTR BCP should explain how to:
1) add new proxies
2) service proxies
3) remove proxies

> exchanged some attributes based on our service level agreement

Ok.  You can't do that in NAPTR or SRV records, but I suspect it is  
much better to be in a contract than anyplace else.

-andy

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Sun, 12 Nov 2006 04:01:56 +0000

I'm not sure about item #1 ("I would want my proxies logically paired
with the proxies on the other side.").  In networks with which I am
familiar, L5 peering devices are not generally collocated nor do 1-to-1
relationships between them, exist.

Tim

p.s. I'm not an operator but I work for one.  Not that that should give
my comments any more (or less) significance.

> Sent: Saturday, November 11, 2006 3:10 PM
> To: 'Michael Hammer (mhammer)'; [email-masked]
> 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? 
> 
> 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.
> 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 
> 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?
> 
> This may really be an implementation detail that does not 
> need standardization.
> 
> Mike
>  
> 
> > 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.
> > 
> "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.
> > 
> > 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