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

From: Teemu Koponen <[email-masked]>
Date: Mon, 7 May 2007 22:35:28 -0700

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

Paul,

> After weeks of quiet, we have finally generated a draft design/ 
> architecture
> (called NUTSS) for the EME research group.  Its posted at:
>
> http://www.ietf.org/internet-drafts/draft-irtf-eme-francis-nutss- 
> design-00.txt

Could someone of the authors give hints how to decipher the notation  
used in the examples?

TIA,
Teemu

--

_______________________________________________
EME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/eme

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 8 May 2007 14:05:06 -0400

Sure.  I know my notation is a bit incomplete here...I was trying to find a
balance between readability and specificity.  In general, I was hoping that
the comments following each message exchange would clarify the notation.

By way of explanation, here's a snippet from the draft:

A.1  H1->M1 (name routed):
   H1-dev[Name(H1name, appName),
          Stack(IP-TCP, IPaddr, TCPport)
   ]
   H2-dev[Name(H2name, appName)
   ]
   H1-Data[TCP SYN, App data
   ]

   A.2.  M1:  DNS lookup on H2name, returns M2 IP address.

   A.3.  M1->M2 (name routed):
   H1-dev[...same as before...]  H2-dev[...]  H1-Data[...]
   M1-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport),
          Token("flow enabled at m-box")
   ]

H1->M1 means that it is going from H1 to M1 (most of the examples have a flow
diagram at the end that summarizes the flow)

(name routed) means that it was routed using the name

H1-dev means that this component of the message is a device describing host
H1.  (Recall that there are two types of message components, "device" and
"data", see section 3)

within the H1-dev component, there is a name and a stack.  

The name contains the name of H1 ("H1name") and the name of the app
("appName")

The stack contains the protocols used ("IP-TCP"), the address of the IP
protocol for H1 ("IPaddr") and the TCP port ("TCPport").  e.g. 20.1.2.3 and
45221.

The data component H1-Data says that the data normally in a TCP SYN packet
and the first application packet are included.

In the message labeled A.3., a component such as H2-dev[...] means that the
component already given in an earlier message is simply repeated (carried
along).  In general, components are not deleted as the message makes it way
back and forth, they are only added.

In the token component, "flow enabled at m-box" means that the m-box has
approved the flow, and will allow packets to pass once all the needed
parameter information is conveyed (i.e. the address on the remote end).
Normally, when a p-box approves a flow, we'll write "approved" instead of
"enabled" (as in "flow approved for <H1,H2,app> tuple").

Let me know if you have more questions.

PF

> -----Original Message-----
> From: Teemu Koponen [mailto:[email-masked]] 
> Sent: Tuesday, May 08, 2007 1:35 AM
> To: Paul Francis
> Cc: eme
> Subject: Re: [EME] finally!: 
> draft-irtf-eme-francis-nutss-design-00.txt
> 
> > architecture (called NUTSS) for the EME research group.  Its posted 
> > at:
> >
> >
http://www.ietf.org/internet-drafts/draft-irtf-eme-francis-nutss-design-00.tx
t
> 
> Could someone of the authors give hints how to decipher the 
> notation used in the examples?
> 
> TIA,
> Teemu
> 
> --
> 
>

---

From: Teemu Koponen <[email-masked]>
Date: Wed, 9 May 2007 16:58:20 -0700

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