Subject: RE: [Ecrit] draft-polk-dhc-uri-00

From: [email-masked]
Date: Fri, 23 Sep 2005 10:26:04 -0400

Henning,

There are three assertions that I will make that seem to favor the use
of DHCP as part of the solution:

Robustness in the face of partial network failure:  Why is it that we
promote pushing the intelligence to the edge as a means of improving
reliability, yet in this case, where crucial data could be pushed/pulled
in advance of an emergency to a point local in the network to the
endpoint that needs it, we seem to be saying no, it is better to
centralize this distantly in the network somewhere?

Closely related dependencies:  We seem to acknowledge that the key to
determining where to route the call is based on the location information
that is local to the network point of attachment and that local
mechanisms are good enough to deliver that information to the caller,
but that those same mechanisms are somehow insufficient to deliver
derived information based on that location.

Subsequent correctability by the application proxies:  Independent of
what the client does in terms of initiating a call, the application
servers always have the ability to override and re-route the call if
they know the information that the client had and have better (more
current) information derived from their own sources.

The design of the network needs to account for multiple possible failure
points, including the location and mapping services themselves.  There
is a time dimension to this that suggests that at the time of the call,
the dependencies may be more reliable if they share the same fate as the
client, i.e. local to the client versus having multiple possible failure
points between the client and the relied on element/data.

Let's not design in single points of failure.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Henning Schulzrinne
> Sent: Thursday, September 22, 2005 9:15 PM
> To: Ted Hardie
> Cc: 'ECRIT'
> Subject: Re: [Ecrit] draft-polk-dhc-uri-00
> 
> Ted Hardie wrote:
> 
> > This is why I believe we need to drill down to details.  If, for 
> > example, the system told you what the local tel: URI was 
> for emergency 
> > calls (tel:911, tel:999, tel:112, etc.), there is some marginal 
> > utility there and the likelihood of the information being
> 
> This idea has popped up in the past and isn't really related 
> to the DHCP discussion, but...
> 
> I don't think this is a workable idea. The DHCP server has no 
> idea what proxy server is going to resolve tel URIs for me. 
> If I use sipgate.de as my VSP and my Verizon DHCP server 
> tells me to use tel:911, I suspect that this is not going to 
> work very well when my SIP request hits the proxy somewhere in Munich.
> 
> If the proxy server is specified somehow and known to be 
> local to the caller, there is no advantage here - the end 
> system might as well just have the proxy server resolve the 
> SIP request, marked as an emergency call, to the appropriate 
> number or SIP URI.
> 
> Henning
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Sep 2005 10:58:41 -0400

Mike,

I would certainly not be in favor of a design with a single point of 
failure. Indeed, I had previously argued (and written up) a design that 
encourages local caching of mapping information. You may remember the 
long and arduous discussions on 'minimal connectivity'.

Thus, I'm in favor of designing a mapping protocol that is 
caching-friendly, but that allows predictable caching behavior to make 
it easy to predict who is going to see what information. It is very 
difficult to do that if there are all kinds of less-than-deterministic 
paths of information flow, using an unknown (to the data source) variety 
of delivery protocols that cannot convey, for example, TTL information 
or may disagree about the meaning of that information.

In other words, introducing this extra mechanism is not necessary for 
local information retrieval, but seems to make it less predictable and 
less robust. We have experience with same-protocol caching (e.g., in DNS 
and HTTP), but very little with multi-protocol caching. The closest 
analogy I can think of, largely outside my area of experience, is the 
IGP/EGP split in routing, where you sometimes need to propagate external 
routing information via an IGP such as OSPF. We do know that protocol 
translation is generally painful and may imply information loss. 
Sometimes there are strong reasons to do this, but I have yet to hear a 
reason why this is such a case. I have only heard lots of "we *could* do 
this" and "it's no worse than X".

Inherently, more mechanism means more complexity, more fault scenarios 
and more interop testing, so there should be a strong motivation ("can't 
reasonably do it any other way") before adding more.

Henning