Subject: RE: [IPTEL] TRIP for gateways

From: James Kempf <[email-masked]>
Date: Thu, 30 Nov 2000 11:08:46 -0800 (PST)

Jonathan,

>> 
>> I'm curious why you need to have the gateway push the 
>> reachability info
>> to the location server. Why can't the location server pull it from the
>> gateway?
>> 
>> In this scenario, the location server acts as a user agent and the
>> gateway acts as the service agent. The service advertisement consists
>> of the PSTN gateway's attributes and reachability info (as I 
>> understand
>> it from below, telephone prefixes). The location server periodically
>> performs an SLP SrvRqst for gateway service URLs, then performs an
>> SLP AttrRqst for the attributes. Alternatively, the location server
>> can include the SLP attribute list extension (see 
>> draft-guttman-svrloc-attrlist-ext-04.txt) to have the attributes
>> delivered along with the service URL.
>
>Indeed, the fundamental question is push vs. pull.
>
>I think gateway routing needs to be push primarily for performance reasons.
>Calls arrive at a proxy server at potentially very high rates; if each call
>needs to generate an independent query for service, you end up (1) adding
>latency to each call setup for the query/response, (2) introducing a serious
>processing burden for all devices, (3) add a lot of network traffic for the
>queries and responses. By pushing the information as it changes, we
>eliminate the additional call setup latency, reduce the processing load, and
>reduce the messaging load. 
>

In a pull model, I don't think that each call needs to necessarily cause
an independent query for services.

If each service advertisment contains a lease or timeout, then the
proxy server only needs to redo its query when the advertisement expires.
The granularity will determine what the messaging load and processing
load is, and needs to be set so that it reflects a realistic apprasial
of how often the external reachability information will change.

Of course the probability of getting stale information is higher with a pull 
model if the lifetimes are set too long,  so the tendency in situations where 
the service information changes dynamically is to decrease the lifetime, upping 
the processing load. 

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, then perhaps a service discovery approach based on pull  seems 
like it would be more appropriate if the gateway servers' reachability service 
doesn't change often.

		jak
		
PS: Incidently, we have been working on a push protocol for SLP, to
allow a service client to subscribe to notifications of changes
in particular services. We are slowly moving the draft to Experimental.
The specification is in draft-kempf-srvloc-notify-04.txt. The design
pays particular attention to scalability issues, since we wanted
to avoid problems with network overload such as occured with 
Netware 4.0 SAP and at least one implementation of SLPv1 that was not
in compliance with RFC 2165.

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

---

From: "Hussein F. Salama" <[email-masked]>
Date: Thu, 30 Nov 2000 16:46:33 -0800

James Kempf wrote:
> 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.

Hussein

> then perhaps a service discovery approach based on pull  seems

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147