Subject: [decade] I-D Action: draft-ietf-decade-arch-09.txt

From: [email-masked]
Date: Mon, 13 Aug 2012 14:03:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Decoupled Application Data Enroute Working Group of the IETF.

	Title           : DECADE Architecture
	Author(s)       : Richard Alimi
                          Akbar Rahman
                          Dirk Kutscher
                          Y. Richard Yang
	Filename        : draft-ietf-decade-arch-09.txt
	Pages           : 30
	Date            : 2012-08-13

Abstract:
   Content Distribution Applications (e.g., P2P applications) are widely
   used on the Internet and make up a large portion of the traffic in
   many networks.  One technique to improve the network efficiency of
   these applications is to introduce storage capabilities within the
   networks; this is the capability provided by a DECADE (DECoupled
   Application Data Enroute) compatible system.  This document presents
   an architecture, discusses the underlying principles, and identifies
   key functionalities in the architecture for introducing a DECADE-
   compatible in-network storage system.  In addition, some examples are
   given to illustrate these concepts.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-decade-arch

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-decade-arch-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-decade-arch-09

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 13 Aug 2012 17:06:52 -0400

FYI - We have made the Problem Statement RFC and Requirements I-D as normative references as per the suggestion from Haibin.

/Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 13, 2012 5:04 PM
To: [email-masked]
Cc: [email-masked]
Subject: [decade] I-D Action: draft-ietf-decade-arch-09.txt

Abstract:

---

From: Songhaibin <[email-masked]>
Date: Tue, 14 Aug 2012 01:10:08 +0000

That's great, thank you, Akbar. We will send this document to IESG.

-Haibin

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rahman, Akbar
> Sent: Tuesday, August 14, 2012 5:07 AM
> To: [email-masked]
> Subject: Re: [decade] I-D Action: draft-ietf-decade-arch-09.txt
> 
> FYI - We have made the Problem Statement RFC and Requirements I-D as
> normative references as per the suggestion from Haibin.
> 
> 
> /Akbar
>

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Mon, 27 Aug 2012 14:29:07 +0000

Dear Richard, Akbar, All,

I've gone through -arch-09 and I would like to commend the authors, as this version is significantly improved from -07. However, I find that there is still room for improvement and perhaps a bit more attention is needed on some of the subtle aspects. I also found a few inconsistencies between -reqs and this draft, which I list below.

Current inconsistencies between -reqs and -arch
-----------------------------------------------
With respect to discovery mechanisms, there is a slight divergence between the two documents:
  -reqs-08/Sec. 6.9: A mechanism for a Provider to discover and connect to its assigned server MUST be supported.
  -arch-09/Sec 5.5: A DECADE-compatible system SHOULD include a discovery mechanism through which clients locate an appropriate server.

Similarly, -reqs/Sec. 5.4 requires (MUST) the following locally-scoped attributes: TTL, creation timestamp, object size and type. But, -arch/Sec. 6.1.4 recommends (SHOULD): expiration time, object size and type (here explicitly as per RFC 4288, while no such mention is found in -reqs), and "access statistics".

In Sec. 6.1.3.1 the ID mentions "List of associated data objects (with properties)". I guess you need to s/(with properties)/and their attributes/ to keep it in sync with the -reqs ID. That is, you point to -reqs/Sec. 5.4 and -arch/Sec. 6.1.4, not -reqs/Sec. 5.5 ;)

-reqs describes a set of requirements on error handling (Sec. 9 mainly, plus tidbits here and there in other sections), while -arch mentions (Sec. 6.2.2) that "Specifics regarding error handling, [...] are deferred to eventual protocol specification." I think this latter approach is better. I expressed this opinion on -reqs/Sec. 9 in my review of that document a couple of weeks ago.

Wrt to redirection of transport:
  -reqs-08/Sec. 7.7: A DECADE-compatible server SHOULD be able to redirect requests to another DECADE-compatible server.
  -arch-09/Sec 7.1: SDT therefore MUST provide a redirection mechanism as described as a requirement in [I-D.ietf-decade-reqs]. Duh.

As a general comment, there are several places in the draft where "see below/above/Sec. XX" appear. Often, they point to sections that do not provide substantially more details (sigh). But they always make reading cumbersome and they should be minimized. 

Other comments and nits, listed by section, follow.

Section 4
---------
Nit:
s/resources Section 6.1.1/resources *OR*
s/resources Section 6.1.1/resources (see Section 6.1.1)

Section 5
---------
s/the document details/this document details

There is something missing in Section 5.3.1, which is effectively empty: "Details of the naming scheme are discussed in Section 5.3." Well, we are in Sec. 5.3 and the naming scheme is not actually _detailed_...

In addition, in sec. 5.3.* there are a couple of references to sec. 5.1.1, which is now "Data Assembly". I have the vague impression that the reference to 5.1.1 is no longer valid.

Sec. 5.3.3 does not provide an example for the case where the DO needs to be fragmented to accommodate server maximum object size restrictions. In addition, since -arch leaves to particular protocols to set the restrictions on min and max sizes (and I agree to this), it is possible that two different implementations may have different container sizes. How does this affect naming as described in 5.3? 

s/A token-based authorization scheme is used/A token-based authorization scheme can be used

The sentence "[I-D.ietf-decade-reqs] details specific requirements of the discovery mechanism;" in Sec. 5.5 is not really reflecting the extent that discovery is covered in -reqs-08. See also the inconsistency mentioned at the beginning of this review.

Section 6
---------
Nits:

s/the DRP and the SDT protocol/DRP and SDT/

s/Provider and trusted by the client/Provider and trusted by the client and the server

Section 6.1.1 is a bit unclear. Since this is part of the DRP description, I would imagine that this refers to a (single) client/app managing its own (account) resources on the DECADE server. But, as it's written now, it can also refer to the total resources on a server (to be shared between all clients). It's best to remove this ambiguity from the text.

Section 6 effectively prescribes a token-based authentication scheme for DECADE. This goes beyond the examples presented in Sec. 3.2 & 5.4 and is an important design choice that should be explicitly included in the abstract of the doc as well as early on in the introduction etc. It's also worth noting that the word "token" appears once in -reqs-08 (Sec. 8.3), and about 60 times in -arch-09.

A point that is not covered currently is how does token-based AAA work with partial/chunk downloads. Once DECADE is widely deployed, a client may wish to obtain different DOs/chunks/frames/what-have-you from different peers, thus their corresponding servers in a DECADE-capable system. What kind of tokens would the content provider distribute in this case of dynamic download request environment? Maybe you could add a few sentences to clarify this aspect as well.

Nits:

s/SHOULD based on/SHOULD be based on

s/and for how/and how

s/a server as seen/a server has seen

s/to other client/to another client

s/cannot be delivered the server/cannot be delivered, the server

s/an corresponding/a corresponding

In Sec. 6.2.1, "The name can be used to access (download) the object later; for example, the client can pass the name as a reference to other client that can then refer to the object." The draft just explained that the whole access model is based on tokens, not names alone. Further, the reference to Sec. 5.3 is not particularly enlightening.

The text in Sec. 6.2.2 implies that all clients (including the one that uploaded the DO) will need the name+token to get access. Over-engineered?

The sentence "Data objects can be self-contained objects [..]" should reiterate the fundamental premise of object immutability in DECADE. Suggestion: "Data objects are immutable and can be self-contained objects [..]"

I am not sure why server-to-server (s2s) communication deserves its own section (Sec. 6.3) or lengthy consideration at the -arch level for that matter. How different is s2s communication? For example, why can't a client C instruct server B to obtain a DO from server A exactly the same way it instructs client D (Sec. 6.2)? The key feature here may be the definition of the proxy function for the DECADE architecture. If so, then the section should be reworked to reflect this. Thoughts?

In the same section, the sentence "Object attributes (see Section 6.1.4) might also be specified in the request to the remote server" is a bit at odds with the fact that said attributes are locally scoped.

Section 7
---------
Overall, I find this section a bit weak and more often than not particularly informal. Small editorial suggestions follow:

s/the effective security of this approach/the effectiveness of this approach

s/that the DRP has/that DRP has

s/and the SDT and DRP/and SDT and DRP

s/faked/forged

s/that is has/that it has

"A DECADE-compatible systems fundamental mechanism [..]" Rework sentence?

s/For those/For these

Section A
---------
Nits: 
s/of a SDT/of SDT/g

s/Immutable data objects might be stored at a server./Immutable data objects are stored at a server.

s/storing in/storing them in

Best regards,

Kostas

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 30 Aug 2012 16:26:45 -0400

Hi Kostas,

Thank you very much for the thorough re-review.  Sorry that I have been a bit slow in responding lately because of the summer holidays.  I have embedded some initial RESPONSES below to your first section on "Current inconsistencies between -reqs and -arch".  I will keep reading your "other comments and nits" and get back to you on those later.

Sincerely,

Akbar

-----Original Message-----
From: Konstantinos Pentikousis [mailto:[email-masked]] 
Sent: Monday, August 27, 2012 10:29 AM
To: [email-masked]; Rahman, Akbar; [email-masked]
Subject: Review of draft-ietf-decade-arch-09

(1) [AKBAR] OKAY.  THEY SHOULD BOTH BE "MUST" THEN TO BE CONSISTENT.

(2) [AKBAR]  OKAY, THEY SHOULD BOTH BE "MUST" THEN TO BE CONSISTENT.  BUT, I THINK IT IS OKAY THAT THERE IS NO REFERENCE TO RFC 4288 AND ACCESS STATS IN REQUIREMENTS, AS THE SPECIFICATION OF THESE CAN BE VIEWED AS A NATURAL 'DESIGN' STEP WHICH IS APPROPRIATE FOR THE ARCHITECTURE I-D.  DO YOU AGREE?

(3) [AKBAR] SOMEHOW YOU LOST ME HERE WITH THE DIFFERENT SECTION REFERENCES.  CAN YOU PLEASE RE-WORD YOUR COMMENT?

(4) [AKBAR]  AS ONE OF THE AUTHORS OF THE ARCHITECTURE I-D, I  HAD AGREED WITH YOUR ORIGINAL SUGGESTION AND THAT IS WHY THE ARCHITECTURE DOCUMENT WAS SIMPLIFIED WRT TO ERROR HANDLING.  I AM NOT AN AUTHOR ON THE REQUIREMENTS I-D AND SO CANNOT SPEAK FOR THEM.  HOWEVER, I DO SEE THAT A CASE COULD BE MADE THAT THESE ERROR CASES BE EXPLICITLY IDENTIFIED IN THE REQUIREMENTS I-D BECAUSE (I IMAGINE) THAT SOME PREVIOUS RESEARCH/THINKING HAS SHOWN THEM TO BE IMPORTANT ENOUGH TO BE LISTED AS EXPLICIT REQUIREMENTS SO THAT WHOEVER SPECIFIES THE PROTOCOL DOES NOT FORGET ABOUT THEM.  THIS AT LEAST HAS BEEN MY PERSONAL EXPERIENCE.  BUT I WILL LET ONE OF THE REQUIREMENTS I-D AUTHORS GIVE THE FINAL WORD ON THIS.

(5) [AKBAR] AS AN EDITORIAL POINT, I UNDESTAND THAT YOU POINT OUT THAT THE REFERENCE BACK TO THE REQS I-D FROM SECTION 5.5 AND 7.1 ARE REDUNDANT (/TRIVIAL/USELESS).  I AGREE. 

(6) [AKBAR] I AGREE AS PER (5) ABOVE AND WILL DO A SCRUB OF THE ARCHITECTURE I-D TO CLEAN THEM UP.

(7) [AKBAR] FYI - WE PLAN TO IMPLEMENT YOUR COMMENTS ABOVE AS PART OF ANY UPDATES TO RESOLVE IESG COMMENT.  I  HOPE THAT YOU ARE AMENABLE TO THIS!

Section 4
---------
Nit:

Section 5
---------

Section 6
---------
Nits:

Nits:

s/and for how/and how

Section 7
---------

s/faked/forged

s/For those/For these

Section A
---------
Nits: 
s/of a SDT/of SDT/g

Best regards,

Kostas

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Fri, 31 Aug 2012 17:28:30 +0000

Hi Akbar,

  |Thank you very much for the thorough re-review.  Sorry that I have
  |been a bit slow in responding lately because of the summer holidays.

You're most welcome and, of course, no problem.

  |I have embedded some initial RESPONSES below to your first section on
  |"Current inconsistencies between -reqs and -arch".  I will keep
  |reading your "other comments and nits" and get back to you on those
  |later.

Sure.

  |Current inconsistencies between -reqs and -arch
  |-----------------------------------------------
  |With respect to discovery mechanisms, there is a slight divergence
  |between the two documents:
  |  -reqs-08/Sec. 6.9: A mechanism for a Provider to discover and
  |connect to its assigned server MUST be supported.
  |  -arch-09/Sec 5.5: A DECADE-compatible system SHOULD include a
  |discovery mechanism through which clients locate an appropriate
  |server.
  |
  |
  |(1) [AKBAR] OKAY.  THEY SHOULD BOTH BE "MUST" THEN TO BE CONSISTENT.

Sounds good.

  |Similarly, -reqs/Sec. 5.4 requires (MUST) the following locally-scoped
  |attributes: TTL, creation timestamp, object size and type. But, -
  |arch/Sec. 6.1.4 recommends (SHOULD): expiration time, object size and
  |type (here explicitly as per RFC 4288, while no such mention is found
  |in -reqs), and "access statistics".
  |
  |(2) [AKBAR]  OKAY, THEY SHOULD BOTH BE "MUST" THEN TO BE CONSISTENT.
  |BUT, I THINK IT IS OKAY THAT THERE IS NO REFERENCE TO RFC 4288 AND
  |ACCESS STATS IN REQUIREMENTS, AS THE SPECIFICATION OF THESE CAN BE
  |VIEWED AS A NATURAL 'DESIGN' STEP WHICH IS APPROPRIATE FOR THE
  |ARCHITECTURE I-D.  DO YOU AGREE?

Yes, it's a good resolution.

  |In Sec. 6.1.3.1 the ID mentions "List of associated data objects (with
  |properties)". I guess you need to s/(with properties)/and their
  |attributes/ to keep it in sync with the -reqs ID. That is, you point
  |to -reqs/Sec. 5.4 and -arch/Sec. 6.1.4, not -reqs/Sec. 5.5 ;)
  |
  |(3) [AKBAR] SOMEHOW YOU LOST ME HERE WITH THE DIFFERENT SECTION
  |REFERENCES.  CAN YOU PLEASE RE-WORD YOUR COMMENT?

Sorry about that :) In short, the term "attribute" is used to refer to locally-scoped information stored at the DECADE server (e.g. TTL, creation timestamp, object size and type). This is defined in -reqs/Sec. 5.4. On the other hand, the term "property" appears to relate to application metadata ("application-defined object properties" is -reqs/Sec. 5.5). I like this term differentiation, hence the comment above, as you most likely refer to the former. That's why I proposed s/(with properties)/and their attributes/ in Sec. 6.1.3.1

  |-reqs describes a set of requirements on error handling (Sec. 9
  |mainly, plus tidbits here and there in other sections), while -arch
  |mentions (Sec. 6.2.2) that "Specifics regarding error handling, [...]
  |are deferred to eventual protocol specification." I think this latter
  |approach is better. I expressed this opinion on -reqs/Sec. 9 in my
  |review of that document a couple of weeks ago.
  |
  |(4) [AKBAR]  AS ONE OF THE AUTHORS OF THE ARCHITECTURE I-D, I  HAD
  |AGREED WITH YOUR ORIGINAL SUGGESTION AND THAT IS WHY THE ARCHITECTURE
  |DOCUMENT WAS SIMPLIFIED WRT TO ERROR HANDLING.  I AM NOT AN AUTHOR ON
  |THE REQUIREMENTS I-D AND SO CANNOT SPEAK FOR THEM.  HOWEVER, I DO SEE
  |THAT A CASE COULD BE MADE THAT THESE ERROR CASES BE EXPLICITLY
  |IDENTIFIED IN THE REQUIREMENTS I-D BECAUSE (I IMAGINE) THAT SOME
  |PREVIOUS RESEARCH/THINKING HAS SHOWN THEM TO BE IMPORTANT ENOUGH TO BE
  |LISTED AS EXPLICIT REQUIREMENTS SO THAT WHOEVER SPECIFIES THE PROTOCOL
  |DOES NOT FORGET ABOUT THEM.  THIS AT LEAST HAS BEEN MY PERSONAL
  |EXPERIENCE.  BUT I WILL LET ONE OF THE REQUIREMENTS I-D AUTHORS GIVE
  |THE FINAL WORD ON THIS.

I will wait for others to chime in then.

<snip>

  |(7) [AKBAR] FYI - WE PLAN TO IMPLEMENT YOUR COMMENTS ABOVE AS PART OF
  |ANY UPDATES TO RESOLVE IESG COMMENT.  I  HOPE THAT YOU ARE AMENABLE TO
  |THIS!
 
Sure, no problem.

Have a great weekend,

Kostas