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

From: James Kempf <[email-masked]>
Date: Tue, 16 May 2000 15:25:02 -0700

>James Kempf writes:
> > I don't think the analogy between SIP and HTTP is valid. I see it more
> > as being between SIP and routing. Suppose I would have to go all the
> > way back to my home network to get my packets routed. 
>
>   This is a pretty dubious analogy. We're talking
>   about proxy-routed signaling traffic and that
>   alone. You're making it sound like the media
>   would do dog-leg routing through the home
>   network which is absurd.
>

No, that's not what I meant. Thhe point I was trying to make is that 
I don't think people will be very happy if it takes them
substantially longer to make a telephone connection remotely than it
does at home. It can take somewhat longer (as it does today in the
circuit switched world) but not *substantially* longer. I don't have
the numbers for intercontinental routing delays in my head but I can
believe they must be more than routing delays to a local ISP. Whether
those delays will, in fact, be substantial enough to merit having
local proxies is a matter that can be solved by engineering analysis
(and not political posturing, as this thread seems to have degenerated into).

> > Even if you are willing to grant the analogy, HTTP requests nowadays often
> > don't get routed to the server that somebody set up as their web site.
> > If your ISP is concerned about service, they may have set up an Inktomi
> > cache, and if the publisher is concerned, they may have contracted with
> > Akami to do the same. So the world is not so simple as "let's make it
> > free and easy for anybody to set up service" on the Web anymore. 
>
>   You're assuming that every thing is going to
>   be a gigantic commercial service. I disagree. 
>   It's still perfectly possible for me to run a
>   web server at home, and in fact I do. We
>   haven't engineered walls around that
>   possibility. Requiring that I use a foreign
>   proxy does, or at least thinks it does.
>

Your web server at home is leveraging off the fact that a company,
probably AT&T back when they had a monopoly, strung a wire to your
house and installed switching equipment at the local office. They made the infrastructue
investment years ago that now allows you and your ISP to offer service
really cheaply. You may be limited as to the bandwidth you get, due
to the fact that your current local telephone provider is not willing
to make the infrastructure investment to upgrade to fiber.

The UK government just auctioned off UMTS licenses for something like $25B
(as in 1 with 9 zeros behind it). Anyone who is not able to come up
with that kind of cash will have a hard time offering wireless 
telephony service. It will take years to amortize that kind of investment.
Of course, there is always the unlicensed spectrum and I'm sure there
will be players like Metricom who figure out creative ways to utilize it.

>   Also: you're talking about transparent caching,
>   not proxying in the web case. I've not heard
>   of any ISP that *require* that I go through 
>   their HTTP proxies.
>
> > You can
> > set up your service, but unless you have a concerned ISP or the money
> > to pay Akami, the latency in using your service may cause people to
> > go elsewhere.
>
>   This analogy is fatally flawed. Cache's are 
>   great for the mountains of .gif's. There aren't
>   similar considerations for SIP. Also: even
>   if you're talking about co-lo servers
>   distributed geographically, the site owner
>   still "owns" the site. What you're talking
>   about here is something run by their
>   *competition* on your subscriber's behalf.
>
>   Yuck.
> 

Cellular companies already have romaing agreements. There's nothing new about
it. 

With regard to caches v.s. proxies, the only point I was trying to make was
that customers want fast service. Whether that service is web page access
or connecting for a telephone call. It therefore makes sense to engineer
such that the service provider can provide that service, whether it requires
transparent caches or local proxies.

> > I know this isn't going to be a popular viewpoint, but I think we need
> > to be realistic about the design. SIP already contains support for
> > telling an incoming caller that a client has moved, I can't see the
> > harm in using a remote proxy, given the performance concerns.
>
>   I think we have to demonstrate that there
>   are legitimate performance concerns before we
>   solve for them.
>

Agreed.

>   Sanity check: we're talking about a
>   hypothetical case where the SIP UA is
>   in the handset, right? We're not talking
>   about the case where you're terminating SIP
>   at the next logical hop up (BTS, MSC) for
>   legacy, right? I'm talking about the former.
>   In the latter, its debatable which proxy
>   should do routing.
>

I was talking about both. The legacy situtation will be important for
some time, particularly in the North American case where the 2G and
3G spectrum allocations overlap. But I think the core network design
should be there for smooth transition to the SIP based handset.

			jak

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 May 2000 17:01:41 -0700 (PDT)

James Kempf writes:
 > circuit switched world) but not *substantially* longer. 

   Question: isn't it the case that the roamed 
   system needs to do a database dip on the
   home system to get their subscriber
   information? If so, even in the current
   situation, you have a round trip to the home
   system. This is why I'm extremely dubious that
   there is any substantial difference in call
   setup time. The same would be true in the scenario
   you propose: in order to proxy my service onto
   the roamed proxy, it would need to do some
   database dip back to my home proxy to find out
   my features. If I routed it through my home
   proxy, it looks like it would actually be
   *faster* because I'd only need to go through
   my home proxy rather than
   foreign-proxy->database-dip-at-home->routing.

 > I don't have
 > believe they must be more than routing delays to a local ISP. 

   Speed of light on fiber is about 20ms/1000miles 
   as I recall.

 > really cheaply.

   And I bow before New Jersey twice daily
   to give thanks to Bell above. 

 > will be players like Metricom who figure out creative ways to utilize it.

   Oh, please. Let's keep track of where the actual
   investment is here: it's the air resources and 
   the raw bandwidth it enables. There's an
   incremental delta for the switching equipment,
   but that's by and large the same equipment as
   landline. This doesn't seem very hard to me:
   if it's expensive to put bits in the air, then
   you charge for it. Let's not get taken down the
   path that the only viable business model for a
   bandwidth provider is to have monopoly access
   to the services I can access.

   That's the same mentality that didn't invent the
   Internet. The same Internet which dramatically
   demonstrates that there are other business
   models which can turn a tidy profit being a
   boring unintelligent network operator. If there
   are good engineering reasons, fine. But
   please lets not get sucked into bad engineering
   design driven by old world business models.

 > Cellular companies already have romaing agreements. There's nothing new about

   I know they do, and my understanding is that
   feature transparency is one thing that suffers
   big time because of their current model. 
   Keeping my features back where I get my 
   features eliminates that feature synch
   problem at its root. That is impossible in
   the circuit switched world, but almost trivial
   in the SIP world.

 > >   are legitimate performance concerns before we

   I think what might be useful rather than another
   round of impassioned polemics here is to see
   some message flows, paying particular attention
   to any hidden assumptions about what the home
   network needs to provide.

		 Mike

---

From: Stephen Terrill <[email-masked]>
Date: Wed, 17 May 2000 08:26:55 +0200

Hi James,

I think that the emphansis on saving the trombing of the user signalling is much overweighted.  Firstly, the "singlling" transport in these networks is not limited to the 64kbs singnalling channels used in the PSTN today.  Secondly, even today, it is not uncommon for two operators in the same country (ie a european country) to interconnect to each other by going through the US due to commercial reasons (ie a call from one phone to another phone just 30 meeters away can cross the atlantic twice).  What I am saying as that this happens today, and that is both user signalling and payload, and customer usually aren´t aware of it.

As such, I do tend to agree with Jonathan and Mike that the advantages of taking the call/session signalling to the "home" proxy outweigh this small and dissappearing disadvantage.

Regards,

..//steve

---

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

Stephen,

Stephen Terrill wrote:

> Hi James,
>
> I think that the emphansis on saving the trombing of the user signalling is much overweighted.  Firstly, the "singlling" transport in these networks is not limited to the 64kbs singnalling channels used in the PSTN today.

Higher bandwidth doesn' t necessarily mean lower latency..... Moreover
you don' t normally have *just one* 64Kb/s link. In this
specific case, the tight delay requirements on SS7 networks, might well
result in lower RTTs for signalling messages.

> Secondly, even today, it is not uncommon for two operators in the same country (ie a european country) to interconnect to each other by going through the US due to commercial reasons (ie a call from one phone to another phone just 30 meeters away can cross the atlantic twice).  What I am saying as that this happens today, and that is both user signalling and payload, and customer usually aren´t aware of it.
>

not saying that signalling should *always* be processed locally: as you
know this is just impossible, especially when user profile data is
required to process the call.

What we are claiming here is that local procesing should be employed as
an optimization, in all those cases where it is actually possible,
without any (pre-call) data exchange with the home domain.

> As such, I do tend to agree with Jonathan and Mike that the advantages of taking the call/session signalling to the "home" proxy outweigh this small and dissappearing disadvantage.

I do tend to disagree... Why not applying an optimization (only in those
cases where it can be applied, obviously) if it's easy, it has basically
no disadvantages, and it can be even much more helpful in other contexts
(seen my other posting ?)

Cheers
Giuseppe
P.S.
BTW: you will remember that  “Optimised call routing” is a requirement
for 3G networks (it does also refer to signalling)....

--
----------------------------------------------------------
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: Stephen Terrill <[email-masked]>
Date: Wed, 17 May 2000 16:58:07 +0200

Hi Giuseppe,

One correction, in the deployed SS7 networks today, there is only a single 64kbs pipe available to the call (the signalling for one call is not split over several signalling links).  As such, the faster transport does reduce the latency - and I don´t believe that anyone is considering running the signalling on an improperly dimensioned/configured network.

Regards,

..//steve

---

From: Giuseppe Ricagni <[email-masked]>
Date: Wed, 17 May 2000 19:33:31 +0200

Hi Stephen,

> One correction, in the deployed SS7 networks today, there is only a single 64kbs pipe available to the call (the signalling for one call is not split over several signalling links).  As such, the f…

well, I just thought that by claiming that current SS7 signalling is conveyed on 64 Kbit/s links you were suggesting   some kind of conjestion *in the nodes* (STPs).

The average ISUP message length, just to make an example, does not normally exceed 40bytes.

A 64 Kbit/s link sends a 40 bytes message in 5 milliseconds: I really don' t think this is the bottleneck.....

Should you take it to 100 Mbit/s you wouln't gain definetly more than 5 msec !!!!

OTOH, the time spent in routers may differ from that spent in STPs, retransmission mechanisms may differ, and so on.

Giuseppe