Subject: Application protocol for distributed storage

From: Wesley Leggette <[email-masked]>
Date: Thu, 14 Jan 2010 16:57:16 -0600

Hello,

My company is interested in submitting an I-D for our network distributed
storage protocol. At this point, we're thinking of dividing our efforts into
multiple parts:

* An on-the-wire application protocol from client to storage servers.
* A security protocol.
* A data processing method and storage format for client data stored on
storage servers.

I'm not entirely clear which working group(s) I should attempt to work with.
Any pointers would be helpful.

Our application and products as a whole get into the "cloud storage" area,
but we would like to focus on a smaller subset (just the network protocol)
to begin with. However, if there are any working groups within IETF that
focus on remote or distributed storage that would be interesting to know as
well.

Thanks,

Wesley Leggette
Cleversafe, Inc.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Jan 2010 23:05:12 +0000

>Hello,
Hi Wesley,

>focus on remote or distributed storage that would be interesting to know as
This looks similar to the DECADE BOF that IETF had in Hiroshima. I am 
hoping this would become a WG soon.
(I've CCed the BOF co-chairs).

Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/IESGmems.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

---

From: Wesley Leggette <[email-masked]>
Date: Thu, 14 Jan 2010 22:02:34 -0600

The DECADE work is interesting, but it is not specifically what we are
working on. Our system, I'm sure, uses some of the same principals, but we
are focusing on hosted systems. Sort of a "hosted P2P" if you will.

So while our system [1] will address dynamic peer environments, it is not
our main concern because our storage nodes are assumed to be available in
the usual case. Instead, we are interested in using IDAs[2] to enhance
availability, reliability, and security.

[1] http://www.cleversafe.com/

However, DECADE does seem very interesting. There are some people in my
company that may be interested in participating in that if it gets going.

Wesley Leggette
Cleversafe, Inc.

On 1/14/10 21:41, "Song Haibin" <[email-masked]> wrote:

> Hi Wesley,
> 
> I'm very glad to get this email from Alexey. The link below is about the BOF
> information at IETF 76 meeting.
> http://trac.tools.ietf.org/bof/trac/wiki/decade
> 
> And we have been trying to narrow down the protocol scope to resource
> control and negotiation of transport protocol as we have discussed in the
> mailing list. You could read about the latest thread here:
> http://www.ietf.org/mail-archive/web/decade/current/threads.html#00106.
> 
> Please let me know if it is the work that you are interested.
> 
> Xie Xie,
> Haibin
> 
> 
>> -----Original Message-----
>> From: Alexey Melnikov [mailto:[email-masked]]
>> Sent: Friday, January 15, 2010 7:05 AM
>> To: Wesley Leggette
>> Cc: [email-masked]; 'Woundy, Richard'; Song Haibin
>> Subject: Re: Application protocol for distributed storage
>> 
>> Wesley Leggette wrote:
>> 
>>> Hello,
>>> 
>>> 
>> Hi Wesley,
>> 
>>> My company is interested in submitting an I-D for our network
>>> distributed storage protocol. At this point, we're thinking
>> of dividing
>>> our efforts into multiple parts:
>>> 
>>> Our application and products as a whole get into the "cloud storage"
>>> area, but we would like to focus on a smaller subset (just
>> the network
>>> protocol) to begin with. However, if there are any working groups
>>> within IETF that focus on remote or distributed storage that
>> would be
>>> interesting to know as well.
>>> 
>>> 
>> This looks similar to the DECADE BOF that IETF had in
>> Hiroshima. I am hoping this would become a WG soon.

---

From: Aaron Stone <[email-masked]>
Date: Fri, 15 Jan 2010 05:54:44 -0800

> focus on remote or distributed storage that would be interesting to know as

Take a look at the memcached binary protocol:
http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol

It's binary, so not typical of IETF protocols, but it's got good
extensibility and excellent client/server interop in many existing
deployments, including a number of truly enormous deployments.

There are some flags and reserved bits already present to indicate the
type of data being stored. There are no implementations yet of any
server-side data processing methods, but the bytes are there for this
direction of growth.

What it doesn't have is much in the way of security. There's precious
little interest in this because memcached itself, as a cache, is
decidedly not secured in the interest of being really really fast.
That's not to say that it isn't possible to build a security
mechanism, but it has to be absolutely optional to gain any traction
with the memcached community.

Cheers,
Aaron

---

From: Song Haibin <[email-masked]>
Date: Fri, 15 Jan 2010 11:41:57 +0800

Hi Wesley,

Xie Xie,
Haibin

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 15 Jan 2010 17:20:07 -0500

Wesley,

>Instead, we are interested in using IDAs[2]

You didn't supply a reference for IDAs, but I suspect this is what you
meant: <http://www.cleversafe.org/dispersed-storage/idas>. It seems that
you are storing slices of data across distributed storage locations, (1)
to maximize storage efficiency and (2) to minimize data exposure if one
or more storage servers are compromised. If so, I agree you do seem to
be trying to solve a slightly different problem than Decade's.

At the same time, there is some potential areas of commonality,
particular in the case of data control and transport protocols.

>From <http://www.cleversafe.com/vision/object-storage>: "If your
application is housing your metadata, and only object storage is
required, the Simple Object interface can be accessed with either a Java
SDK, or HTTP/REST API. Simple PUT, GET, DELETE commands allow your
applications to access digital content, and the resulting object ID is
stored directly within the application."

From
<http://www.cleversafe.com/vision/Dispersed_Data_Archiving_Top-10-Featur
es>: "dsNet systems can be accessed in numerous ways.  Today we offer
iSCSI and a straight block interface, soon to come releases support FTP,
NFS, CIFS (SMB) and webDAV, making your data universally accessible to
any application you might conceive for it.  Our authentication systems
are also pluggable through PAM (Pluggable Authentication Modules)."

Since your company already sells a product, I am curious about which
interoperability problems you are trying to solve (or avoid) by posting
your internet-drafts. Are you enabling any third-party client to
leverage your cloud storage? Could other cloud storage vendors leverage
the same network protocols?

Are there any patents that the IETF should be aware of, e.g.
<http://www.google.com/patents?q=cleversafe>?

-- Rich

-----Original Message-----
From: Wesley Leggette [mailto:[email-masked]] 
Sent: Thursday, January 14, 2010 11:03 PM
To: Song Haibin; Alexey Melnikov
Cc: IETF Apps Discuss; Woundy, Richard
Subject: Re: Application protocol for distributed storage

The DECADE work is interesting, but it is not specifically what we are
working on. Our system, I'm sure, uses some of the same principals, but
we
are focusing on hosted systems. Sort of a "hosted P2P" if you will.

So while our system [1] will address dynamic peer environments, it is
not
our main concern because our storage nodes are assumed to be available
in
the usual case. Instead, we are interested in using IDAs[2] to enhance
availability, reliability, and security.

However, DECADE does seem very interesting. There are some people in my
company that may be interested in participating in that if it gets
going.

Wesley Leggette
Cleversafe, Inc.

---

From: Wesley Leggette <[email-masked]>
Date: Fri, 15 Jan 2010 17:28:46 -0600

> the same network protocols?

Yes, our ultimate goal is to allow any third-party client to leverage our
storage product. As the cloud storage market is fairly new and very
fragmented, we feel it would be beneficial to at least get something out
there for discussion.

While we wouldn't be so bold as to assume everybody will just implement our
protocol, we feel it has many advantages and want to make it possible for
others to leverage it.

Further, we are not completely opposed to making changes to our protocol and
products, but what I'm getting from these exchanges is that the first step
is to publish what we have and then to see what interest there is from that.

> <http://www.google.com/patents?q=cleversafe>?

There are several patents that we will have to disclose. I am vaguely
familiar with the IETF IPR rules, but I will have to fully familiarize
myself with them before saying more.

Wesley Leggette
Cleversafe, Inc.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Jan 2010 17:44:23 -0600

> deployments, including a number of truly enormous deployments.

Whoa.  I can think of a large number of "binary" Internet protocols, at
every layer in the stack (not including layers 8 and 9 :) that the IETF
has protocols for.  E.g.,

 - SSHv2, TLS, NFS, iSCSI, ...
 - DNS, LDAP, ...
 - Kerberos, PKIX, ...
 - TCP, UDP, SCTP
 - IP itself (v4 and v6)

Many encoding schemes are used, from custom schemes (e.g., in SSHv2),
bits-on-the-wire (e.g., IP), line-oriented text with escapes (e.g.,
HTTP), XDR (NFS), various ASN.1 encoding rules (mostly BER and CER),
XML, etcetera.

Yes, we also have net-ascii-type protocols (HTTP, FTP, IMAP, ...).  I
suspect those are actually in the minority, though some are so widely
used and so notable that one might think that net-ascii is the rule --
it just isn't.

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Sat, 16 Jan 2010 09:31:20 -0500

--On Friday, January 15, 2010 17:28 -0600 Wesley Leggette
<[email-masked]> wrote:

>...
> Yes, our ultimate goal is to allow any third-party client to
> leverage our storage product. As the cloud storage market is
> fairly new and very fragmented, we feel it would be beneficial
> to at least get something out there for discussion.
> 
> While we wouldn't be so bold as to assume everybody will just
> implement our protocol, we feel it has many advantages and
> want to make it possible for others to leverage it.
> 
> Further, we are not completely opposed to making changes to
> our protocol and products, but what I'm getting from these
> exchanges is that the first step is to publish what we have
> and then to see what interest there is from that.
>  
> There are several patents that we will have to disclose. I am
> vaguely familiar with the IETF IPR rules, but I will have to
> fully familiarize myself with them before saying more.

Wesley,

Speaking only for myself, but with the perspective of some years
in the IETF community...

Yes, you should put your ideas into an Internet Draft and get it
posted.   We are all better off talking about a description of
something, ideally a description that would be good enough to
build interoperable implementations from, than with a
description of a description and the need to do detective work
on your web site, even though Richard has done an impressive (to
me) job of that.

But --and, again, this is just personal opinion-- I think you
will not get very far in convincing the IETF to evaluate,
publish, or adopt you work unless at least one, and preferably
both, of the following conditions are met:

	(i) Your document shows a clear awareness of the
	alternatives that are already out there and critically
	describes the relative strengths and weaknesses of your
	approach for the applications you think relevant.
	
	(ii) At least implementation of a client, and ideally
	implementation of alternate servers, should not require
	any sort of complex and/or expensive licensing.  When
	established and deployed alternatives exist, the IETF is
	only very rarely willing to invest energy in a new
	protocol whose main value seems to be to improve one
	company's profitability and, correctly or not, IPR
	encumbrances and licensing requirements are often
	interpreted that way. 

regards, 
   john

---

From: Eric Burger <[email-masked]>
Date: Sun, 17 Jan 2010 11:59:34 -0500

To jck's point, see, e.g., <https://datatracker.ietf.org/ipr/580/>.   
If the purpose of your IPR is to protect people who implement the IPR,  
royalty free, life is going to be good.  There are bad people out  
there that might try to assert IPR against an open standard. A filing  
like MSCML protects 3rd-parties from such assertions.  In this case,  
you will be seen as a good guy.

However, if the purpose of your IPR is to get royalties or to block  
competitive services that fully implement the IETF (hopefully your  
stuff gets that far), then the community will probably not even start  
work or, worse yet, will start work and then excoriate you as well as  
CleverSafe.  You would get put into the Very Bad Guy doghouse.

P.S., say hi to Chris G. for me.
--
- Eric

On Jan 16, 2010, at 9:31 AM, John C Klensin wrote:

> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss