Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide

From: James Kempf <[email-masked]>
Date: Thu, 11 May 2000 15:24:45 -0700 (PDT)

Couple of comments.

>3. AUTHENTICATION (end-to-end) 
>============================== 
>We have the following potential authentication requirements: 
>- Called party id 
>- Calling party id 
>- Who we thought we were calling 
>

This doesn't say anything about a client authenticating a proxy,
but that seems to be implied by the subsequent discussion.

>Dean Willis and Robert Sparks objected that you need app-level security
>when you don’t
>have transitivity of trust, and there are applications where you do not
>have transitivity
>of trust. For example, consider a call where you involve multiple
>providers for that call
>(multi-proxy authenticate). Basically, it’s not enough to have either
>end-to-end or
>hop-by-hop security; you also need to have end-to-intermediate security. 
>
>This was a different model than had been worked on for the majority of
>the meeting
>however no one argued against the validity of it. Since it contradicts
>some of the
>earlier assumptions and decisions made during the meeting, each of these
>will have to be
>revisited. 
>  

I`m not exactly sure what is meant by "application level security" here.
Does "application" mean "application built on top of SIP" or does
it mean "SIP as an application protocol?

Certainly in the case of cellular, it will be the case that the
proxy will be changing. When the mobile terminal roams outside
of it's cellular provider's domain, the new proxy needs to be authenticated
with the mobile terminal, and vice versa. This roaming can happen either 
statically or dynamically, i.e. statically when the mobile terminal comes up
in a foreign domain, or dynamically, when a call is in progress
and the mobile roams into an area where its provider does not
have coverage but a provider with a roaming agreement does.

		jak

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 May 2000 20:10:06 -0400

> but that seems to be implied by the subsequent discussion.

e2e authentication is not about client authenticating a proxy, its about
clients authenticating clients. hBh authentication involves client
authentication of proxies and vice a versa.

> it mean "SIP as an application protocol?

The latter.

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 12 May 2000 17:36:38 -0700 (PDT)

The latter.

 > with the mobile terminal, and vice versa. 

   That sort of pre-supposes that the proxy the
   handset contacts when it's roamed isn't its
   home proxy. I'm not sure I see why that
   wouldn't still be the case. I hope people
   aren't getting buffaloed into some garden
   walls kind of mentality where the service
   provider gets to keep their stranglehold on
   services.

   If you ask me, the only thing I want the
   cellular service provider to provide me is
   bits on the air (ie, access, QoS). Where I get
   routing information, etc, should be my choice.
   Settling the bits on the air could have a 
   component which involves SIP (ala DQoS), but
   it shouldn't force me to get services through
   SlamAir if don't want to.

   Not that that has anything to do with SIP
   security.

		Mike

---

From: Giuseppe Ricagni <[email-masked]>
Date: Mon, 15 May 2000 17:38:22 +0200

Michael Thomas wrote:

>    wouldn't still be the case.

the current assumption is to have a "proxy" in the visited domain (it might be
something more than a pure proxy).

There are many reasons behind this choice (I might even be unaware of many
others...). Just three examples:

   * possible optimizations (e.g.: signalling for a basic call to an Australian
     fixed network number from an Italian mobile roaming to Australia could be
     processed locally, without any "tromboning")
   * some people claim the "proxy" should also perform some kind of admission
     control for the calls. The proxy in the home domain has no information on the
     visited domain
   * the PNO who runs the visited network might desire to have some kind of
     knowledge on what is going on in his network, from a call control point of
     view

Giuseppe

----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:[email-masked]
----------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Mon, 15 May 2000 11:49:10 -0700 (PDT)

>      processed locally, without any "tromboning")

   If during call setup there needs to be a round
   trip to the home network, it pretty much negates
   any advantage of proxying the call locally. 

 >      control for the calls. The proxy in the home domain has no information on the

   This is true of the foreign domain too. How does
   any proxy have knowledge of network topology? 

 >      knowledge on what is going on in his network, from a call control point of

   Absolutely. However, admission control can
   be done through other means. Namely, you could
   use RSVP to signal your intent to consume some
   air resources and authenticate/authorize that
   traffic. SIP normally has no part in bandwidth
   allocation, which is a feature not a bug. 
   Even if you believe the manyfolks (DQoS) model
   of implicit linkage, I still don't see why
   there is any advantage to having a local proxy
   do call routing vs my home proxy. I can think
   of a lot of disadvantages though.

	Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 15 May 2000 18:57:47 -0400

Let me chime in with strong support of what Mike is saying. One of the
great strengths of SIP is that there is a complete separation of
transport (i.e.,voice) from signaling (read: services). This means that
I can buy my transport and access for VoIp from one provider, but get
applications and services from one or more other providers. This provide
disaggregation of what has traditionally been a coupled service
offering. Such disaggregation opens the door to massive innovation in
the services area, since any yahoo can buy application hosting services,
run on application on the hosted providers SIP servers, and provide
service to anyone in the world, accessing from any IP device, wireless
included.

This is the model that made the web successful. Would it had evolved if
ONLY my ISP could provide web content? No way. There would *never* had
been a web if content and services for web had been coupled to access
and transport. Never. Please lets not make this mistake with
communications services.

Efforts to link transport and access with services and signaling on the
Internet are fundamentally futile, flawed, and will, in the end, reduce
competition and innovation. But, I suppose thats the point.

So, as it relates to wireless, just because some local provider is
offering me transport services does not mean I should be forced to use
them for signaling and features. 

>    any advantage of proxying the call locally.

Please note that this service (optimized dial plans based on roaming) is
still possible even if I go directly to the home network. All I need to
do is indicate to my home proxy where I am, so it knows what dial plan
to apply. In fact, dial plan administration is, in general, a service
that can be outsourced to any ASP (of course, only local ASPs may wish
to provide it, but the point is anyone can).

>    any proxy have knowledge of network topology?

Call admission control in proxies >>will never work<<. As Mike suggests,
this belongs in the transport layer, not the signaling layer.

-Jonathan R.

---

From: David Daiker <[email-masked]>
Date: Tue, 16 May 2000 16:50:23 -0400 (EDT)

> this belongs in the transport layer, not the signaling layer.

Doesn't a proxy do this everytime it returns a 401 or 407 response
to an INVITE ?

Isn't PacketCable DCS doing this also ?

How about h.323 ? are you suggesting that if I am visiting China,
and make calls from a h.323 endpoint I can forward admission and location
requests to my favorite gatekeeper back in the States ?

I'm obviously missing something...

david

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 May 2000 17:08:33 -0400

> Doesn't a proxy do this everytime it returns a 401 or 407 response

Um, no. Proxies generate 407s to authenticate users to SIP resources,
not perform admission control based on QoS for the media path.

> Isn't PacketCable DCS doing this also ?

No. The admission control for RSVP is still done in the media path. It
is only policy based authorization that is done in the proxy, and this
authorization is passed to the gate performing QoS admission control.

> requests to my favorite gatekeeper back in the States ?

No. I am saying no proxy can usefully make admission control decisions
based on bandwidth, QoS, or media path resource availability. This holds
for the proxy in China and in the US. They can, of course, make
"admission control" decisions about access to resources they actually
provide, such as SIP features.

-Jonathan R.

---

From: Giuseppe Ricagni <[email-masked]>
Date: Tue, 16 May 2000 17:28:35 +0200

> to provide it, but the point is anyone can).

I was just talking about the PDD (post dial delay) for a call that can
be processed
locally, without any kind of message sent to the home network.

Morever, if we start from the assumption (for the above mentioned
reasons) that all SIP
signalling goes through at least one proxy, the advantages of having a
local proxy is
relevant for example in case of (SIP, hard) handovers (I' m always
referring to Henning' s approach to SIP mobility). The reduced RTT
results in a much smaller number of lost packets.

Giuseppe

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 May 2000 00:35:49 -0400

> locally, without any kind of message sent to the home network.

I think the RTT for going to the home network is going to be a drop in
the bucket compared to the typical PDDs in wireless today. The RTT for
going to the home network is going to have to be reasonable to carry
voice anyway, so we are talking a few hundred milliseconds, worst case?
It takes my cell phone 5 seconds for PDD now....

> results in a much smaller number of lost packets.

How is that? Its a dangerous game to make strong assumptions on loss
models like this.

In any case, I think that optimizing an architecture based on
assumptions about loss distributions and latency is somewhat
short-sighted. Lousy network quality is going to kill you on the
compressed voice traffic long before the signaling gets really blown
away. Even from a human factors perspective, most people will tolerate
long PDDs but not high voice packet loss rates. If the signaling loss is
really bothering you, deploy good networks with diffserv giving great
service to port 5060. Eventually these network performance problems will
get solved. But, fundamental architectural decisions don't get changed.
The ability to choose anyone as my applications provider, and not suffer
horrible voice quality (since the audio always goes direct) is such a
huge win for competition and service innovation. Saying no to that to
save 50ms on signaling latency seems such a shame. This was my point
about web. If I had to *rely* on my ISP replicating the content in order
to fetch it, there never would have been a web. It is only because
anyone, anywhere on the Internet could set up shop, and anyone, anywhere
could access it, that we had the huge growth in this service. 

-Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 17 May 2000 01:01:52 -0500

> provide, such as SIP features.

Actually, I think there might be an exception. Let's say we have a large network that mixes several DiffServe classes -- for simplicity, let's say "best effort" and "priority" clases. Assume that there is normally a relatively high ratio of best-effort to priority traffic in the network.

One might a heuristic for traffic engineering that works like this:

Assume a network monitoring system that can provide both a rough estimate of the ration of best-effort to priority traffic on the backbone and on specific links. Feed this data into access proxies.

Define a minimum ratio for both of those metrics, say 2-1.  A proxy could then provide a "network health guidance" effect for edge devices.

Sure, we can't KEEP an unfriendly app from jumping in during a peak congestion period, but we could certainly ADVISE friendly apps that it woudn't be a good idea to send more traffic right now.

Or one could just put the QoS function under control of the proxy, which activates the last clause in Jonathan's  argument.

--
Dean

--
Dean
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú?

---

From: Giuseppe Ricagni <[email-masked]>
Date: Wed, 17 May 2000 14:12:44 +0200

> It takes my cell phone 5 seconds for PDD now....

Well, you might want to consider changing  mobile operator... :-))

> How is that? Its a dangerous game to make strong assumptions on loss

I think we are talking about two different things.
I was just sayng that, according to Henning's model, to put it very simple, when you change
IP address you shuld send an Invite to your correspondent host containing your new IP
address (plus re-registering with your proxy, to allow for signalling to be sent to the new
address).

If we assume (by hipotesys) that all SIP messages must go through at least 1 proxy, and if
we have an active conversation between two Italian mobiles located in Australia, the so
called "handoff delay" is one RTT between Australia and Italy, which can be something like
300 msec or (very likely) more.
Even with a 300msec figure, you would en up losing some 15 voice samples, which is something
definetly undesirable.

OTOH, with a local proxy, you wouldn' t lose more than 1 or, at worst, two samples.

Giuseppe

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 May 2000 08:53:00 -0400

There seem to be two cases:

1) The callee is local and the caller is roaming. In that case, there's
no reason to have the caller go through its remote (home) proxy for
sending SIP requests (except if that home proxy performs, for example,
authentication services).

2) The callee is roaming (independent of where the caller is). The SIP
call has no choice but to go the home proxy of the callee first, since
that's the only reference point for the caller. It has no clue that the
callee is standing right next to him/her.

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Wed, 17 May 2000 10:10:05 -0400

>It takes my cell phone 5 seconds for PDD now....

FWIW - I would love only 5 seconds!

My home office phone (Bell Atlantic) is often forwarded to my AT&T Wireless
phone. However, I'm usually in a Comcast serving area (i.e., roaming).

When I am at home when someone calls my forwarded home office
phone ... it pings (to let me know a call has been forwarded) ... then I
wait .... and wait some more ..... usually 6 to 8 seconds MINIMUM ... before
my cell rings. And that is over and above the usual PDD to Bell Atlantic.

Why do I put up with it? Two reasons ... 1) no other choice and 2) most
time the Caller-ID is provided so I can call back the party that has just
given up on me because of the long PDD.

Just think of how many SS7 messages and voice trunk seizures were
required for the present PSTN in this case ..... every hop "set up" requires
signaling ... in this case between three service provider (trust) boundaries.

How can the RTT for going back to the home network (for the simple, no
special features case, only once) be worse than what I have now? And I
consider what I have now a useful service ... considering the alternative.

Every replacement technology challenges some of the "requirements"
upon which the present generation of technology is built upon. Optimizing
PDD for the PSTN-to-PSTN phone call was one of these requirements.
And while I still agree that minimizing PDD with some reasonableness of
the tradeoffs involved is still a laudable goal ... one should compare the
PDD tradeoffs of todays mobile/cellular world to indeed verify that what
we propose is -  in many cases - ALREADY BETTER than some usual
mobility cases (like my experience above).

As for the loss arguments .... I also agree with Jonathan. Moreover, we
have taken steps in IETF/sigtran to create transports that do not have the
head of line blocking and do have "fast retransmit" capability that our
more time sensitive signaling messages require (i.e., SCTP).

>could access it, that we had the huge growth in this service. 

Michael A. Ramalho, Ph.D.
Cisco Systems
1802 Rue de la Port
Wall Township, NJ 07719-3784
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578

---

From: Giuseppe Ricagni <[email-masked]>
Date: Wed, 17 May 2000 16:10:23 +0200

Henning,

> authentication services).

right !
This also applies to roaming mobile-to-fixed, local endpoint.

Authentication is the real open issue at the moment, but what about having
a full authentication involving the home domain at registration time (when
I switch on the mobile), and a local authentication with the local proxy
when the endpoint sends the Invite ? Would this be feasible ?

> callee is standing right next to him/her.

As long as I set up a brand new call, you are absolutely right.

In my handover example, anyway, I was sending a new Invite with the same
call identifier of an existing call just to update the IP address where my
correspondent should send voice traffic, and I was trying to reduce the
handoff delay to a minimum. The costraint I put was that all SIP messages
were going through at least 1 proxy.

Now, if both terminals are roaming, and they are in the same domain
(typical case of two friends on vacation), since there already is an
established call between the two, the local proxy sholud be able to route
the Invite message towards the correspondent host without involving the
home network.

Correct ?

Thank you
Giuseppe

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 May 2000 11:56:20 -0400

Just as a data point: Tony Eyers and I have looked at signaling
performance under redirect and proxy assumptions, for both ("optimized")
TCP and UDP. See the paper in the IPtel 2000 workshop at
http://www.fokus.gmd.de/events/iptel2000/pg.php3

This is based on recent real Internet measurements, assuming that SIP
will not use either reserved flows or BBE diff-serv classes. If one were
to use standard TCP with its long initial retransmit timer, things get
really bad (we didn't look at this since it's too bad to be
interesting...), but even with cross-country redirection, call setup
delays are rather modest. Note that we looked at percentiles, not
averages.

"Michael A. Ramalho" wrote:

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 May 2000 12:10:32 -0400

> when the endpoint sends the Invite ? Would this be feasible ?

I should have been more precise: we need to distinguish roaming between
domains (from, say, columbia.edu to stanford.edu) and roaming between
proxies that share information/data (say, detroit.att.com and
nyc.att.com). In the latter case, presumably the Detroit server has
access to my NY "home" entry and can perform all normal outbound proxy
functions, including any outbound scripts, address books or other
personalized logic. The tricky part is how the UA decides what to do. We
have three local-proxy mechanisms:

- DHCP
- multicast
- local configuration (hard-wired)

The first two would presumably point to stanford.edu or detroit.att.com
as I roam away from Columbia, while the third is likely to be always
nyc.att.com.  With the DHCP option, the UA could guess as to whether to
use the home proxy or not, based on domain name. It would have to know,
somehow, whether the proxy is sharing information with home or not.

> were going through at least 1 proxy.

See our SIP mobility paper and other more recent work that addresses
this, at a high level. We still need to work out the details as to how
this work, as it requires that the "away" proxy proxying the
registration modifies the Contact to point to it rather than the mobile,
for example.

> the Invite message towards the correspondent host without involving the

Again, this depends on naming and whether a local outbound proxy allows
"foreign" registrations. If I visit Stanford and the Stanford proxy
allows me to register with my cs.columbia.edu address AND somehow
short-circuits INVITEs from a Stanford caller to me (using my
cs.columbia.edu address), this avoids the trip home, but has obviously
bad consequences if I'm relying on my cs.columbia.edu proxy to do call
filtering for me. Thus, I may not particularly appreciate that *unless*
I can get the Stanford proxy to inherit my call logic. Currently, I can
only do this by uploading the CPL script, say, which means my mobile has
to carry it around. One could presumably allow a level of indirection
where I register at Stanford with my a pointer to my canonical master
CPL script.

I doubt whether this complexity is worth the minor saving in call setup
delay. 

Thus, just about anything can be done, depending on naming, but each
choice has consequences on available call features.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 May 2000 10:22:33 -0700 (PDT)

Dean Willis writes:
 > Assume a network monitoring system that can
 > provide both a rough estimate of the ration of
 > best-effort to priority traffic on the backbone
 > and on specific links. Feed this data into access
 > proxies.

   Doesn't this violate the law of "You are not
   alone"?

   Besides, even if it were just EF RTP traffic
   controlled by SIP proxies, how would they
   synchronize amongst themselves?

   Even with the implicit linkage model of
   signaling and admission authorization of
   DQoS, it's still the edge routers making the 
   admission control decision from a "can we
   support the bandwidth" standpoint into the
   diffserv cloud.

	       Mike

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 17 May 2000 17:16:02 -0500

Comments inline

Mike ponders:
> Dean Willis writes:
>  > Actually, I think there might be an exception. Let's say we 
> have a large network that mixes several DiffServe classes -- for 
> simplicity, let's say "best effort" and "priority" clases. Assume 
> that there is normally a relatively high ratio of best-effort to 
> priority traffic in the network.
>  > 

We're not making assurances -- we're making guesses about the state of the network. The question: Does the core network look like it will support another EF flow right now? The law of large numbers provides an averaging effect here. Remember, this is a big, densely-connected core.

>    synchronize amongst themselves?

They don't need to. One call makes little difference to the core network. We just define the admissions threshold well into the "safe" area. Statistical distribution takes care of the rest.

>    support the bandwidth" standpoint into the

Different edge -- it's the edge of carrier network vs. the edge of customer network. And the feedback is through network management to SIP, and it could be completely decoupled from a DQOS.

Consider it in an aggregation model, like a donut. The chewy outside parts of the donut are controlled by IntServ. Traffic leaps across the DiffServ donut-hole only if the heuristic process thinks (IE, is reasonably sure) that there is adequate bandwidth.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 May 2000 01:52:36 -0400

Giuseppe Ricagni wrote:

> OTOH, with a local proxy, you wouldn' t lose more than 1 or, at worst, two samples.

This presumes that there aren't any other proxies which decide to
record-route. When a call is made, it will generally pass through many
proxies, each providing differing levels of service. Some of these will
want to record-route. I don't want to prevent them from doing so.
Optimizing a system for the special case where (1) both caller and
called party have home domains that are far, (2) they are both roaming
in visiting domains that are close, (3) there are no other proxies on
the path which record-route, seems like you are optimizing for the wrong
case.

Your assumption is also that handover is done through a re-INVITE to the
new address once its known. This need not be the case. In a scenario
with a smoother handover, I can imagine a brief period where the roaming
mobile has both addresses - one in the old domain, one in the new. When
it obtains the new one, it does a re-INVITE to *add* a new media stream
targeted to the new address. This means it will get both stream of
packets during this transition period. Once these new packets start
arriving, it can do a re-INVITE again, turning off the stream targeted
to the old address. It can then release the old address.

I admit ignorance in not knowing if such a smooth handover at the IP
level is possible. But, if so, it completely decouples the signaling RTT
from any packet loss during handovers.

-Jonathan R.

---

From: Romeo Zwart <[email-masked]>
Date: Thu, 18 May 2000 11:22:17 +0200

Hi Henning,

>http://www.fokus.gmd.de/events/iptel2000/pg.php3

These measurements did not include the PRACK model. Do you
know if anyone is working on a followup that addresses the reliable
provisional response model as well?

>delays are rather modest. Note that we looked at percentiles, not

This is a very interesting simulation. Has a more detailed analysis
of these results been published? Some of the results seem rather
counter-intuitive.

For example, if you compare graphs 12 (simple call NY-Chi) and 14
(redirect, NY-West Coast), the minimum setup delay roughly triples.
Considering the combined effect of the added redirect and the larger
distance, this is a trend you might expect, albeit a rather large increase.
Comparing the same graphs on the 95 percentile scores, the result
seems to be that variation increases a lot, which again seems to
make sense. However the graphs also suggests that the trend is
downward, rather than upward, i.e. from roughly 600 ms in the
simple call case, down to 200 ms on many of the observed days
for the redirected Coast-to-Coast case.

Romeo

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 May 2000 07:27:08 -0400

> provisional response model as well?

Not that I know of, but PRACK would seem to be a fairly limited-use
model. You'd have to address also the whole QoS setup mechanism, I
suppose...

> of these results been published? Some of the results seem rather

Not sure if you looked at the paper or the slides, but the paper is
about as complete as we have at this point.

> for the redirected Coast-to-Coast case.

Tony, want to comment?

---

From: [email-masked]
Date: Thu, 18 May 2000 22:05:19 +1000

Romeo, Henning,
              As you say, the results that you mention appear
counter-intuitive. A detailed discussion appears in section
VII of the paper. However, the reason for the apparent discrepancy
(i.e. the New York-Chicago path having a higher 95th delay percentile
than the longer New York-West Coast one) is the consistently higher
error rates seen on the New York-Chicago path. These errors cause
SIP timeouts, and hence push the 95th percentile over 500 msec.

As you mention, the graphs show minimum delays which
reflect the respective propagation delays expected over the
two paths. The 95th percentile results show two
features: the delay arising from the 500 msec SIP timeouts,
and the delay arising from queueing variations
(e.g. the results around 200-300 msec on the New York-West
Coast graph).

In general, the 95th percentile of the call setup delay
is greatly influenced by the prevailing error rate. We also
do show that increasing the number of hops in the call
setup path can greatly increase the 95th delay percentile
(e.g. figures 9 and 10 from the paper). 

Hope this helps.

Regards,

Tony

---

From: Giuseppe Ricagni <[email-masked]>
Date: Thu, 18 May 2000 14:49:14 +0200

Jonathan Rosenberg wrote:

> want to record-route.I don't want to prevent them from doing so.

Basically, the only problem here is that the callee is roaming.

As Henning reminded us, this requires a database (let' s call it Home Subscriber Server: HSS, a
kind of GSM HLR) lookup by the "calling proxy" in the callee home domain, to have information
about the address of the proxy the callee is registered at.

This lookup can be performed directly by the caller proxy, or via a callee home domain "home
proxy".

This  "home proxy" is the only proxy you would like to write in the record-route and I would like
not to.

IMHO, since  from a technical point of view you could query the HSS directly from the calling
proxy, you are to involving the "home proxy" only for "political reasons", to some extent to
"filter" queries to the HSS.

There is therefore no point in having  such proxy in the record-route.

Also remember we are talking here about basic calls, requesting no additional services, or
services that   are user profile independent. More complex scenarios can be achieved, as I
suggested in a previous posting:

there are four kind of value added services:

     a) those who require user profile information
     b) those who don' t  require user profile information, but to some extent they are not
     supported by the visited domain
     c) those who don' t  require user profile information and they are implemented by the
     visited domain.
     d) null services: in other words, basic calls that do not request any kind of value added
     service

Case a) and b) require some kind of interaction with the home network.

C) and d) don' t.

[....]

type a) services. need to execute it in the home network, unless you download
the user profile at registration time AND the visited network has implemented that specific
service.

With respect to the method used to classify service request within the four cathegories, a
possibility is that  the home domain, at registration time, sends information to the visited
domain
on the requirements to meet  to locally execute a given set of services for that specific user. If

the visited domain supports such requirements ==> those services can be executed locally.

This mechanism can even  be extended to the full download of the user profile.

> the path which record-route, seems like you are optimizing for the wrong

First of all: we are not "optimizing" a system, here: we are adding a feature, that can be useful
to "optimize" a given set of cases.

Let's make a simpler  (and very common) example:
an Italian mobile roaming to Australia, that wants to call a (local !) Taxy: is this the wrong
case ? (In that case I'm wrong myself, because I did it in Adelaide!!!  :-))

It is a basic call, no supplementary services required, it can definetly handled locally. The
calle is a PSTN number, therefore no HSS lookup is neded (well, even if the calee was an
australian mobile phone, it would have been a local -Australian- lookup of the Australian HSS).
Why should I send my Invite to Italy ?!?!?

> new address once its known.

well, something like that. (the Invite is sent FROM the mobile host -the one changing address-
towards its correspondent)

> This need not be the case. In a scenario

Sorry, but I think you missed the target.

The problem is only related to the in-flight packets.
If I' m in the position of keeping the two address active for a while, I will get the in-flight
packets on the old
address anyway !!!! I don' t need any duplicte invite !!!

The problem comes when I lose the old address and there are some already in-flight packets
addressed to it.
The number of in-flight packets is proportional to the time needed to make  the other endpoint
aware of the new address.
No duplicate Invites or whatever can help.

Giuseppe

---

From: Romeo Zwart <[email-masked]>
Date: Thu, 18 May 2000 15:11:29 +0200

Henning, Tony,

Thanks for your explanations on the graphs. I admit having only
seen the presentation, not the paper. The proceedings are rather
difficult to obtain from the fokus website - I've restarted several
download attempts today, without much success. Could you
forward me a copy of the paper directly?

At 10:05 PM 18-05-00 +1000, [email-masked] wrote:
[... stuff deleted ...]
>(e.g. the results around 200-300 msec on the New York-West

OK, so the 500 ms timeout explains the 'quatum leap' effect
seen in the graphs - instead of a smooth distribution of setup
times. Which may suggest that packet loss contributes
significantly, even more than (queuing and propagation)
delay itself.

>(e.g. figures 9 and 10 from the paper).

If there is a correlation with the number of (router)hops, this
also suggests packet loss as a contributor, although queuing
delay can't be ignored, ofcourse.

I am very interested to have a look at your paper.

Regards,

Romeo

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 May 2000 09:26:12 -0400

I've added the paper reference to
http://www.cs.columbia.edu/~hgs/sip/papers.html and
http://www.cs.columbia.edu/~hgs/research/imm/

Thanks for your interest.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2000 09:55:52 -0700 (PDT)

> This lookup can be performed directly by the caller proxy, or via a callee home domain "home

   Sorry to be flippant, but gag me with a spoon.

   If you remote the proxy, this presupposes that:

   1) We have a standardized database transport protocol
   2) [far worse] we have a standardized database scheme

   versus:

   going directly to my home proxy for which I do not
   need to expose a database transport protocol or
   a scheme at all.

   This is a no-brainer to me: having to standardize
   a database scheme will stiffle innovation and 
   propogate the feature non-transparency brain damage
   of the current system. This is unacceptible.

   Let's take step back here though: the claimed
   reason for wanting a remote proxy is so that 
   you don't incur a transport layer dog leg clear
   back to my home proxy half way around the
   world. However, I'll claim that that problem
   can be solved far more adequately by putting
   proxies geographically closer to the roamed
   user. I doubt that it is unreasonable to assume
   that AT&T, etc, can place a home proxy for my
   service physically on Australia just like
   anybody else.
   
   The only challenge is how my mobile unit gets
   directed toward a home proxy that is
   geographically close to me (thus helping 
   round trip latencies). I'll claim that that
   is a useful problem to solve overall because
   web services, etc, have the identical problem.
   
   Maybe it's already solved for all I know. Even
   if it is not, I'd far rather work on that than
   have to come up with some grandiose, all
   encompassing database scheme. It is an
   intractable problem, and has many clear
   disadvantages for all parties.

		    Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 May 2000 14:31:20 -0400

As a point of reference, I do hope that (some) services will be portable
across providers, if not for reasons of mobility, then for the ability
to take them with you when you change providers. CPL has that aim. It
would not be hard, as I indicated earlier, to have CPL scripts "roam"
with the user, without all agreeing on the universal LDAP schema or
database interface. Whether service providers will offer this feature is
probably less a technical than a business issue. I don't think it's a
good idea to rely on this being available, but service portability is a
worthwhile goal independent of this application. If a set of providers
agrees to support CPL, say, and then say "we switch your calls faster",
why not?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Giuseppe Ricagni <[email-masked]>
Date: Thu, 18 May 2000 20:49:03 +0200

Sorry Michael,

I think we are diverging from the original issue.

   * When the callee is roaming, either you use a standardized database transport protocol or you
     delegate the callee home domain proxy to perform the query, but you have a RTT towards the callee
     home domain. Your solution of having synchronized copies of such database all over the world is
     another interesting enhancement, maybe expensive (pretty sure off-the-shelf solutions are already
     out there)

        o the point I was making was that for all subsequent mid-call messages, just like the INVITEs
          you have to send for handovers, you should shortcut and avoid the round trip to the home
          net.

   * When the caller is roaming, under certain circumstances (related to the type of value added
     services required & the set of services supported by the visited network &  the possibility to
     transfer a user profile--see my previous messages) it is possible to avoid sending signalling
     back to the caller home domain. This applies to calls towards the fixed network (which may be
     routed by TRIP) and for calls to local mobiles. For roaming mobiles you fall back to the prvious
     case: still you don' t need to send signalling to the caller home domain, but you have a RTT to
     the callee home domain.

Hope this can summarize the discussion

Giuseppe

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2000 12:29:02 -0700 (PDT)

Giuseppe Ricagni writes:
 >      home domain. 

   Which may effectively be zero.

> Your solution of having synchronized copies of such database all over the world is

   It doesn't sound much more interesting than a
   localize LDAP cache on the client proxy. There
   are other ways to do this as well. And it doesn't
   imply synchronized; all that is necessary are caches
   with TTL's.

 >           you have to send for handovers, you should shortcut and avoid the round trip to the home

   I disagree. Most traffic is between the two UA's.
   And it absolutely does not follow that proxies 
   need to have any part in handoffs. In fact, I
   do not believe that proxies have any part in
   handoffs when the UA is in the mobile unit. 

 >      transfer a user profile--see my previous messages)

   I don't know what services the roaming network
   wants to provide -- other than trying to shoehorn
   themselves into the call. Even if, there is nothing
   to prevent me from obtaining those service even if
   it's routed through my home proxy first.

	       Mike

---

From: Giuseppe Ricagni <[email-masked]>
Date: Thu, 18 May 2000 22:04:16 +0200

Sorry Michael,

I really think we are looping: can we take it off-line ?

Giuseppe

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2000 14:04:17 -0700 (PDT)

> authentication services).

   That's a pretty big exception. I think there's
   a lot more reasons, like for example there is no
   standard way of the roamed proxy to know what my
   subscriber information is. Nor should there be any
   expectation that a roamed proxy would know what to
   do with that information except for a the barest
   least common denominator.

 > callee is standing right next to him/her.

   This no different than the non-roamed case.

	   Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2000 14:31:30 -0700 (PDT)

> Consider it in an aggregation model, like a donut. The chewy outside parts of the donut are controlled by IntServ. Traffic leaps across the DiffServ donut-hole only if the heuristic process thinks…

   OK, but I still don't see what that has to do
   with proxies. That sounds like something an
   edge router would do before it admits diffserv
   traffic into the diffserv core. Proxies are even
   more clueless because they never see the actual
   traffic patterns.

		Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 May 2000 15:19:30 -0400

Giuseppe Ricagni wrote:
> As Henning reminded us, this requires a database (let' s call it Home
> Subscriber Server: HSS, a kind of GSM HLR) lookup by the "calling
> proxy" in the callee home domain, to have information about the
> address of the proxy the callee is registered at.

In SIP, we call that database DNS.

> 
> This lookup can be performed directly by the caller proxy, or via a
> callee home domain "home proxy".

No - how would we get to the proxy of the callee in the first place
without having identified this server?

> 
> This  "home proxy" is the only proxy you would like to write in the
> record-route and I would like not to.

You are missing my point. You are assuming a very specific configuration
of two proxies, without any services. In real networks, there will be
lots of proxies, many of which are providing a variety of different
services. It is the right of these proxies to record-route in order to
provide those services. I don't know what those services will be, nor do
I know how many proxies there will be. I have heard of trial SIP
networks with six proxies on establishment paths. The great thing about
SIP is that it allows these kinds of things. 

So, my point is that GIVEN that there will be other proxies on the path
for a variety of reasons, you really won't be able to force signaling to
go directly between users, or between users and a local proxy, in most
of the cases.

> 
> IMHO, since  from a technical point of view you could query the HSS
> directly from the calling proxy, you are to involving the "home proxy"
> only for "political reasons", to some extent to "filter" queries to
> the HSS.

No. The home proxy is providing services.

> There is therefore no point in having  such proxy in the record-route.

I doubt you will be able to dictate to service providers that they are
not allowed to provide services in their proxies.

> 
> Also remember we are talking here about basic calls, requesting no
> additional services, or services that   are user profile independent.
> More complex scenarios can be achieved, as I suggested in a previous
> posting:

You can't design protocol mechanisms which do not consider the variety
of cases that might exist.

> possibility is that  the home domain, at registration time, sends
> information to the visited domain

This seems dubious. It assumes some kind of simple classification of
services which is unlikely to exist, and it also assumes that there is
some kind of transfer of service logic from one domain to another. I
think we have already discussed that this is really far fetched, both
technically and politically.

> First of all: we are not "optimizing" a system, here: we are adding a
> feature, that can be useful to "optimize" a given set of cases.
> 
> an Italian mobile roaming to Australia, that wants to call a (local !)
> Taxy: is this the wrong case ? (In that case I'm wrong myself, because
> I did it in Adelaide!!!  :-))

This is a good example. I have no problem if, when a user moves
somewhere else, the user decides to select a new ASP for providing
certain services. This ASP has its own proxies and application servers,
which may or may not be physically local to the user. 

The choice is ultimately the end users. My point is that I disagree with
forcing users to obtain services through a certain proxy just because
that service provider is also providing them with their IP level
mobility services. I have no problems allowing users to choose different
service providers at will, including the one providing the IP mobility
services, if they have something compelling to offer, such as the
service you desribe above (basically, a dial plan service).

> If I' m in the position of keeping the two address active for a while,
> I will get the in-flight packets on the old

You would if usage of that extra old address was costing you money, or
it would cease to be possible to use it after some time. As I said, I am
not sure if this is how IP mobility handover is accomplished.

> 
> The problem comes when I lose the old address and there are some
> already in-flight packets addressed to it.
> The number of in-flight packets is proportional to the time needed to
> make  the other endpoint aware of the new address.

At the risk of causing even more controversy and flames, I'll note that
this problem is occuring because you are using an application layer
mobility service for a network layer mobility need. If you were using an
IP layer mobility service which allowed you to tell the network which
owned your old address that you have moved, and thus to forward packets
to your new address, you would not have this problem.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 May 2000 15:50:00 -0400

>    it's routed through my home proxy first.

There are two different cases - one where the proxy is asking to be on
the call path for an existing call, and the other, where the proxy
wishes to be the local outbound (or inbound) proxy for outgoing (or
incoming) calls. I agree totally that the former - shoehorning into an
existing call - makes little sense technically. For the latter case, I
think the roaming proxy is simply another ASP. I can see reasons why I
might want to use them for some calls, and not for others. I see no
reason to prevent a user from using those proxies, but I don't see a
reason for forcing them to use them.

-Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 19 May 2000 17:35:09 -0500

Ah. The networkstatus-aware proxy is effectively advising the SIP user of congestion in the DiffServ network. Kind of like those radio announcers that say "Highway 18 is shut down again -- please use surface streets or just stay home".

The real question is to define a mechanism that allows the health of the network to be assessed in some sort of meaningful way so that this knowledge may be made available to the UAC.

--
Dean

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Thursday, May 18, 2000 4:32 PM
> To: Dean Willis
> Cc: IETF SIP; Michael Thomas
> Subject: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force
> in Adelaide)
> 
> 
> Dean Willis writes:
>  > Consider it in an aggregation model, like a donut. The chewy 
> outside parts of the donut are controlled by IntServ. Traffic 
> leaps across the DiffServ donut-hole only if the heuristic 
> process thinks (IE, is reasonably sure) that there is adequate bandwidth.
>

---

From: "Dave Oran" <[email-masked]>
Date: Wed, 24 May 2000 12:28:12 -0400

If you're using Intserv at the edge the router at the edge of the Diffserv
cloud will likely know this and reject the reservation. No need for the
proxy to get involved.

The car analogy is not a good one because in the case of highways you're
already stuck at the bottleneck when you find out you're screwed, as opposed
to RSVP when you are essentailly clearing all the dead wrecks out of your
way before driving up the highway, ala Mad Max.

Positing that a SIP proxy has a better idea what the QoS state of the
Diffserv core is than the edge router at the edge of that core is like
saying the radio announcer knows more about the tornado than the Twister
crew chasing it.

If there's a oracle which knows the state of the core it can tell the edges
as easily or MORE easily than it can tell an undefined sea of application
proxy boxes.

Dave.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Dean Willis
> Sent: Friday, May 19, 2000 6:35 PM
> To: Michael Thomas
> Cc: IETF SIP
> Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task
> force in Adelaide)
>
>
>
> Ah. The networkstatus-aware proxy is effectively advising the SIP
> user of congestion in the DiffServ network. Kind of like those
> radio announcers that say "Highway 18 is shut down again --
> please use surface streets or just stay home".
>
> The real question is to define a mechanism that allows the health
> of the network to be assessed in some sort of meaningful way so
> that this knowledge may be made available to the UAC.
>
> --
> Dean
>
>
>
> > Hƒæj)bž	b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ©

---

From: Dean Willis <[email-masked]>
Date: Wed, 24 May 2000 15:53:02 -0400

> cloud will likely know this and reject the reservation. No need for the

In general, I'm not. The WorldCom net, for example, is TOS-priority from
end to end.

> saying the radio announcer knows more about the tornado than the Twister

A SIP proxy is in a better position to have a persistent relationship
with a network management system which can feed it information about the
state of the network than a dynamically romin SIP UA is. So, even though
the announceer may not know as much about the tornado as the chaser
does, he is in a MUCH better position to share that information with the
listening audience.
 
> as easily or MORE easily than it can tell an undefined sea of application

Sure, the edges probably know truckloads of cool stuff.

But I have no mechanism for the edges to relay this knowledge to the
UAs.

--
Dean

---

From: "Dave Oran" <[email-masked]>
Date: Wed, 24 May 2000 16:08:41 -0400

Ah. I understand. no RSVP == no explicit admission control.
That's the bug. Hijacking SIP proxies to do the job of a bandwidth
allocation and admission control signaling protocol is ugly at best. You'd
need one of these beasts for every application in the universe - rtsp,
quake, you name it.

If you build SIP proxies the way some people build web server farms you'll
have an entirely different scaling problem, which is 100's of SIP proxies
polling a poor overworked network managmeent system trying to figure out
what it knows about the state of the core (or better stated, what it knew
about the core 5 minutes ago when it last gathered enough measurements to
make a guess).

Register me as a skeptic.

Dave.

> From: Dean Willis [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2000 3:53 PM
> To: Dave Oran
> Cc: Dean Willis; Michael Thomas; IETF SIP
> Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task
> force in Adelaide)
>
>
>
>
> Dave Oran wrote:
> >

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 25 May 2000 00:13:28 +0200

Dave,

In the DiffServ case, I see these policies to control the edge:

0) no control; the edge trusts end-devices absolutely; end-devices
   will get what they want
	-> not very secure
1) self-control; the edge manages itself; it uses some heuristics to say
   which packet deserves which class
	-> heuristics may fail
2) the edge is polled/controlled explicitly by
   a) end-devices 
	->they have some built-in control support, e.g. RSVP mapped to 
          DiffServe at the edge
   b) proxies on behalf of the end-devices
	->works w/o changes to end-devices
	->application-awareness may be added on top of the
	  admission control, e.g. a SIP/RTSP/quake proxy will be
          able to decide that all video streams from
	  head of department will be assigned high
	  priority

The question: Is 2b an invalid policy? Is it a 
useful policy? And what is actually the difference in terms 
of scalability between 
i) end-devices trying to control/poll the edge [2a]
ii) farm of SIP proxies doing the same on behalf of them 
    (possibly using some kind of aggregation) [2b]?
The scalability bottleneck is the edge in both cases,
isn't it?

Thanks,

Jiri

-- 
Jiri Kuthan               Phone: +49-30-3463 7271
GMD FOKUS                 Fax  : +49-30-3463 8271
Kaiserin-Augusta-Allee 31 E-Mail : [email-masked]
D-10589 Berlin, Germany   WWW    : http://www.fokus.gmd.de/usr/kuthan
--
Curious about Internet Telephony? 
Check http://www.fokus.gmd.de/glone/projects/ipt today!

---

From: "Dave Oran" <[email-masked]>
Date: Thu, 25 May 2000 12:33:32 -0400

> [mailto:[email-masked]]On Behalf Of Jiri Kuthan
> Sent: Wednesday, May 24, 2000 6:13 PM
> To: Dave Oran
It also provides no traffic isloation, so one badly behaving host can
degrade or deny service for a whole class. Call this a security problem if
you want, but I don't. Diffserv by itself doesn't do "admission control",
only aggregate policing.

>    which packet deserves which class
If you believe Diffserv BY ITSELF is adequate, then by definition the
heuristics don't fail. They only determine who wins and loses when the
policing starts remarking or tossing packets.

> 	->they have some built-in control support, e.g. RSVP mapped to
Yes.

> 	->works w/o changes to end-devices
Define "works". I'm skeptical. This requires that the proxy knows enough
about the topology to know where the end-device hits the edge, and knows
enough about the current SLAs and policing parameters at that edge device to
know if allowing the call will exceed the SLA and trigger aggregate
policing.

> 	  head of department will be assigned high
This is a completely independent issue. RSVP and COPS now have
priority/preemption objects which allow admission control to take this kind
of policy into account.

> The question: Is 2b an invalid policy?
I'm a registered skeptic. I don't think it has well defined properties such
that you can explain either to a customer or an end user why the system
behaves in a certain way. If you buy the notion that you don't need
resource-availability-based admission control and traffic isolation to
confine the effects of oversubscription, then I suppose 2b is workable. I
wouldn't buy it. Someone else might.

> Is it a
Not really. The edge is in fact the only place where I think the scalability
problem is tractable, because that's the point where the policing is done.