[EME] RE: finally!: draft-irtf-eme-francis-nutss-design-00.txt

Teemu Koponen <koponen@icsi.berkeley.edu> Wed, 09 May 2007 23:58 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 1Hlw3S-0000KY-NF; Wed, 09 May 2007 19:58:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlw3R-0000KS-Ob for eme@irtf.org; Wed, 09 May 2007 19:58:45 -0400
Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlw3O-0003Ht-Pc for eme@irtf.org; Wed, 09 May 2007 19:58:45 -0400
Received: by an-out-0708.google.com with SMTP id b6so117333ana for <eme@irtf.org>; Wed, 09 May 2007 16:58:42 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:in-reply-to:references:content-type:message-id:from:subject:date:to:x-mailer:sender; b=ZwhY24/hNL32MFwwYryEmk9r25Kj2dkdtgcliQv9mlsotNohHycyGL0Kt1HIpzFS7VLUf3/7Cilx4vAVFLYL0XR3iC8HiP5trQiC7WbxYUnz2Pqx8Ghb1M+YM2asSRPoh7YCX+1LsnLk23w4aScDpn8qL5/BxxagVACV+3SNXOs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:in-reply-to:references:content-type:message-id:from:subject:date:to:x-mailer:sender; b=tHfwt6XcyRMOC7E6vN1Jvx5wldoQBXP/xZBMDzab3IG9RHRkQcsi5TjGdq+REJ4M4BsUFhXZ1ZuwV2c2IrwCaec3LJr8bnM6mD4UTaNTr1F6kBZBAoHq/TgXFO0KW2hXbGd/qUhQJjuwvqsy+eIeu3K69BqAyMnDXjDITU9HKZE=
Received: by 10.100.128.8 with SMTP id a8mr804212and.1178755122004; Wed, 09 May 2007 16:58:42 -0700 (PDT)
Received: from ?192.150.186.189? ( [192.150.186.189]) by mx.google.com with ESMTP id b14sm19629181ana.2007.05.09.16.58.23; Wed, 09 May 2007 16:58:33 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <E6F7A586E0A3F94D921755964F6BE006BAD1D5@EXCHANGE2.cs.cornell.edu>
References: <E6F7A586E0A3F94D921755964F6BE006BAD1D5@EXCHANGE2.cs.cornell.edu>
Content-Type: multipart/mixed; boundary=Apple-Mail-10-731922129
Message-Id: <65542F99-1F6F-499A-95FE-46FDA486B39C@icsi.berkeley.edu>
From: Teemu Koponen <koponen@icsi.berkeley.edu>
Date: Wed, 9 May 2007 16:58:20 -0700
To: eme <eme@irtf.org>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82ac797c7bd86bc512d4df63baba1592
Subject: [EME] RE: finally!: draft-irtf-eme-francis-nutss-design-00.txt
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

On Apr 24, 2007, at 11:10, Paul Francis wrote:

Folks,

> The main feature of the NUTSS is the "dual signaling" approach,  
> where both
> path-coupled and path-decoupled signaling are tightly coordinated  
> in order to
> overcome the limitations of either mode alone.  Some form of dual- 
> signaling
> seems necessary to me, but there might be many ways to manage it.   
> This draft
> suggests one way...others might have better ideas.

Here's another idea, this time a clean-slate one. While reading the  
draft, please

1) forget the data-orientation and concentrate to the policy aspects  
(in other words, we can name services/apps/hosts instead of data, if  
that's what apps desire),
2) replace an RH with P-box in your mind, and
3) do not let the different naming to distract you too much.

It strikes me that the similarities are very obvious:

(a) both do name based routing. NUTSS uses DNS, we do it with flat  
identifiers.
(b) both have two kinds of paths between end-points. NUTSS talks  
about off-path vs. on-path, we talk about slow-path and fast-path. In  
both, the policies are mostly applied on the off/slow-path, i.e., it  
is designed for *functionality*, not for speed like the off/fast-path  
is.

It seems that these two ideas are the in the deep core of both  
proposals. DONA is probably cleaner/simpler due to its clean- 
slateness, while NUTSS favors incremental deployability instead, and  
does that for a very good reason, of course.

Teemu

--

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