Subject: RE: [IPTEL] TRIP for gateways

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 3 Dec 2000 13:31:02 -0500

> -----Original Message-----
> From: Hussein F. Salama [mailto:[email-masked]]
> Sent: Thursday, November 30, 2000 7:47 PM
> To: James Kempf
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [IPTEL] TRIP for gateways
> 
> 
> > If what you are trying to do is distribute routing information, then
> > something like a routing protocol that does push seems like it might
> > be the better approach, since any failure of freshness pretty much
> > invalidates the information. However, if what you are trying to
> > do is locate suitable gateway servers based on where they
> > can get you to, 
> 
> We're not just trying to locate the suitable egress gateway. 
> We're also
> trying to determine the best route to get to that gateway. This route
> may consist of multiple signaling proxies.

I think some of the disagreements in terms of push vs. pull come from
different views on what we are actually talking about.

My impression is that we were talking about the egress gateway to proxy
only, thus covering a single hop, and being only within a single ITAD. 

The arguments for push become more persuasive as you move farther into the
domain, and then ultimately inter-domain. Indeed, TRIP is designed for
inter-domain and it is push.

Focusing only on the gateway issue, there are other factors driving push
that have not been mentioned. First, recall that any gateway can, in fact,
terminate a call to any destination number - its a question of cost. So, if
a proxy is managing a farm of say 20 gateways, all of them could service
each call. Thus, in the pull model, the proxy would query, and all 20
gateways would respond with a yes. This is wasteful (I understand caching
can reduce this). 

The model for this architecture is, I believe, one where we wish to program
the policy for call routing into the proxies alone, and let the gateways be
the source of the data that is used as an input to the policy process. The
output of this process is the decision about where to forward a call. I
think this kind of model is ultimately best served by a push protocol, since
it has the fastest response times and least amount of network overhead. A
pull protocol would be better if there were many, many entities that could
query for service. There, push becomes wasteful. But thats not the case
here. We are talking about a single (or a few, given backups), servers that
use this data. 

Query protocols are also transactional in nature, generally requiring
per-request authentication and authorization. Again, this makes sense in
cases where there may be many queriers (as is the case when the server is a
printer and the queriers are end users), but it is not useful when the
querying is over a pre-established relationship, as is the case here. In
that model, it makes much more sense to establish a secure connection ahead
of time, and then not perform authentication or authorization once that has
happened. This is how TRIP (and indeed, any other push protocol) would work.

So, in the model we have here, I think push is a clear winner. I'd be
interested to hear if anyone can provide concrete benefits for the pull
protocols in this model; I'd also be interested to hear if you think that
the gateway "registration" problem should be solved by a different model.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel