Subject: RE: [midcom] pre-midcom candidates

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2001 04:13:39 -0500

> -----Original Message-----
> From: James Ho [mailto:[email-masked]]
> Sent: Thursday, November 15, 2001 2:08 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [midcom] pre-midcom candidates
> 
> 
> Two issues pertaining to the pre-midcom work that I still don't
> have clarity around.
> 
> 1. What are the specific latency/peformance issues associated with
> tunnelling/VPN appraoches? While admitedly there is another device
> in the picture, as I mentioned before, there are available/evolving
> hw solutions for integrate wire-speed IPsec processing
> enabling tunnel de/encapsulation at wire-speeds, so theoretically
> this should not be an issue.

It has nothing to do with processing speed at the intermediary. The problem
is the painfully slow speed of light. Consider two users, A and B, who sign
up for service with a provider foo.com. Foo has a data center in California.
Foo has no idea where its customers physically reside when they make calls.
In fact, foo may not even know the mailing address for its customers. Now,
it so happens that A and B are in New York. A makes a VoIP call to B. The
media for these calls is routed from A, over some kind of VPN solution to
the foo.com data center in CA where the VPN server sits. The media then goes
right back into another tunnel, to B, in New York. The media, as a result,
has done a round trip through the US, just to go across the street. That
adds substantial latency, increases loss probabilities, and costs a lot for
the provider. Since media comes in and goes back out, for whatever the
number of erlangs the provider is trying to handle, they need TWICE that in
access bandwidth in their data center. If the media never goes through this
VPN server, they need only the bandwidth to support signaling. 

The cost differences between these are astounding. Lets say the provider
wants to handle a modest 4 calls a second. With signaling alone, assuming
maybe 2kB worth of SIP messages per call, thats 64 kbps. No problem. With
media, lets assume a 3 minute call hold time. At 4 calls per second, thats
720 erlangs. Lets assume G.711 plus RTP overheads, which is 80kbps. You need
to support that much in each direction, but each direction goes in and out
of the provider network. Thats 115 Mbps in each direction! Thats 1800 TIMES
as much bandwidth needed. I don't know about you, but my customers are not
itching to pay for the access bandwidth for that, the switches, the
operating expenses, and so on, which very much add up.

Another way to think about it is this; the IP network is designed to figure
out the shortest route between A and B. By using VPN solutions, you are
inserting additional hops that can result in seriously non-optimal routing.

> 
> 2. what is the benefit of developing new/additional approaches
> for secure tunneling when there are existing standards in place
> for this (e.g. IPsec)? From Jonathan's e-mail, it would seem that
> the answer to this is 'no'. Is there a concensus around this
> (I understand there is a philosophical debate underway on this but my
> interest is in the technical issues)?
> 

There are at least a few reasons why one might want a new solution for this
kind of tunneling (since it is, alas, needed for symmetric cases). I outline
these in the TURN draft, but here they are repeated:

o RSIP and the VPN solutions all allocate an entire IP address
          to the client. This means the provider must have sufficient IP
          addresses for all the clients which would simultaneously need
          service. This could require significant address space. With
          this proposal, its an IP address/port thats allocated, which
          means very few IP addresses are needed. This is the standard
          NAT argument.

        o RSIP and VPN solutions all require tunneling. In this
          proposal, there is no tunneling. The result is more efficient
          bandwidth usage, which is important for media packets (RTP is
          a likely user of this mechanism).

        o RSIP and VPN solutions might contradict enterprise firewall
          policy, allowing people to run servers, to use UDP when only
          TCP is allowed, and so on. Some would consider this a feature,
          not a drawback. But, if the goal is consistency with IT
          established policies, it is a drawback. Our proposal provides
          a simple, minimalistic functionality that is consistent with
          enterprise policy. The only feature TURN adds, is the ability
          of a user behind the firewall/NAT to receive a single incoming
          connection, which it has previously requested.

I am still on the fence, but here is at least a start on some reasons to do
it.

Thanks,
Jonathan R.

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

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: "Saqib Jang" <[email-masked]>
Date: Sat, 17 Nov 2001 16:57:38 -0800

> inserting additional hops that can result in seriously non-optimal
routing.

The above discussion assumes a completely centralized model of
service delivery which will not always be the desireable case. The typical
model of delivery  of business-grade IP services is to distribute
intelligence
to the network edge (for QoS, per-subscriber management, etc)  versus one
centralized instance of the service delivery platform. Meaning that
VPN end points could be distributed to PoPs across the network in which
case the latency issues described above would not be relevant. For example,
tthe model distributed model is being followed by all/most SPs undertaking
deployment of managed VPN services.

Saqib

>           connection, which it has previously requested.

As I mentioned in an earlier e-mail, standards-based VPN solutions
are (in addition to firewalls) an important component of an enterprises
security policy and could be used to allow secure firewall traversal of
specific protocols to specific external endpoints. Enabling an enterprise
to make such a choice through deploying a VPN set-up (in addition to
a firewall) if it deems it acceptacle in view of its security
policy is viewed positively.

I see generalizations such as the above to be questioning the rationale
for standards such as tunnel-mode IPsec which I don't this working group
wants to get into.

Saqib

----- Original Message -----
From: Jonathan Rosenberg <[email-masked]>
To: 'James Ho' <[email-masked]>; Jonathan Rosenberg
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, November 17, 2001 1:13 AM
Subject: RE: [midcom] pre-midcom candidates