From internet-drafts@ietf.org Mon May 7 02:59:15 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C19221F859F; Mon, 7 May 2012 02:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYvJI35kJC3W; Mon, 7 May 2012 02:59:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D871821F8592; Mon, 7 May 2012 02:59:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507095914.25751.30294.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 02:59:14 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-problem-statement-06.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 09:59:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : DECoupled Application Data Enroute (DECADE) Problem Stat= ement Author(s) : Haibin Song Ning Zong Y. Richard Yang Richard Alimi Filename : draft-ietf-decade-problem-statement-06.txt Pages : 14 Date : 2012-05-07 Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols and cache refresh mechanisms) and they do not allow users to manage access to content in the cache. For example, content providers wishing to use in- network storage cannot easily control cache access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, and shows the need for a standard protocol for accessing this storage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-06.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-06.t= xt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/ From iesg-secretary@ietf.org Mon May 7 07:53:41 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4821F85E3; Mon, 7 May 2012 07:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT4PvmRzeH72; Mon, 7 May 2012 07:53:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9CF21F85ED; Mon, 7 May 2012 07:53:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507145336.3330.70604.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 07:53:36 -0700 Cc: decade mailing list , decade chair , RFC Editor Subject: [decade] Document Action: 'DECoupled Application Data Enroute (DECADE) Problem Statement' to Informational RFC (draft-ietf-decade-problem-statement-06.txt) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 14:53:44 -0000 The IESG has approved the following document: - 'DECoupled Application Data Enroute (DECADE) Problem Statement' (draft-ietf-decade-problem-statement-06.txt) as Informational RFC This document is the product of the Decoupled Application Data Enroute Working Group. The IESG contact persons are Martin Stiemerling and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/ Technical Summary Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols and cache refresh mechanisms) and they do not allow users to manage access to content in the cache. For example, content providers wishing to use in- network storage cannot easily control cache access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, and shows the need for a standard protocol for accessing this storage. Working Group Summary The WG strongly supports this document for publication. Many WG members have read and agreed with it. Document Quality This is a problem statement document, and provides the motivations for the DECADE effort and its scope. Optimizing peer-to-peer applications are the primary motivation for DECADE, and the document authors and reviewers are well- versed in P2P technology. The document was reviewed by DECADE WG members, the WG Chairs, and key non-WG contributors, particularly by Akbar Rahman, Roni Even, David Bryan, Ning Zong, Börje Ohlmann and Tao Ma. Personnel Document Shepherd: Richard Woundy (richard_woundy@cable.comcast.com) Responsible Area Director: Martin Stiemerling (martin.stiemerling@neclab.eu) From richard.alimi@gmail.com Sat May 12 11:10:58 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8924321F85C5 for ; Sat, 12 May 2012 11:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[AWL=-2.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0JOUNVSTt7V for ; Sat, 12 May 2012 11:10:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8A121F85B5 for ; Sat, 12 May 2012 11:10:49 -0700 (PDT) Received: by yenq13 with SMTP id q13so4193786yen.31 for ; Sat, 12 May 2012 11:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=hapWvApR2lYNLBpyYdsKgMJDmp5eS2aIk/m2M3WQRYo=; b=ZiN+Es+S/aJbTneMH7l5iXKfkA7z23FerRNbA/dBTAvO65UpM8dJClmDphewqbDwKq ObRY0v/odk5g3jenYmpmEmOpiNOjUv9pEeEY7L81XEmJsRrduZWWR9De6xBPy4VVOHNW yYAtNyFztpqNHZ2TF+WlLv6er/r+RsbVo4T9ZBh/Daox/du2fy8druVaWYTbKGR0zGkk Dq3t4qhH/k5SwR+5rQAjWgtDSahuUFpb9xkNWEtc93RRGNlgDcFP9PgKSeMvlXcMTmhq 1xgnWMq7vMXGL8aOq0q2x230PzjebUI6QdWY14PH/0u+eSFz16KJPFAPn7+Kk+JOs04r ZQ/Q== Received: by 10.50.168.34 with SMTP id zt2mr1389635igb.10.1336846249003; Sat, 12 May 2012 11:10:49 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.209.82 with HTTP; Sat, 12 May 2012 11:10:28 -0700 (PDT) From: Richard Alimi Date: Sat, 12 May 2012 11:10:28 -0700 X-Google-Sender-Auth: abIMDVa9v-o9sUkZ_P0RQudC2Sg Message-ID: To: decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [decade] WG Review of draft-ietf-decade-integration-example-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 18:10:58 -0000 The following is my review of draft-ietf-decade-integration-example-03. Overall, the document is much improved. It could still use some general revision for grammar and to make the wording more concise. Detailed review: ** Introduction s/firstly/first "we only show the feasibility of ALTO and INS without comparing to other content distribution systems at this time" - what other "content distribution systems" would be compared against? - if not at this time, is that planned for a future iteration of this draft (if not I'd suggest removing "at this time") ** Terminlogy add definition for "native application client" INS Service Provider - does it deploy the entire INS system, or just some servers? INS Portal - why simulated? what's a simulated portal? - don't use 'portal' in order to define the term ** INS Client API define what a 'token' is (or provide a reference) s/authorized token/authorization token/ why does the particular example (ALTO + INS) determine who generates the token? Is this detail necessary in the API description? ** Integration of P2P Live Streaming and INS System Introductory sentence can be simplified to just "We integrate an INS client into a P2P live streaming client." The rest is repetative. what does it mean to be "compatible with original P2P live streaming signalling"? Is it more accurate to just say that existing signallling is still used? "whose size can be application-customized according to the variable requirements of of performance or sensitive factors" - wording seems awkward. How about something like "the API supports variable-sized blocks to cater to different application requirements (e.g., latency and throughput)." For live streaming, in what sense are they "bittorrent-like"? Piece exchanges? (the concept of the torrent file and piece map doesn't directly apply without modifications) "On the other hand, INS-enabled .." - remove "on the other hand" is the token exchange message the reason for the INS Client <-> INS Client line in Figure 1? If so, explain in the "Control Messages" section tha tthis does not use (or extend) the native application protocol. To what extent are the recommendations based on the fact that M=1 in the implementation? The stronger argument to make might be that the INS server may need to concurrently serve many thousands (or more) clients. "can use this range token to access all available data objects in the INS server" - make it clear that it isn't all objects in the server, but only those to which it was permitted access The design considerations would be a lot more convincing and easier to follow if the message flow were discussed before making the recommendations. Otherwise, the reader is less clear on the particular problem being solved. (Presenting filesharing before live streaming may solve the problem.) ** Integration of P2P file sharing and INS system Is Figure 1 basically the same as Figure 2 with the exception of Figure 2 saying Vuze? If they are the same, perhaps just present the general architecture at the beginning of the document and say it works with both filesharing and live streaming (reuse is a good thing). Either explain why it is an "Azureous handshake" or replace it with just "handshake reply" or similar There seems to be a transition sentence missing before the details of Figure 4 are discussed. Are ther eany additional lessons/recommendatons based on the filesharing integration? Even if there aren't, it seems like there should be some sort of concluding remarks in that section. ** Integration of ALTO and INS System for File Distribution Alto doesn't (typically) give information to end users. It gives information to applications run by those end users :) s/content servers/content providers/ alto won't help reduce bandwidth consumption for the end host (the current text seems to imply that). make it clear that it can reduce network usage within ISP s/Architecture Design/Architecture/ how does alto help CPs to upload files ot INS servers? In Figure 5, why don't End Users talk to INS Servers? It makes it look like the CP Portal and INS Portal are on the data path for downloads. Similar comment for End Users and ALTO Server. In Figure 6, why not have the Portal redirect the uploder to an INS server instead of acting as a proxy? Acting as a proxy means the portal (a server or set of servers presumably) must have an aggregate network capacity equal to the sum of the total upload rate that it wishes to provide to all the INS servers. By not using the proxy design, it also means the INS Portal no longer needs to define protocol messaging for communicating things like placement policies. s/HTTP_POST/HTTP POST/ In the downloading procedure, is the user using a standard web browser? From the description, it seems like there must be some sort of INS extension installed in the web browser (in order to understand tokens, know how to communicate with INS servers, etc). That should be stated. What is the relationship between the ISP and the INS Service Provider? Does the INS Service Provider have servers in multiple ISPs (in which case it would make sense to consult ALTO servers from each ISP). Or is the INS Service Provider the same as the ISP? How is "optimal" decided? ** Test Environment and Settings Avoid using the word "cloud". They are large sets of servers available for use. wild-spread area -> global? how is geolocation distance computed? Figure 9 - also include where the servers were in the figure? (like Figure 8) s/leeches/leechers/ would it be simpler to just assume PlanetLab Manager was part of the text controller and not mention it explicitly? "4G CPU" -> 4 CPU? (or, did you find 4-Ghz CPUs?) If you found a VM with 4 billion CPUs that were halfway-decent, we should chat :) For filesharing, why is there 480MB of download traffic in the INS case but 430MB in the native case? Can an INS server always supply 94%, or only when there was a 1Gbps NIC? More specifically, does it supply 9.4Gbps with a 10Gbps NIC? it would be interesting to note what scaling issues you found passed 400 concurrent users at an INS server. From richard.alimi@gmail.com Sat May 12 11:18:55 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B83421F8589 for ; Sat, 12 May 2012 11:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGRMOhJimlQ3 for ; Sat, 12 May 2012 11:18:54 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A380221F8522 for ; Sat, 12 May 2012 11:18:54 -0700 (PDT) Received: by yenq13 with SMTP id q13so4196327yen.31 for ; Sat, 12 May 2012 11:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=NyBEi0iRHmeP6aG/xM+c7i3E7C3a1tEK9EAjL7Ve0Mw=; b=x0XffbA3Kp5H36mTsxceaYsCpGhaWeAp3aTTczZiRoQ+fHPPAcspkUYAbd6Rhxx3sI XC9P6/YcBZDxmfu6Z/4pouJ0ccBc2f7LLesW62oQdW4BwVHch/X/okeU4psC6GFWyMrV BFt1vzpOYQ3mCg32azlpNwn+XtxfxAdTnNqhH2aaSvin3khMhPHPHEtNCbjk1Cq33O2i bWI+WlphNf4Gwwobdxi9qSVS8TYjBMZNc6gKWXFa2KpIPz77p1di/FtXkBctl1SnplS2 0zAos/MO057Ap87wNHoECdeoZdVOtjOHBTXDoI59oqeeFE+/5s4rj0naU9D2uYv1t8Dh Q77g== Received: by 10.42.153.10 with SMTP id k10mr1126782icw.24.1336846734020; Sat, 12 May 2012 11:18:54 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.209.82 with HTTP; Sat, 12 May 2012 11:18:33 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD131A168EC@PACDCEXMB05.cable.comcast.com> From: Richard Alimi Date: Sat, 12 May 2012 11:18:33 -0700 X-Google-Sender-Auth: 040wCR-x46h7bPT0LWf8psb0EOQ Message-ID: To: Songhaibin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] Remote Get Object Message X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 18:18:55 -0000 I'm late to the game, but I agree that using the proxy concept for remote-get and standard (simple) operations for the others seems pretty clean. Rich On Tue, Apr 17, 2012 at 7:23 PM, Songhaibin wrote: > I also agree with that using standard HTTP GET and POST can be better for > remote get behavior and server to server data communication than inventin= g > new headers. I also agree with the non-transparent proxy concept. > > > > BR, > > -Haibin (as contributor) > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > Rahman, Akbar > Sent: Tuesday, April 03, 2012 9:55 PM > > > To: Woundy, Richard > Cc: decade@ietf.org > Subject: Re: [decade] Remote Get Object Message > > > > Hi Rich, > > > > > > Yes, that is a good point.=A0 I agree that for server-server communicatio= ns > (without a client involved) then standard HTTP GETs, PUTs and POSTs could= be > used without need for new headers or methods. > > > > > > Akbar > > > > > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Monday, April 02, 2012 3:53 PM > To: Rahman, Akbar > Cc: decade@ietf.org; Woundy, Richard > Subject: RE: [decade] Remote Get Object Message > > > >> However, I guess this model breaks down if we are required to support a >> use case where =93DECADE server-1=94 wants to exchange content with =93D= ECADE >> server-2=94 without being triggered by a client. > > > > Yes I would tend to agree. One *could* make this look like a proxy case b= y > forcing server-1 to act as its own proxy, but that seems inelegant. > > > > But then I would imagine that server-1 could obtain content from server-2 > using a simple HTTP GET, and could push content to server-2 using a simpl= e > HTTP POST, right? We still wouldn=92t need a new X-DECADE-ORIGIN header o= r a > new HTTP message, right? > > > > -- Rich > > > > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > Sent: Friday, March 30, 2012 8:40 PM > To: Woundy, Richard > Cc: decade@ietf.org > Subject: RE: [decade] Remote Get Object Message > > > > Hi Rich, > > > > I agree that using a classic HTTP GET request (instead of a new modified > POST) to implement the =93DECADE-compatible Remote Get Object=94 message = is a > good approach. > > > > I also like your proposal for the local DECADE server to act as a > non-transparent proxy when processing a request from a client. =A0=A0(I.E= . > Client makes a request to =93DECADE server-1=94 which then acts as a prox= y by > forwarding the request to =93DECADE server-2=94). > > > > However, I guess this model breaks down if we are required to support a u= se > case where =93DECADE server-1=94 wants to exchange content with =93DECADE > server-2=94 without being triggered by a client. > > > > Do you agree? > > > > Akbar > > > > > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > Woundy, Richard > Sent: Friday, March 30, 2012 10:37 AM > To: decade@ietf.org > Subject: [decade] Remote Get Object Message > > > > Folks, > > > > In Thursday's session, we discussed how to implement the Remote Get Objec= t > message. One proposal is to use HTTP Post with a new X-DECADE-ORIGIN head= er; > another proposal is to define a new HTTP message. See slide 3 of > and > . > > > > My thought (as an individual contributor, not as co-chair) is to use > existing HTTP Get headers and leverage the base functionality of an HTTP > caching proxy in DECADE. The local "DECADE" server would act as a caching > proxy (with additional functionality of course) in order to reach the rem= ote > "DECADE" server, and cache the contents of the reply in the "DECADE" > storage. I have a "non-transparent proxy" behavior in mind, per the > definition of "proxy" in RFC 2616 > (http://tools.ietf.org/html/rfc2616#section-1.3). Also see > , > , and perhaps > as well. > > > > Did we fully explore this possibility? As a co-chair, I can assure you th= at > it would be much better to leverage existing protocols and standards, ver= sus > inventing new ones. > > > > -- Rich From Dirk.Kutscher@neclab.eu Mon May 14 00:34:34 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9A021F85B6 for ; Mon, 14 May 2012 00:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH+BKsTTa+uT for ; Mon, 14 May 2012 00:34:33 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8900121F85A8 for ; Mon, 14 May 2012 00:34:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BC37E10107D; Mon, 14 May 2012 09:29:42 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc45MRxuJVgH; Mon, 14 May 2012 09:29:42 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 96FC910107B; Mon, 14 May 2012 09:29:27 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.189]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 14 May 2012 09:33:56 +0200 From: Dirk Kutscher To: Richard Alimi , Songhaibin Thread-Topic: [decade] Remote Get Object Message Thread-Index: AQHNDoKBg3eg7H8F4ECL+B6dPaD8m5aDi/UwgARonwCAATCQAIAWz0iQgCakT4CAAoBigA== Date: Mon, 14 May 2012 07:33:55 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524924CB6551@PALLENE.office.hd> References: <1CA25301D2219F40B3AA37201F0EACD131A168EC@PACDCEXMB05.cable.comcast.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.204] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] Remote Get Object Message X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 07:34:34 -0000 Hi, So, I agree that DECADE should not introduce new HTTP headers, let alone ne= w message types, without real good reasons. Regarding GET vs. POST, I think it will be important to have a closer look = at the protocol semantics. For example, if it is just HTTP-GET semantics an= d DECADE is using URI types that existing proxies understand (http in this = case), HTTP-GET should be used (to enable using existing proxies). But there can be reasons to use POST, specifically if the DECADE protocol u= sed non-HTTP URI types*and* existing proxy infrastructure should be used. I= n that case, it may be better to use POST (with a well-known local part of = the URI, e.g., as in http://example.com/decade/get) and to provide DECADE r= equest parameters such as the object name in form data parameters. It can b= e possible to cache responses to those requests (requiring cache-control he= aders). Best regards, Dirk > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > Behalf Of Richard Alimi > Sent: Samstag, 12. Mai 2012 20:19 > To: Songhaibin > Cc: decade@ietf.org > Subject: Re: [decade] Remote Get Object Message >=20 > I'm late to the game, but I agree that using the proxy concept for remote= -get > and standard (simple) operations for the others seems pretty clean. >=20 > Rich >=20 > On Tue, Apr 17, 2012 at 7:23 PM, Songhaibin > wrote: > > I also agree with that using standard HTTP GET and POST can be better > > for remote get behavior and server to server data communication than > > inventing new headers. I also agree with the non-transparent proxy > concept. > > > > > > > > BR, > > > > -Haibin (as contributor) > > > > > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > > Behalf Of Rahman, Akbar > > Sent: Tuesday, April 03, 2012 9:55 PM > > > > > > To: Woundy, Richard > > Cc: decade@ietf.org > > Subject: Re: [decade] Remote Get Object Message > > > > > > > > Hi Rich, > > > > > > > > > > > > Yes, that is a good point.=A0 I agree that for server-server > > communications (without a client involved) then standard HTTP GETs, > > PUTs and POSTs could be used without need for new headers or methods. > > > > > > > > > > > > Akbar > > > > > > > > > > > > > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Monday, April 02, 2012 3:53 PM > > To: Rahman, Akbar > > Cc: decade@ietf.org; Woundy, Richard > > Subject: RE: [decade] Remote Get Object Message > > > > > > > >> However, I guess this model breaks down if we are required to support > >> a use case where "DECADE server-1" wants to exchange content with > >> "DECADE server-2" without being triggered by a client. > > > > > > > > Yes I would tend to agree. One *could* make this look like a proxy > > case by forcing server-1 to act as its own proxy, but that seems ineleg= ant. > > > > > > > > But then I would imagine that server-1 could obtain content from > > server-2 using a simple HTTP GET, and could push content to server-2 > > using a simple HTTP POST, right? We still wouldn't need a new > > X-DECADE-ORIGIN header or a new HTTP message, right? > > > > > > > > -- Rich > > > > > > > > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > > Sent: Friday, March 30, 2012 8:40 PM > > To: Woundy, Richard > > Cc: decade@ietf.org > > Subject: RE: [decade] Remote Get Object Message > > > > > > > > Hi Rich, > > > > > > > > I agree that using a classic HTTP GET request (instead of a new > > modified > > POST) to implement the "DECADE-compatible Remote Get Object" > message > > is a good approach. > > > > > > > > I also like your proposal for the local DECADE server to act as a > > non-transparent proxy when processing a request from a client. =A0=A0(I= .E. > > Client makes a request to "DECADE server-1" which then acts as a proxy > > by forwarding the request to "DECADE server-2"). > > > > > > > > However, I guess this model breaks down if we are required to support > > a use case where "DECADE server-1" wants to exchange content with > > "DECADE server-2" without being triggered by a client. > > > > > > > > Do you agree? > > > > > > > > Akbar > > > > > > > > > > > > > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > > Behalf Of Woundy, Richard > > Sent: Friday, March 30, 2012 10:37 AM > > To: decade@ietf.org > > Subject: [decade] Remote Get Object Message > > > > > > > > Folks, > > > > > > > > In Thursday's session, we discussed how to implement the Remote Get > > Object message. One proposal is to use HTTP Post with a new > > X-DECADE-ORIGIN header; another proposal is to define a new HTTP > > message. See slide 3 of > > and > . > > > > > > > > My thought (as an individual contributor, not as co-chair) is to use > > existing HTTP Get headers and leverage the base functionality of an > > HTTP caching proxy in DECADE. The local "DECADE" server would act as a > > caching proxy (with additional functionality of course) in order to > > reach the remote "DECADE" server, and cache the contents of the reply i= n > the "DECADE" > > storage. I have a "non-transparent proxy" behavior in mind, per the > > definition of "proxy" in RFC 2616 > > (http://tools.ietf.org/html/rfc2616#section-1.3). Also see > > , > > , and perhaps > > as well. > > > > > > > > Did we fully explore this possibility? As a co-chair, I can assure you > > that it would be much better to leverage existing protocols and > > standards, versus inventing new ones. > > > > > > > > -- Rich From internet-drafts@ietf.org Thu May 31 08:08:22 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DF221F877D; Thu, 31 May 2012 08:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHIKHmZmubBa; Thu, 31 May 2012 08:08:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E426321F873A; Thu, 31 May 2012 08:08:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120531150821.6423.74137.idtracker@ietfa.amsl.com> Date: Thu, 31 May 2012 08:08:21 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-arch-06.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:08:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : DECADE Architecture Author(s) : Richard Alimi Akbar Rahman Dirk Kutscher Y. Richard Yang Filename : draft-ietf-decade-arch-06.txt Pages : 33 Date : 2012-05-31 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 required for introducing a DECADE-compatible in- network storage system. In addition, some examples are given to illustrate these concepts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-arch-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-arch-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-decade-arch/ From Akbar.Rahman@InterDigital.com Thu May 31 08:12:14 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE5E21F8735 for ; Thu, 31 May 2012 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhE4J5ev6lsl for ; Thu, 31 May 2012 08:12:13 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id E711B21F87A0 for ; Thu, 31 May 2012 08:12:12 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 May 2012 11:12:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 31 May 2012 11:12:11 -0400 Message-ID: In-Reply-To: <20120531150821.6423.74137.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] I-D Action: draft-ietf-decade-arch-06.txt Thread-Index: Ac0/P00yIbfS/SZ+Tym2S9hFvvMp+QAABG4g References: <20120531150821.6423.74137.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 31 May 2012 15:12:12.0321 (UTC) FILETIME=[C15D2910:01CD3F3F] Subject: Re: [decade] I-D Action: draft-ietf-decade-arch-06.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:12:14 -0000 SGksDQoNCg0KVGhlIGF1dGhvcnMgaGF2ZSB1cGRhdGVkIHRoZSBERUNBREUgQXJjaGl0ZWN0dXJl IEktRCBleHRlbnNpdmVseSB0byBhZGRyZXNzIHRoZSBtYW55IGdvb2QgY29tbWVudHMgZnJvbSBD YXJzdGVuIEJvcm1hbm4gYW5kIERhdmUgSGFycmluZ3Rvbi4NCg0KDQpTaW5jZXJlbHksDQoNCg0K QWtiYXINCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkZWNhZGUtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpTZW50OiBUaHVyc2RheSwgTWF5IDMxLCAyMDEy IDExOjA4IEFNDQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQpDYzogZGVjYWRlQGlldGYub3Jn DQpTdWJqZWN0OiBbZGVjYWRlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRlY2FkZS1hcmNoLTA2 LnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgRGVjb3VwbGVkIEFwcGxpY2F0aW9uIERhdGEgRW5yb3V0ZSBXb3JraW5nIEdyb3Vw IG9mIHRoZSBJRVRGLg0KDQoJVGl0bGUgICAgICAgICAgIDogREVDQURFIEFyY2hpdGVjdHVyZQ0K CUF1dGhvcihzKSAgICAgICA6IFJpY2hhcmQgQWxpbWkNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgQWtiYXIgUmFobWFuDQogICAgICAgICAgICAgICAgICAgICAgICAgIERpcmsgS3V0c2NoZXIN CiAgICAgICAgICAgICAgICAgICAgICAgICAgWS4gUmljaGFyZCBZYW5nDQoJRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtaWV0Zi1kZWNhZGUtYXJjaC0wNi50eHQNCglQYWdlcyAgICAgICAgICAgOiAz Mw0KCURhdGUgICAgICAgICAgICA6IDIwMTItMDUtMzENCg0KICAgQ29udGVudCBEaXN0cmlidXRp b24gQXBwbGljYXRpb25zIChlLmcuLCBQMlAgYXBwbGljYXRpb25zKSBhcmUgd2lkZWx5DQogICB1 c2VkIG9uIHRoZSBJbnRlcm5ldCBhbmQgbWFrZSB1cCBhIGxhcmdlIHBvcnRpb24gb2YgdGhlIHRy YWZmaWMgaW4NCiAgIG1hbnkgbmV0d29ya3MuICBPbmUgdGVjaG5pcXVlIHRvIGltcHJvdmUgdGhl IG5ldHdvcmsgZWZmaWNpZW5jeSBvZg0KICAgdGhlc2UgYXBwbGljYXRpb25zIGlzIHRvIGludHJv ZHVjZSBzdG9yYWdlIGNhcGFiaWxpdGllcyB3aXRoaW4gdGhlDQogICBuZXR3b3JrczsgdGhpcyBp cyB0aGUgY2FwYWJpbGl0eSBwcm92aWRlZCBieSBhIERFQ0FERSAoREVDb3VwbGVkDQogICBBcHBs aWNhdGlvbiBEYXRhIEVucm91dGUpIGNvbXBhdGlibGUgc3lzdGVtLiAgVGhpcyBkb2N1bWVudCBw cmVzZW50cw0KICAgYW4gYXJjaGl0ZWN0dXJlLCBkaXNjdXNzZXMgdGhlIHVuZGVybHlpbmcgcHJp bmNpcGxlcywgYW5kIGlkZW50aWZpZXMNCiAgIGtleSBmdW5jdGlvbmFsaXRpZXMgcmVxdWlyZWQg Zm9yIGludHJvZHVjaW5nIGEgREVDQURFLWNvbXBhdGlibGUgaW4tDQogICBuZXR3b3JrIHN0b3Jh Z2Ugc3lzdGVtLiAgSW4gYWRkaXRpb24sIHNvbWUgZXhhbXBsZXMgYXJlIGdpdmVuIHRvDQogICBp bGx1c3RyYXRlIHRoZXNlIGNvbmNlcHRzLg0KDQoNCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQt RHJhZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LWRlY2FkZS1hcmNoLTA2LnR4dA0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KDQpUaGlzIEludGVybmV0LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6DQpmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZGVjYWRlLWFyY2gtMDYudHh0DQoN ClRoZSBJRVRGIGRhdGF0cmFja2VyIHBhZ2UgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRlY2FkZS1hcmNoLw0K DQo=