Re: [EME] Is this IMS?

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Tue, 03 July 2007 13:35 UTC

Return-path: <eme-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iX9-0001B2-Si; Tue, 03 Jul 2007 09:35:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iX8-00019v-7x for eme@irtf.org; Tue, 03 Jul 2007 09:35:10 -0400
Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5iW8-0003F9-63 for eme@irtf.org; Tue, 03 Jul 2007 09:35:10 -0400
Received: (qmail invoked by alias); 03 Jul 2007 13:34:07 -0000
Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp041) with SMTP; 03 Jul 2007 15:34:07 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19bkGsXuvNb0JJLzhNQxyS1oJsnbkir2EZl+DGouL GxHebMn7VLVN7c
Message-ID: <468A504E.7060408@gmx.net>
Date: Tue, 03 Jul 2007 15:34:06 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Scott W Brim <swb@employees.org>
Subject: Re: [EME] Is this IMS?
References: <E6F7A586E0A3F94D921755964F6BE006C9800E@EXCHANGE2.cs.cornell.edu> <4676DBC1.9060201@gmx.net> <46893AAC.8090605@employees.org>
In-Reply-To: <46893AAC.8090605@employees.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: eme@irtf.org
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Errors-To: eme-bounces@irtf.org

Hi Scott,

thank you for your response. Please find my comments and questions below:

Scott W Brim wrote:
> On 06/18/2007 15:23 PM, Hannes Tschofenig allegedly wrote:
>   
>> When I first read the document then I got the impression that all
>> this stuff already exists. I thought that you are replicating the
>> 3GPP IMS work (without referencing it). The only difference I saw
>> was that backup paths were established but I wasn't quite sure
>> whether this is a good idea anyway.
>>
>> So, what is the new idea about combining SIP (name-based routing)
>> with path-coupled signaling?
>>     
>
> To the extent I understand it, IMS is a single pass protocol.
It depends what you call "single pass".


>   There
> are several assumptions there ...
>
>   - The CSCFs (application layer control signaling intermediaries)
>     have gathered the knowledge to determine the best path for the
>     network-layer connection.  In NUTSS the two are loosely coupled,
>     but in IMS allowed paths are restricted to the few that the policy
>     boxes can keep track of.
>
>   
But there are many ways a network operator can traffic engineer their 
own network (at different layers).

>   - All policy boxes mutually trust each other.  In the draft, policy
>     boxes can be independent.
>   
Why does this assumption exist?

>   - All policy boxes understand everything you are trying to do.  It
>     is not a general-purpose signaling mechanism for all kinds of
>     traffic, rather it is very specific to the services the IMS
>     provides.
>   
Some EU funded projects have tried to extend the usage to all sorts of 
protocols, for example HTTP.
I really wonder why this is a good idea. It is a massive change but with 
little utility.

> NATs and firewalls are not considered as far as I know, except at
> domain boundaries where they might use B2BUAs. 
I don't agree with you. The work that was done on the usage of Diameter 
QoS considers both firewall and NAT traversal.
This is a MIDCOM alike approach rather than a path-coupled approach.


>  If policy signaling
> and data path are less tightly coupled, the need to tie application
> layer intelligence into a forwarder (as well as routing intelligence
> into a policy box) can be lessened.
>   

What do you mean by "less tightly coupled"?

> Finally, the signaling in the draft can be used not only by a network
> operator to control traffic over its infrastructure, but also by the
> receiving client, in order to exercise finer control over how it deals
> with incoming connection requests.
>
>   
When you use NATs on the receiving side then you essentially have very 
tight control with any protocol that allows you to interact with the NAT 
anyway.
See the NATFW NSLP, as an example.


> On 06/19/2007 03:13 AM, Hannes Tschofenig allegedly wrote:
>   
>> In IMS there is also the option to obtain authorization tokens via
>> SIP signaling that are then put into RSVP messages and signaled to
>> the middlebox.
>> In NSIS we used the same concept (even the same token format) to
>> authorize flows, as one option.
>>     
>
> First, I am told that that was in IMS R6 but it's deprecated in R7
> (now they use a "binding" mechanism instead of a "token" mechanism).
> I don't really know what that means.
>   
That's true. The main reason is that it was not simple to implement and 
RSVP never got very far (and is totally unnecessary in that particular 
environment with the assumptions that are being made for the architecture).

> Second, regarding the scheme in general ... Yes but it's just one auth
> token from a single PDF for a particular service in a particular
> environment.  Suppose I need an auth token to punch a hole in a NAT
> box, another to use a special interconnect for high bandwidth video,
> another to demonstrate to the recipient that I am in his "friends"
> list, and so on?  Different policies, different trust domains, even
> different services.
>   
There is no restrictions on the number of tokens you can obtain. It is 
just that more than one is somewhat non-practical since you can encode 
the authorization into a single token.

>   
>>> NUTSS has broader goals.  First, it wants to apply to all data
>>> flows, not just media.
>>>       
>> SIP is not only about the establishment of media traffic. You can
>> setup any type of end-to-end communication.
>>     
>
> Yes, with a little tweaking.
What type of tweaking?

>   When I first heard about NUTSS I said to
> Paul that if we used SIP we could call it "SIP as a Session Initiation
> Protocol".  :-)
>
>   
>>> It wants to be able to steer packets through middleboxes not on the
>>> path (as requested either by the ends or by the middle).
>>>       
>> You want to use something similar to source routing or QoS routing.
>>
>> While these type of things make sense for an operator to perform
>> traffic engineering it does not make that much sense for an end
>> host.
>>     
>
> Do I want my traffic to go through the USA or Kyrghyzstan? 
The middlebox does not tell you the physical location (in case you care 
for that).
It just tells you IP address X and IP address Y.


>  But I
> think the main benefit of involving the session endpoints is that you
> remove the need for linkage between p-boxes.
>   
If you want to setup tunnels or influence routing then you might just 
want to use VPNs, Mobile IP or other tunneling mechanisms where the end 
host has more control.

>   
>>>   It tries to encompass a wide range of topologies, including
>>>   multi-homed to different domains (and including dealing with the
>>>   assymetric paths that often result from this).
>>>       
>> You can accomplish this using other ways as well, such as ICE. ICE
>> would allow you to find a working path between the two end points
>> but does not require you to select the path it goes through the
>> network. From a deployment point of view that's obviously much
>> nicer.
>>     
>
> Let's reserve comparison with ICE for the meeting in Chicago.
>
>
> On 06/25/2007 08:48 AM, Hannes Tschofenig allegedly wrote:
>   
>>>   In particular, my understanding of
>>> NSIS was that it is primarily an on-path approach.
>>>       
>> Well. The concept of path-coupled and path-decoupled is somewhat a
>> philosophical question particularly when you consider that NSIS (and
>> RSVP) need to interact with other protocols.
>>     
>
> I don't understand how it's just philosophical.  Are you saying it
> doesn't matter?
>   

What you call on-path and what you call off-path is often quite 
difficult to judge.
When you want to let signaling packets to follow the data path then 
there is just the question of how close.
Please take a look at 
http://tools.ietf.org/id/draft-hancock-nsis-pds-problem-04.txt

Ciao
Hannes


_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme