From nobody Tue Sep 1 01:52:33 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65091B389D for ; Tue, 1 Sep 2015 01:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.831 X-Spam-Level: * X-Spam-Status: No, score=1.831 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.741, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYfHAxfd5nCM for ; Tue, 1 Sep 2015 01:52:30 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 87EF31B3527 for ; Tue, 1 Sep 2015 01:52:28 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.45]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMZVHZ+VVGta_Bw--.9637S2; Tue, 01 Sep 2015 16:52:23 +0800 (CST) Date: Tue, 1 Sep 2015 16:52:08 +0800 From: "qinxiaowei@cnnic.cn" To: storagesync X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2015090116520811787510@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart046434137210_=----" X-CM-TRANSID: AQAAf0ApMZVHZ+VVGta_Bw--.9637S2 X-Coremail-Antispam: 1UD129KBjvdXoWruF1DKrykKrWfGFW3KrWkCrg_yoWkXFc_JF yUJFy8Jr18JF1xJr4DJrnxJrn0qryqgry8J34UJr4Utry7Ar1kJr1DXr4UXr1UXw4UGr1U GF13Zr18Jr15ujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbLAYjsxI4VWDJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG62kEwI0E Y4vaYxAvb48xMc02F40Ex7xS67I2xxkvbII20VAFz48EcVAYj21l5I8CrVC20s02628v4x 8GjsIEw4AK0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S 6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFc xC0VAYjxAxZF0Ex2IqxwCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK67AK6r43MxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU0 aXd5UUUUU== X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 08:52:32 -0000 This is a multi-part message in MIME format. ------=_001_NextPart046434137210_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 aGksIA0KVGhpcmQtcGFydHkgQVBJIGFuZCBvcHRpbWl6aW5nIHRoZSBzeW5jIHByb3RvY29scyBt YXkgYmUgaW1wb3J0YW50IGZvciBPbmxpbmUgc3RvcmFnZS4gQnV0LCBJTU8sIHRoZSBtb3N0IGlt cG9ydGFudCBpcyBpbXByb3ZpbmcgZGF0YSB1cGxvYWQgcmF0ZSB0aGF0IGVuZCB1c2VycyBjYW4g b2J0YWluLg0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSGkgZm9sa3MsCldlbGNv bWUgdG8gdGhlIG1haWxpbmcgbGlzdCBvZiBJbnRlcm5ldCBTdG9yYWdlIFN5bmMgKFN0b3JhZ2Vz eW5jQGlldGYub3JnKS4gVGhpcyBsaXN0IGlzIGZvciB0aGUgZGlzY3Vzc2lvbnMgb2YgSW50ZXJu ZXQgU3RvcmFnZSBTeW5jIHdvcmsuIFlvdSBhcmUgd2VsY29tZSB0byBpbnRyb2R1Y2UgeW91cnNl bGYgaGVyZSBhbmQgc3RhcnQgcmVsYXRlZCBkaXNjdXNzaW9ucy4KV2UndmUgcHJvZHVjZWQgYSBk cmFmdCB0byBvdXRsaW5lIHRoZSBtYWluIHByb2JsZW1zIGluIGV4aXN0aW5nIEludGVybmV0IHN0 b3JhZ2Ugc2VydmljZXMsIHBsZWFzZSBmaW5kIHRoZSBkb2N1bWVudCB3aXRoIHRoZSBmb2xsb3dp bmcgbGluay4gUGxlYXNlIGZlZWwgZnJlZSB0byBjb21tZW50IG9uIGl0IGFuZCB5b3VyIHZhbHVh YmxlIGNvbW1lbnRzIGFyZSBtb3JlIHRoYW4gd2VsY29tZS4KaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1jdWktaXNzLXByb2JsZW0vCkEgd2lraSBmb3Igc29tZSB1c2VmdWwg cmVzb3VyY2VzIGFuZCBsaW5rcyBjb3VsZCBiZSBmb3VuZC4gUGxlYXNlIGZlZWwgZnJlZSB0byBl ZGl0IGl0IG9yIGxldCB1cyBrbm93IGlmIHdlJ3ZlIG1pc3NlZCBzb21ldGhpbmcuIApodHRwczov L2dpdGh1Yi5jb20vaXNzLWlldGYvaXNzL3dpa2kvSW50ZXJuZXQtU3RvcmFnZS1TeW5jLwpSZWdh cmRzLApZb25nIEN1aSwKUHJvZmVzc29yLCBUc2luZ2h1YSBVbml2ZXJzaXR5LCBCZWlqaW5nLCBD aGluYQpBc3NvY2lhdGUgRWRpdG9yIG9uIElFRUUgVFBEUywgSUVFRSBUQ0MKVVJMOiBodHRwOi8v d3d3LjRvdmVyNi5lZHUuY24vY3VpeW9uZy9pbmRleC5odG1sDQoNCg0KDQo= ------=_001_NextPart046434137210_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= body>=0A
hi, 
Third-party API and optimizing the sync protocols m= ay be important for Online storage. But, IMO, the most important is improv= ing data upload rate that end users can obtain.







----------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------
<= pre class=3D"wordwrap">Hi folks,=0AWelcome to the mailing list of Internet= Storage Sync (Storagesync@ietf.org). This list is for the discussions of = Internet Storage Sync work. You are welcome to introduce yourself here and= start related discussions.=0AWe've produced a draft to outline the main p= roblems in existing Internet storage services, please find the document wi= th the following link. Please feel free to comment on it and your valuable= comments are more than welcome.=0Ahttp://datatracker.ietf.org/doc/draft-c= ui-iss-problem/=0AA wiki for some useful resources and links could be foun= d. Please feel free to edit it or let us know if we've missed something. = =0Ahttps://github.com/iss-ietf/iss/wiki/Internet-Storage-Sync/=0ARegards,= =0AYong Cui,=0AProfessor, Tsinghua University, Beijing, China=0AAssociate = Editor on IEEE TPDS, IEEE TCC=0AURL: http://www.4over6.edu.cn/cuiyong/inde= x.html
=0A

=0A
=0A ------=_001_NextPart046434137210_=------ From nobody Tue Sep 1 06:10:11 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E671B2C89 for ; Tue, 1 Sep 2015 06:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQlZ_ZM_xp_2 for ; Tue, 1 Sep 2015 06:10:06 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CE21B450B for ; Tue, 1 Sep 2015 06:09:46 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so12011021wic.0 for ; Tue, 01 Sep 2015 06:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=L+Ed0KofJtXwvODHKLFPO11BSHwtyzNZ32u+e7JQ8y8=; b=shyyApVLbwZhWkniigtIc1VCgG+UM32YnLAau7speckszMYxlz7IIjGMOkoJGpSC21 cryu9s0s5vntSK/jj/Ne4IRAxTLRSfVqmvoJIJElbyl7MbHAdzJyJ+/jGmRGmm7E9cte nUO2fcEjIykto62PFEfaehIQzeazAwINVudyeGKpBHFDaqvblFKuT3uOUmF5/1L9bkdP 2rMaAqzpBUgcdj8fpzHuJdDm4U/wgEjFNzoYTiR9ZcBysQ4KfEITQOxKUbmwDBGXkazU JkFNCZO6IXjkN2bvvLySCo8gFxFnVhItT/pjzgpP8+Iwf9YUgKLDdR2TrHKbnzD8DqTz M2uQ== X-Received: by 10.194.58.199 with SMTP id t7mr34677394wjq.45.1441112982594; Tue, 01 Sep 2015 06:09:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.22.209 with HTTP; Tue, 1 Sep 2015 06:09:23 -0700 (PDT) In-Reply-To: <2015090116520811787510@cnnic.cn> References: <2015090116520811787510@cnnic.cn> From: Linhui Sun Date: Tue, 1 Sep 2015 21:09:23 +0800 Message-ID: To: "qinxiaowei@cnnic.cn" , storagesync Content-Type: multipart/alternative; boundary=047d7bacc66468a92f051eaf4323 Archived-At: Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 13:10:09 -0000 --047d7bacc66468a92f051eaf4323 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Xiaowei, Thanks for sharing your thoughts. I think the things you mentioned are not conflicting when considering the standardization of sync protocol. If we could come up with an open and standard sync protocol, the third-party APIs could be significantly simplified. And it is reasonable and necessary that such standard sync protocol should pay more attention to the sync efficiency to allow users have an ideal upload rate. Any comments? Actually we outline five different problems in the problem statement draft. Problem 4 and 5 reveals why most existing proprietary sync protocols do not have a satisfactory sync efficiency (e.g. poor performance on upload rate). 1) *Complicated Support for APIs* 2) *Unavailable Cross-service Sync* 3) *Redundant Similar Clients* 4) *Different Capability Configurations and Implementations* 5) *Challenges in Mobile and Wireless Environments * (More detailed descriptions could be found in: http://datatracker.ietf.org/doc/draft-cui-iss-problem/) In addition, I think the most urgent task of this Non-WG list is to have an agreement on the specified problems and the scope of work. Thus may I ask the people in this list to share your thoughts on the problems and scope of work? Which problem do you think is not required or is there any other problems we haven't mentioned in the draft? Please feel free to comment on it. Best regards, Linhui 2015-09-01 16:52 GMT+08:00 qinxiaowei@cnnic.cn : > hi, > Third-party API and optimizing the sync protocols may be important for > Online storage. But, IMO, the most important is improving data upload rat= e > that end users can obtain. > > > > > > > > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------- > > Hi folks, > Welcome to the mailing list of Internet Storage Sync (Storagesync@ietf.or= g). This list is for the discussions of Internet Storage Sync work. You are= welcome to introduce yourself here and start related discussions. > We've produced a draft to outline the main problems in existing Internet = storage services, please find the document with the following link. Please = feel free to comment on it and your valuable comments are more than welcome= .http://datatracker.ietf.org/doc/draft-cui-iss-problem/ > A wiki for some useful resources and links could be found. Please feel fr= ee to edit it or let us know if we've missed something. https://github.com/= iss-ietf/iss/wiki/Internet-Storage-Sync/ > Regards, > Yong Cui, > Professor, Tsinghua University, Beijing, China > Associate Editor on IEEE TPDS, IEEE TCC > URL: http://www.4over6.edu.cn/cuiyong/index.html > > > ------------------------------ > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --047d7bacc66468a92f051eaf4323 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Xiaowei,

Thanks for sharing your tho= ughts. I think the things you mentioned are not conflicting when considerin= g the standardization of sync protocol. If we could come up with an open an= d standard sync protocol, the third-party APIs could be significantly simpl= ified. And it is reasonable and necessary that such standard sync protocol = should pay more attention to the sync efficiency to allow users have an ide= al upload rate.

Any comments?

=
Actually we outline five different problems in the problem statement d= raft. Problem 4 and 5 reveals why most existing proprietary sync protocols = do not have a=C2=A0satisfactory sync efficiency (e.g. poor performance on u= pload rate).

1) Complicated Support for APIs
2) Unavailable Cross-service Sync
3) <= b>Redundant Similar Clients
4) Different Capability Co= nfigurations and Implementations
5) Challenges in Mobi= le and Wireless Environments=C2=A0
(More detailed descrip= tions could be found in:=C2=A0http://datatracker.ietf.org/doc/draft-cui-iss-problem= /)

In addition, I think the most urgent task o= f this Non-WG list is to have an agreement on the specified problems and th= e scope of work. Thus may I ask the people in this list to share your thoug= hts on the problems and scope of work? Which problem do you think is not re= quired or is there any other problems we haven't mentioned in the draft= ? Please feel free to comment on it.

Best regards,=
Linhui

2015-09-01 16:52 GMT+08:00 qin= xiaowei@cnnic.cn <qinxiaowei@cnnic.cn>:
hi,=C2=A0
Third-party API and optimizing the sync protocols may be important for On= line storage. But, IMO, the most important is improving data upload rate th= at end users can obtain.






---= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -----------------------------------
Hi folk=
s,
Welcome to the mailing list of Internet Storage Sync (Storagesync@ietf.org). This list i=
s for the discussions of Internet Storage Sync work. You are welcome to int=
roduce yourself here and start related discussions.
We've produced a draft to outline the main problems in existing Interne=
t storage services, please find the document with the following link. Pleas=
e feel free to comment on it and your valuable comments are more than welco=
me.
http://datatracker.ietf.org/doc/draft-cui-iss-problem/
A wiki for some useful resources and links could be found. Please feel free=
 to edit it or let us know if we've missed something.=20
https://github.com/iss-ietf/iss/wiki/Internet-Storage-Sync/<=
/a>
Regards,
Yong Cui,
Professor, Tsinghua University, Beijing, China
Associate Editor on IEEE TPDS, IEEE TCC
URL: http://www.4over6.edu.cn/cuiyong/index.html


_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync


--047d7bacc66468a92f051eaf4323-- From nobody Tue Sep 1 19:25:36 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD311B3E81 for ; Tue, 1 Sep 2015 19:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4zGnoAzFqCR for ; Tue, 1 Sep 2015 19:25:32 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id E9C961B3CDD for ; Tue, 1 Sep 2015 19:25:29 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.148]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CpsJQUXuZVbCLABw--.9684S2; Wed, 02 Sep 2015 10:25:24 +0800 (CST) Date: Wed, 2 Sep 2015 10:25:08 +0800 From: "qinxiaowei@cnnic.cn" To: "Linhui Sun" References: <2015090116520811787510@cnnic.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <201509021025084691715@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart874642026833_=----" X-CM-TRANSID: AQAAf0CpsJQUXuZVbCLABw--.9684S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJw4UXr4ftr45GFWfXw1UJrb_yoW5ZF1DpF 43Jry3Gr4DJFW7Gw1kJF1j9r10yr1ktrWUKrnxJr18J345AFy0qr4xtr4rAryUJr95tw4Y qrnFgF15Gw18XFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUHmb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAa z4v26cxKscIFY7kG0wAqx4xG6xAIxVCFxsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzx vEb7x7Mc02F40Ex2IqxVA2YxCjr7Iv64kEw24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0E x4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4 xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lc2xSY4AK67AK6r4UMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU0 j0PDUUUUU== X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Cc: storagesync Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 02:25:35 -0000 This is a multi-part message in MIME format. ------=_001_NextPart874642026833_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 aGksDQpCZXNpZGVzICBvcHRpbWl6aW5nIHRoZSBzeW5jIHByb3RvY29sLCB3ZSBtYXkgY29uc2lk ZXIgdG8gYXZvaWQgdGhlIHRyYW5zbWlzc2lvbiBib3R0bGVuZWNrcyBleGlzdGluZyBpbiBsb25n IGludGVybmV0IGNvbW11bmljYXRpb24sIHN1Y2ggYXMgbGF0ZW5jeSwgcGFja2V0IGxvc3MsIG5l dHdvcmsgb3V0YWdlcywgaW5lZmZpY2llbnQgDQpwcm90b2NvbHMsIGFuZCBpbnRlci1uZXR3b3Jr IGZyaWN0aW9uLCBldGMuDQoNCnJlZ2FyZHMNClhpYW93ZWkgUWluDQoNCg0KDQogDQpGcm9tOiBM aW5odWkgU3VuDQpEYXRlOiAyMDE1LTA5LTAxIDIxOjA5DQpUbzogcWlueGlhb3dlaUBjbm5pYy5j bjsgc3RvcmFnZXN5bmMNClN1YmplY3Q6IFJlOiBbU3RvcmFnZXN5bmNdIFdlbGNvbWUgdG8gdGhl IERpc2N1c3Npb24gb24gSW50ZXJuZXQgU3RvcmFnZSBTeW5jDQpIaSBYaWFvd2VpLA0KDQpUaGFu a3MgZm9yIHNoYXJpbmcgeW91ciB0aG91Z2h0cy4gSSB0aGluayB0aGUgdGhpbmdzIHlvdSBtZW50 aW9uZWQgYXJlIG5vdCBjb25mbGljdGluZyB3aGVuIGNvbnNpZGVyaW5nIHRoZSBzdGFuZGFyZGl6 YXRpb24gb2Ygc3luYyBwcm90b2NvbC4gSWYgd2UgY291bGQgY29tZSB1cCB3aXRoIGFuIG9wZW4g YW5kIHN0YW5kYXJkIHN5bmMgcHJvdG9jb2wsIHRoZSB0aGlyZC1wYXJ0eSBBUElzIGNvdWxkIGJl IHNpZ25pZmljYW50bHkgc2ltcGxpZmllZC4gQW5kIGl0IGlzIHJlYXNvbmFibGUgYW5kIG5lY2Vz c2FyeSB0aGF0IHN1Y2ggc3RhbmRhcmQgc3luYyBwcm90b2NvbCBzaG91bGQgcGF5IG1vcmUgYXR0 ZW50aW9uIHRvIHRoZSBzeW5jIGVmZmljaWVuY3kgdG8gYWxsb3cgdXNlcnMgaGF2ZSBhbiBpZGVh bCB1cGxvYWQgcmF0ZS4NCg0KQW55IGNvbW1lbnRzPw0KDQpBY3R1YWxseSB3ZSBvdXRsaW5lIGZp dmUgZGlmZmVyZW50IHByb2JsZW1zIGluIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdC4gUHJv YmxlbSA0IGFuZCA1IHJldmVhbHMgd2h5IG1vc3QgZXhpc3RpbmcgcHJvcHJpZXRhcnkgc3luYyBw cm90b2NvbHMgZG8gbm90IGhhdmUgYSBzYXRpc2ZhY3Rvcnkgc3luYyBlZmZpY2llbmN5IChlLmcu IHBvb3IgcGVyZm9ybWFuY2Ugb24gdXBsb2FkIHJhdGUpLg0KDQoxKSBDb21wbGljYXRlZCBTdXBw b3J0IGZvciBBUElzDQoyKSBVbmF2YWlsYWJsZSBDcm9zcy1zZXJ2aWNlIFN5bmMNCjMpIFJlZHVu ZGFudCBTaW1pbGFyIENsaWVudHMNCjQpIERpZmZlcmVudCBDYXBhYmlsaXR5IENvbmZpZ3VyYXRp b25zIGFuZCBJbXBsZW1lbnRhdGlvbnMNCjUpIENoYWxsZW5nZXMgaW4gTW9iaWxlIGFuZCBXaXJl bGVzcyBFbnZpcm9ubWVudHMgDQooTW9yZSBkZXRhaWxlZCBkZXNjcmlwdGlvbnMgY291bGQgYmUg Zm91bmQgaW46IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY3VpLWlzcy1w cm9ibGVtLykNCg0KSW4gYWRkaXRpb24sIEkgdGhpbmsgdGhlIG1vc3QgdXJnZW50IHRhc2sgb2Yg dGhpcyBOb24tV0cgbGlzdCBpcyB0byBoYXZlIGFuIGFncmVlbWVudCBvbiB0aGUgc3BlY2lmaWVk IHByb2JsZW1zIGFuZCB0aGUgc2NvcGUgb2Ygd29yay4gVGh1cyBtYXkgSSBhc2sgdGhlIHBlb3Bs ZSBpbiB0aGlzIGxpc3QgdG8gc2hhcmUgeW91ciB0aG91Z2h0cyBvbiB0aGUgcHJvYmxlbXMgYW5k IHNjb3BlIG9mIHdvcms/IFdoaWNoIHByb2JsZW0gZG8geW91IHRoaW5rIGlzIG5vdCByZXF1aXJl ZCBvciBpcyB0aGVyZSBhbnkgb3RoZXIgcHJvYmxlbXMgd2UgaGF2ZW4ndCBtZW50aW9uZWQgaW4g dGhlIGRyYWZ0PyBQbGVhc2UgZmVlbCBmcmVlIHRvIGNvbW1lbnQgb24gaXQuDQoNCkJlc3QgcmVn YXJkcywNCkxpbmh1aQ0KDQoyMDE1LTA5LTAxIDE2OjUyIEdNVCswODowMCBxaW54aWFvd2VpQGNu bmljLmNuIDxxaW54aWFvd2VpQGNubmljLmNuPjoNCmhpLCANClRoaXJkLXBhcnR5IEFQSSBhbmQg b3B0aW1pemluZyB0aGUgc3luYyBwcm90b2NvbHMgbWF5IGJlIGltcG9ydGFudCBmb3IgT25saW5l IHN0b3JhZ2UuIEJ1dCwgSU1PLCB0aGUgbW9zdCBpbXBvcnRhbnQgaXMgaW1wcm92aW5nIGRhdGEg dXBsb2FkIHJhdGUgdGhhdCBlbmQgdXNlcnMgY2FuIG9idGFpbi4NCg0KDQoNCg0KDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkhpIGZvbGtzLApXZWxjb21lIHRvIHRoZSBtYWlsaW5nIGxpc3Qgb2Yg SW50ZXJuZXQgU3RvcmFnZSBTeW5jIChTdG9yYWdlc3luY0BpZXRmLm9yZykuIFRoaXMgbGlzdCBp cyBmb3IgdGhlIGRpc2N1c3Npb25zIG9mIEludGVybmV0IFN0b3JhZ2UgU3luYyB3b3JrLiBZb3Ug YXJlIHdlbGNvbWUgdG8gaW50cm9kdWNlIHlvdXJzZWxmIGhlcmUgYW5kIHN0YXJ0IHJlbGF0ZWQg ZGlzY3Vzc2lvbnMuCldlJ3ZlIHByb2R1Y2VkIGEgZHJhZnQgdG8gb3V0bGluZSB0aGUgbWFpbiBw cm9ibGVtcyBpbiBleGlzdGluZyBJbnRlcm5ldCBzdG9yYWdlIHNlcnZpY2VzLCBwbGVhc2UgZmlu ZCB0aGUgZG9jdW1lbnQgd2l0aCB0aGUgZm9sbG93aW5nIGxpbmsuIFBsZWFzZSBmZWVsIGZyZWUg dG8gY29tbWVudCBvbiBpdCBhbmQgeW91ciB2YWx1YWJsZSBjb21tZW50cyBhcmUgbW9yZSB0aGFu IHdlbGNvbWUuCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY3VpLWlzcy1w cm9ibGVtLwpBIHdpa2kgZm9yIHNvbWUgdXNlZnVsIHJlc291cmNlcyBhbmQgbGlua3MgY291bGQg YmUgZm91bmQuIFBsZWFzZSBmZWVsIGZyZWUgdG8gZWRpdCBpdCBvciBsZXQgdXMga25vdyBpZiB3 ZSd2ZSBtaXNzZWQgc29tZXRoaW5nLiAKaHR0cHM6Ly9naXRodWIuY29tL2lzcy1pZXRmL2lzcy93 aWtpL0ludGVybmV0LVN0b3JhZ2UtU3luYy8KUmVnYXJkcywKWW9uZyBDdWksClByb2Zlc3Nvciwg VHNpbmdodWEgVW5pdmVyc2l0eSwgQmVpamluZywgQ2hpbmEKQXNzb2NpYXRlIEVkaXRvciBvbiBJ RUVFIFRQRFMsIElFRUUgVENDClVSTDogaHR0cDovL3d3dy40b3ZlcjYuZWR1LmNuL2N1aXlvbmcv aW5kZXguaHRtbA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQpTdG9yYWdlc3luY0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KDQoN Cg== ------=_001_NextPart874642026833_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
= hi,
Besides  optimizing the sync protocol, we may consider to avoid the transmission bottlenecks existing in long internet communication, such as <= /span>latency, packet loss, network outages, inefficient =
protocols, and inter-network friction, etc.

regar= ds
Xiaowei Qin

=0A
=0A
 
Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Syn= c
Hi Xiaowei,

Thanks for sharing your thoughts. = I think the things you mentioned are not conflicting when considering the = standardization of sync protocol. If we could come up with an open and sta= ndard sync protocol, the third-party APIs could be significantly simplifie= d. And it is reasonable and necessary that such standard sync protocol sho= uld pay more attention to the sync efficiency to allow users have an ideal= upload rate.

Any comments?

<= div>Actually we outline five different problems in the problem statement d= raft. Problem 4 and 5 reveals why most existing proprietary sync protocols= do not have a satisfactory sync efficiency (e.g. poor performance on= upload rate).

1) Complicated Support for APIs=
2) Unavailable Cross-service Sync
= 3) Redundant Similar Clients
4) Different Capabili= ty Configurations and Implementations
5) Challenges i= n Mobile and Wireless Environments 
(More detailed = descriptions could be found in: http://datatracker.ietf.org/doc/draft-cui-is= s-problem/)

In addition, I think the most urg= ent task of this Non-WG list is to have an agreement on the specified prob= lems and the scope of work. Thus may I ask the people in this list to shar= e your thoughts on the problems and scope of work? Which problem do you th= ink is not required or is there any other problems we haven't mentioned in= the draft? Please feel free to comment on it.

Be= st regards,
Linhui

2015-09-01 16:52 GMT+08:00 qinxiaowei@cnnic.cn <qinxiaowei@cnnic.cn>:=
=0A
hi, 
= Third-party API and optimiz= ing the sync protocols may be important for Online storage. But, IMO, the = most important is improving data upload rate that end users can obtain.







----------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= ------------
Hi folks,=0AWelcome to the ma=
iling list of Internet Storage Sync (Storagesync@ietf.org). This list is for the discu=
ssions of Internet Storage Sync work. You are welcome to introduce yoursel=
f here and start related discussions.=0AWe've produced a draft to outline =
the main problems in existing Internet storage services, please find the d=
ocument with the following link. Please feel free to comment on it and you=
r valuable comments are more than welcome.=0Ahttp://datatracker=
.ietf.org/doc/draft-cui-iss-problem/=0AA wiki for some useful resource=
s and links could be found. Please feel free to edit it or let us know if =
we've missed something. =0Ahttps://github.com/iss-ietf/iss=
/wiki/Internet-Storage-Sync/=0ARegards,=0AYong Cui,=0AProfessor, Tsing=
hua University, Beijing, China=0AAssociate Editor on IEEE TPDS, IEEE TCC=
=0AURL: http://www.4over6.edu.cn/cuiyong/index.html
=0A
=0A
=0A

_____= __________________________________________
=0AStoragesync mailing list<= br>=0AStoragesync@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinfo/storages= ync
=0A

=0A=0A ------=_001_NextPart874642026833_=------ From nobody Tue Sep 1 19:53:46 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4449A1A6F62 for ; Tue, 1 Sep 2015 19:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so4d4EwRe8ZP for ; Tue, 1 Sep 2015 19:53:43 -0700 (PDT) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 366A11ACD38 for ; Tue, 1 Sep 2015 19:53:42 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_7013B1BF-5F9D-4A72-9ACB-EA98F4B7F169" From: Ted Lemon X-Priority: 3 In-Reply-To: <201509021025084691715@cnnic.cn> Date: Tue, 1 Sep 2015 22:53:30 -0400 Message-Id: <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> To: qinxiaowei@cnnic.cn X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Linhui Sun , storagesync Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 02:53:45 -0000 --Apple-Mail=_7013B1BF-5F9D-4A72-9ACB-EA98F4B7F169 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 1, 2015, at 10:25 PM, qinxiaowei@cnnic.cn = wrote: > Besides optimizing the sync protocol, we may consider to avoid the = transmission bottlenecks existing in long internet communication, such = as latency, packet loss, network outages, inefficient=20 > protocols, and inter-network friction, etc. Question: you say "optimizing the sync protocol," which sounds like = there is already a sync protocol. Is that true, or do you mean = optimizing the sync protocol after it=E2=80=99s been developed? I = haven=E2=80=99t seen any documents about a sync protocol yet. --Apple-Mail=_7013B1BF-5F9D-4A72-9ACB-EA98F4B7F169 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Sep 1, 2015, at 10:25 PM, qinxiaowei@cnnic.cn = wrote:
Besides  optimizing the sync = protocol, we may consider to avoid the transmission bottlenecks existing in long internet communication, such = as latency, packet loss, network = outages, inefficient 
protocols, and inter-network = friction, etc.

Question: you say "optimizing the sync protocol," which = sounds like there is already a sync protocol.   Is that true, or do = you mean optimizing the sync protocol after it=E2=80=99s been developed? =   I haven=E2=80=99t seen any documents about a sync protocol = yet.

= --Apple-Mail=_7013B1BF-5F9D-4A72-9ACB-EA98F4B7F169-- From nobody Tue Sep 1 19:56:20 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F45C1B3ABC for ; Tue, 1 Sep 2015 19:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NpE8fZ2sdkR for ; Tue, 1 Sep 2015 19:56:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA5D1B3ABB for ; Tue, 1 Sep 2015 19:56:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXA78944; Wed, 02 Sep 2015 02:56:12 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Sep 2015 03:56:09 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.99]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0235.001; Wed, 2 Sep 2015 10:56:01 +0800 From: "Songhaibin (A)" To: Ted Lemon , "qinxiaowei@cnnic.cn" Thread-Topic: [Storagesync] Welcome to the Discussion on Internet Storage Sync Thread-Index: AQHQ5JOQpy4QE+NnCk+ErAO3nI1O+p4nH5OAgAFkn/D//4GjAIAAhnIg Date: Wed, 2 Sep 2015 02:56:00 +0000 Message-ID: References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> In-Reply-To: <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.191] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F6534A7C8nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Linhui Sun , storagesync Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 02:56:19 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F6534A7C8nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SU1PLCBXZWJEQVYgY2FuIGJlIHNlZW4gYXMgdGhlIElFVEYgc3luYyBwcm90b2NvbCBmb3IgdmVy c2lvbiBtYW5hZ2VtZW50LiBJIGRvIG5vdCBrbm93IGlmIE5GUyBhbHNvIHN1cHBvcnRzIHN5bmMg b3Igbm90Lg0KDQpCZXN0IFJlZ2FyZHMhDQotSGFpYmluDQoNCkZyb206IFN0b3JhZ2VzeW5jIFtt YWlsdG86c3RvcmFnZXN5bmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1v bg0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDIsIDIwMTUgMTA6NTQgQU0NClRvOiBxaW54 aWFvd2VpQGNubmljLmNuDQpDYzogTGluaHVpIFN1bjsgc3RvcmFnZXN5bmMNClN1YmplY3Q6IFJl OiBbU3RvcmFnZXN5bmNdIFdlbGNvbWUgdG8gdGhlIERpc2N1c3Npb24gb24gSW50ZXJuZXQgU3Rv cmFnZSBTeW5jDQoNCk9uIFNlcCAxLCAyMDE1LCBhdCAxMDoyNSBQTSwgcWlueGlhb3dlaUBjbm5p Yy5jbjxtYWlsdG86cWlueGlhb3dlaUBjbm5pYy5jbj4gd3JvdGU6DQpCZXNpZGVzICBvcHRpbWl6 aW5nIHRoZSBzeW5jIHByb3RvY29sLCB3ZSBtYXkgY29uc2lkZXIgdG8gYXZvaWQgdGhlIHRyYW5z bWlzc2lvbiBib3R0bGVuZWNrcyBleGlzdGluZyBpbiBsb25nIGludGVybmV0IGNvbW11bmljYXRp b24sIHN1Y2ggYXMgbGF0ZW5jeSwgcGFja2V0IGxvc3MsIG5ldHdvcmsgb3V0YWdlcywgaW5lZmZp Y2llbnQNCnByb3RvY29scywgYW5kIGludGVyLW5ldHdvcmsgZnJpY3Rpb24sIGV0Yy4NCg0KUXVl c3Rpb246IHlvdSBzYXkgIm9wdGltaXppbmcgdGhlIHN5bmMgcHJvdG9jb2wsIiB3aGljaCBzb3Vu ZHMgbGlrZSB0aGVyZSBpcyBhbHJlYWR5IGEgc3luYyBwcm90b2NvbC4gICBJcyB0aGF0IHRydWUs IG9yIGRvIHlvdSBtZWFuIG9wdGltaXppbmcgdGhlIHN5bmMgcHJvdG9jb2wgYWZ0ZXIgaXTigJlz IGJlZW4gZGV2ZWxvcGVkPyAgIEkgaGF2ZW7igJl0IHNlZW4gYW55IGRvY3VtZW50cyBhYm91dCBh IHN5bmMgcHJvdG9jb2wgeWV0Lg0KDQo= --_000_E33E01DFD5BEA24B9F3F18671078951F6534A7C8nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovk vZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi50ZXh0Ymx1ZQ0K CXttc28tc3R5bGUtbmFtZTp0ZXh0X2JsdWU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTU8sIFdlYkRBViBjYW4g YmUgc2VlbiBhcyB0aGUgSUVURiBzeW5jIHByb3RvY29sIGZvciB2ZXJzaW9uIG1hbmFnZW1lbnQu IEkgZG8gbm90IGtub3cgaWYgTkZTIGFsc28gc3VwcG9ydHMgc3luYyBvciBub3QuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpq dXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1 c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tSGFpYmluPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3RvcmFnZXN5bmMgW21haWx0bzpzdG9yYWdlc3luYy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UZWQgTGVtb248YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDIsIDIwMTUgMTA6NTQgQU08YnI+DQo8Yj5Ubzo8 L2I+IHFpbnhpYW93ZWlAY25uaWMuY248YnI+DQo8Yj5DYzo8L2I+IExpbmh1aSBTdW47IHN0b3Jh Z2VzeW5jPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU3RvcmFnZXN5bmNdIFdlbGNvbWUgdG8g dGhlIERpc2N1c3Npb24gb24gSW50ZXJuZXQgU3RvcmFnZSBTeW5jPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+T24gU2VwIDEsIDIwMTUsIGF0IDEwOjI1IFBNLCA8YSBocmVmPSJt YWlsdG86cWlueGlhb3dlaUBjbm5pYy5jbiI+DQpxaW54aWFvd2VpQGNubmljLmNuPC9hPiB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS43NXB0Ij48c3BhbiBjbGFzcz0idGV4 dGJsdWUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmVz aWRlcyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwO29wdGltaXppbmcNCiB0aGUmbmJz cDtzeW5jIHByb3RvY29sLCB3ZSBtYXkgY29uc2lkZXIgdG8gYXZvaWQgdGhlIHRyYW5zbWlzc2lv biZuYnNwO2JvdHRsZW5lY2tzIGV4aXN0aW5nIGluIGxvbmcgaW50ZXJuZXQgY29tbXVuaWNhdGlv biwgc3VjaCBhcyZuYnNwO2xhdGVuY3ksIHBhY2tldCBsb3NzLCBuZXR3b3JrIG91dGFnZXMsIGlu ZWZmaWNpZW50Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnBy b3RvY29scywgYW5kIGludGVyLW5ldHdvcmsgZnJpY3Rpb24sIGV0Yy48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5RdWVzdGlvbjogeW91IHNheSAmcXVvdDtvcHRpbWl6aW5nIHRoZSBzeW5jIHBy b3RvY29sLCZxdW90OyB3aGljaCBzb3VuZHMgbGlrZSB0aGVyZSBpcyBhbHJlYWR5IGEgc3luYyBw cm90b2NvbC4gJm5ic3A7IElzIHRoYXQgdHJ1ZSwgb3IgZG8geW91IG1lYW4gb3B0aW1pemluZyB0 aGUgc3luYyBwcm90b2NvbCBhZnRlciBpdOKAmXMgYmVlbiBkZXZlbG9wZWQ/ICZuYnNwOyBJIGhh dmVu4oCZdCBzZWVuIGFueSBkb2N1bWVudHMNCiBhYm91dCBhIHN5bmMgcHJvdG9jb2wgeWV0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E33E01DFD5BEA24B9F3F18671078951F6534A7C8nkgeml501mbschi_-- From nobody Tue Sep 1 20:09:07 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5AF1B4210 for ; Tue, 1 Sep 2015 20:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.061 X-Spam-Level: *** X-Spam-Status: No, score=3.061 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_MISSP_FREEMAIL=0.001, FROM_MISSP_XPRIO=0.001, HTML_MESSAGE=0.001, RELAY_IS_220=2.118, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga5UsEejyOLT for ; Tue, 1 Sep 2015 20:09:04 -0700 (PDT) Received: from m15-219.126.com (m15-219.126.com [220.181.15.219]) by ietfa.amsl.com (Postfix) with ESMTP id 990E61B420B for ; Tue, 1 Sep 2015 20:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Message-ID:Subject:MIME-Version; bh=mBZ2x eglOM+lt2HdV7xa7XGQE803aPWwHRZdPMxAwQw=; b=IHUF8s6bwyDNldv+ICuRz u/1Hgo0W1lmrQ5jWlfj+fc+v7084iy5Cr3QMNM7hbD9qQE0O2dASEI6N0nbGsxCv UzJJtRt2Bpo40EZwNwiV7mjkBqCdNGbDpUBAM5TAHkibg036sF79YJ851s3B/VOR S42QFkxV8dIjQqG5G00t38= Received: from lilishan48$126.com ( [106.185.25.254] ) by ajax-webmail-sdy11 (Coremail) ; Wed, 2 Sep 2015 11:08:49 +0800 (GMT+08:00) Date: Wed, 2 Sep 2015 11:08:26 +0800 From: "lilishan48" To: "Songhaibin (A)", "Ted Lemon", "qinxiaowei@cnnic.cn" Message-ID: <1a97080f.20693e.14f8c074064.Coremail.lilishan48@126.com> In-Reply-To: References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="__=_Part_Boundary_006_031977.019900" X-Mailer: NetEase Flash Mail 2.4.0.11 X-Priority: 3 (Normal) X-Originating-IP: [106.185.25.254] X-CM-TRANSID: 5cqowAAHDoJCaOZVTsw7AA--.720W X-CM-SenderInfo: 5olox2hkdqkma6rslhhfrp/1tbiaRRpwU1sBB5d+QABsL X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: Cc: Linhui Sun , storagesync Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 03:09:06 -0000 --__=_Part_Boundary_006_031977.019900 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBIYWliaW4sDQoNCldlYkRBViAoV2ViLWJhc2VkIERpc3RyaWJ1dGVkIEF1dGhvcmluZyBh bmQgVmVyc2lvbmluZykgZXh0ZW5kcyB0aGUgSFRUUCBwcm90b2NvbCB0byBlbmFibGUgdXNlcnMg dG8gY29sbGFib3JhdGl2ZWx5IGVkaXQgYW5kIG1hbmFnZSBmaWxlcyBvbiB0aGUgcmVtb3RlIHdl YiBzZXJ2ZXJzLiBXZWJEQVYgbWFpbmx5IGZvY3VzZXMgb24gdGhlIGNvbGxhYm9yYXRpdmUgd29y ayBvbiBmaWxlcy4gSSB0aGluayB0aGUgSVNTIG1heSBoYW5kbGUgbGFyZ2UgZGF0YSBmaWxlcyBt b3JlIGZyZXF1ZW50bHkgYW5kIGZvY3VzIG1vcmUgb24gdGhlIHJlbW90ZSBkYXRhIHN5bmMgY2Fw YWJpbGl0eS4NCk5GUyAoTmV0d29yayBGaWxlIFN5c3RlbSkgaXMgc29tZSBraW5kIG9mIGRpc3Ry aWJ1dGVkIGZpbGUgc3lzdGVtIHRoYXQgZW5hYmxlcyB1c2VycyB0byBzdG9yZSBvciBhY2Nlc3Mg ZmlsZXMgb24gYSBuZXR3b3JrIGFzIGlzIHRoZXkgYXJlIG1hbmlwdWxhdGluZyBsb2NhbCBmaWxl cy4gTkZTIGlzIGp1c3QgYSBmaWxlIHN5c3RlbSB3aXRob3V0IGFueSB0cmFuc2ZlciBjYXBhYmls aXR5LCB0aHVzIGl0IG1ha2VzIHVzZSBvZiBSUEMgcHJvdG9jb2wgdG8gZnVsZmlsbCB0aGUgZmls ZSBzaGFyaW5nIHByb2Nlc3MuDQoNCkJlc3QgUmVnYXJkcywNCkxpc2hhbg0KDQoNCg0K5Y+R5Lu2 5Lq677yaIlNvbmdoYWliaW4gKEEpIiA8aGFpYmluLnNvbmdAaHVhd2VpLmNvbT4NCuWPkemAgeaX tumXtO+8mjIwMTUtMDktMDIgMTA6NTYNCuS4u+mimO+8mlJlOiBbU3RvcmFnZXN5bmNdIFdlbGNv bWUgdG8gdGhlIERpc2N1c3Npb24gb24gSW50ZXJuZXQgU3RvcmFnZSBTeW5jDQrmlLbku7bkurrv vJoiVGVkIExlbW9uIjxtZWxsb25AZnVndWUuY29tPiwicWlueGlhb3dlaUBjbm5pYy5jbiI8cWlu eGlhb3dlaUBjbm5pYy5jbj4NCuaKhOmAge+8miJMaW5odWkgU3VuIjxsaC5zdW5saW5oQGdtYWls LmNvbT4sInN0b3JhZ2VzeW5jIjxzdG9yYWdlc3luY0BpZXRmLm9yZz4NCg0KSU1PLCBXZWJEQVYg Y2FuIGJlIHNlZW4gYXMgdGhlIElFVEYgc3luYyBwcm90b2NvbCBmb3IgdmVyc2lvbiBtYW5hZ2Vt ZW50LiBJIGRvIG5vdCBrbm93IGlmIE5GUyBhbHNvIHN1cHBvcnRzIHN5bmMgb3Igbm90LiANCiAN CkJlc3QgUmVnYXJkcyENCi1IYWliaW4NCiANCkZyb206IFN0b3JhZ2VzeW5jIFttYWlsdG86c3Rv cmFnZXN5bmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KU2VudDog V2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDIsIDIwMTUgMTA6NTQgQU0NClRvOiBxaW54aWFvd2VpQGNu bmljLmNuDQpDYzogTGluaHVpIFN1bjsgc3RvcmFnZXN5bmMNClN1YmplY3Q6IFJlOiBbU3RvcmFn ZXN5bmNdIFdlbGNvbWUgdG8gdGhlIERpc2N1c3Npb24gb24gSW50ZXJuZXQgU3RvcmFnZSBTeW5j DQogDQpPbiBTZXAgMSwgMjAxNSwgYXQgMTA6MjUgUE0sIHFpbnhpYW93ZWlAY25uaWMuY24gd3Jv dGU6DQpCZXNpZGVzICBvcHRpbWl6aW5nIHRoZSBzeW5jIHByb3RvY29sLCB3ZSBtYXkgY29uc2lk ZXIgdG8gYXZvaWQgdGhlIHRyYW5zbWlzc2lvbiBib3R0bGVuZWNrcyBleGlzdGluZyBpbiBsb25n IGludGVybmV0IGNvbW11bmljYXRpb24sIHN1Y2ggYXMgbGF0ZW5jeSwgcGFja2V0IGxvc3MsIG5l dHdvcmsgb3V0YWdlcywgaW5lZmZpY2llbnQgDQpwcm90b2NvbHMsIGFuZCBpbnRlci1uZXR3b3Jr IGZyaWN0aW9uLCBldGMuDQogDQpRdWVzdGlvbjogeW91IHNheSAib3B0aW1pemluZyB0aGUgc3lu YyBwcm90b2NvbCwiIHdoaWNoIHNvdW5kcyBsaWtlIHRoZXJlIGlzIGFscmVhZHkgYSBzeW5jIHBy b3RvY29sLiAgIElzIHRoYXQgdHJ1ZSwgb3IgZG8geW91IG1lYW4gb3B0aW1pemluZyB0aGUgc3lu YyBwcm90b2NvbCBhZnRlciBpdOKAmXMgYmVlbiBkZXZlbG9wZWQ/ICAgSSBoYXZlbuKAmXQgc2Vl biBhbnkgZG9jdW1lbnRzIGFib3V0IGEgc3luYyBwcm90b2NvbCB5ZXQuDQog --__=_Part_Boundary_006_031977.019900 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptID0gDQoiaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIj48SEVBRD4NCjxNRVRBIGNvbnRl bnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8 TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwgMTEuMDAuOTYwMC4xNzk2MyI+DQo8 U1RZTEU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2T IjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk65b6u6L2v6ZuF6buROw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5b6u6L2v6ZuF6buRIjsNCglwYW5vc2UtMToyIDEx IDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnRleHRi bHVlDQoJe21zby1zdHlsZS1uYW1lOnRleHRfYmx1ZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv U1RZTEU+DQo8IS0tIGZsYXNobWFpbCBzdHlsZSBiZWdpbiAtLT4NCjxTVFlMRSB0eXBlPXRleHQv Y3NzPgpib2R5IHtib3JkZXItd2lkdGg6MDttYXJnaW46MH0KaW1nIHtib3JkZXI6MDttYXJnaW46 MDtwYWRkaW5nOjB9CjwvU1RZTEU+DQo8QkFTRSB0YXJnZXQ9X2JsYW5rPjwhLS0gZmxhc2htYWls IHN0eWxlIGVuZCAtLT48L0hFQUQ+DQo8Qk9EWSANCnN0eWxlPSJCT1JERVItTEVGVC1XSURUSDog MHB4OyBGT05ULVNJWkU6IDEwLjVwdDsgRk9OVC1GQU1JTFk6IOW+rui9r+mbhem7kTsgQk9SREVS LVJJR0hULVdJRFRIOiAwcHg7IEJPUkRFUi1CT1RUT00tV0lEVEg6IDBweDsgQ09MT1I6ICMwMDAw MDA7IE1BUkdJTjogMTJweDsgTElORS1IRUlHSFQ6IDEuNTsgQk9SREVSLVRPUC1XSURUSDogMHB4 IiANCm1hcmdpbmhlaWdodD0iMCIgbWFyZ2lud2lkdGg9IjAiPg0KPERJVj5EZWFyIEhhaWJpbiw8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPldlYkRBViAoV2ViLWJhc2VkIERpc3RyaWJ1 dGVkIEF1dGhvcmluZyBhbmQgVmVyc2lvbmluZykgZXh0ZW5kcyB0aGUgSFRUUCANCnByb3RvY29s IHRvIGVuYWJsZSB1c2VycyB0byBjb2xsYWJvcmF0aXZlbHkgZWRpdCBhbmQgbWFuYWdlIGZpbGVz IG9uIHRoZSByZW1vdGUgDQp3ZWIgc2VydmVycy4gV2ViREFWIG1haW5seSBmb2N1c2VzIG9uIHRo ZSBjb2xsYWJvcmF0aXZlIHdvcmsgb24gZmlsZXMuIEkgdGhpbmsgDQp0aGUgSVNTIG1heSBoYW5k bGUgbGFyZ2UgZGF0YSBmaWxlcyBtb3JlIGZyZXF1ZW50bHkgYW5kIGZvY3VzIG1vcmUgb24gdGhl IHJlbW90ZSANCmRhdGEgc3luYyBjYXBhYmlsaXR5LjxCUj5ORlMgKE5ldHdvcmsgRmlsZSBTeXN0 ZW0pIGlzIHNvbWUga2luZCBvZiBkaXN0cmlidXRlZCANCmZpbGUgc3lzdGVtIHRoYXQgZW5hYmxl cyB1c2VycyB0byBzdG9yZSBvciBhY2Nlc3MgZmlsZXMgb24gYSBuZXR3b3JrIGFzIGlzIHRoZXkg DQphcmUgbWFuaXB1bGF0aW5nIGxvY2FsIGZpbGVzLiBORlMgaXMganVzdCBhIGZpbGUgc3lzdGVt IHdpdGhvdXQgYW55IHRyYW5zZmVyIA0KY2FwYWJpbGl0eSwgdGh1cyBpdCBtYWtlcyB1c2Ugb2Yg UlBDIHByb3RvY29sIHRvIGZ1bGZpbGwgdGhlIGZpbGUgc2hhcmluZyANCnByb2Nlc3MuPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5CZXN0IFJlZ2FyZHMsPC9ESVY+DQo8RElWPkxpc2hh bjwvRElWPg0KPEhSIA0Kc3R5bGU9IkJPUkRFUi1UT1A6ICNjMGMwYzAgMXB4IHNvbGlkOyBIRUlH SFQ6IDFweDsgQk9SREVSLVJJR0hUOiAwcHg7IEJPUkRFUi1CT1RUT006IDBweDsgQk9SREVSLUxF RlQ6IDBweCI+DQoNCjxESVYgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFZl cmRhbmEiPg0KPERJVj48U1RST05HPuWPkeS7tuS6uu+8mjwvU1RST05HPiJTb25naGFpYmluIChB KSIgJmx0O2hhaWJpbi5zb25nQGh1YXdlaS5jb20mZ3Q7PC9ESVY+DQo8RElWPjxTVFJPTkc+5Y+R 6YCB5pe26Ze077yaPC9TVFJPTkc+MjAxNS0wOS0wMiZuYnNwOzEwOjU2PC9ESVY+DQo8RElWPjxT VFJPTkc+5Li76aKY77yaPC9TVFJPTkc+UmU6IFtTdG9yYWdlc3luY10gV2VsY29tZSB0byB0aGUg RGlzY3Vzc2lvbiBvbiBJbnRlcm5ldCANClN0b3JhZ2UgU3luYzwvRElWPg0KPERJVj48U1RST05H PuaUtuS7tuS6uu+8mjwvU1RST05HPiJUZWQgDQpMZW1vbiImbHQ7bWVsbG9uQGZ1Z3VlLmNvbSZn dDssInFpbnhpYW93ZWlAY25uaWMuY24iJmx0O3FpbnhpYW93ZWlAY25uaWMuY24mZ3Q7PC9ESVY+ DQo8RElWPjxTVFJPTkc+5oqE6YCB77yaPC9TVFJPTkc+Ikxpbmh1aSANClN1biImbHQ7bGguc3Vu bGluaEBnbWFpbC5jb20mZ3Q7LCJzdG9yYWdlc3luYyImbHQ7c3RvcmFnZXN5bmNAaWV0Zi5vcmcm Z3Q7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4NCjxESVYgY2xhc3M9V29yZFNlY3Rp b24xPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0nRk9OVC1T SVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBDT0xPUjog IzFmNDk3ZCc+SU1PLCANCldlYkRBViBjYW4gYmUgc2VlbiBhcyB0aGUgSUVURiBzeW5jIHByb3Rv Y29sIGZvciB2ZXJzaW9uIG1hbmFnZW1lbnQuIEkgZG8gbm90IA0Ka25vdyBpZiBORlMgYWxzbyBz dXBwb3J0cyBzeW5jIG9yIG5vdC4gPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0nRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQt RkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBDT0xPUjogIzFmNDk3ZCc+PG86cD4mbmJz cDs8L286cD48L1NQQU4+PC9QPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJU RVhULUFMSUdOOiBqdXN0aWZ5OyBURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaCI+PFNQQU4g bGFuZz1FTi1VUyANCnN0eWxlPSdGT05ULVNJWkU6IDEwLjVwdDsgRk9OVC1GQU1JTFk6ICJDYWxp YnJpIiwic2Fucy1zZXJpZiI7IENPTE9SOiAjMWY0OTdkJz5CZXN0IA0KUmVnYXJkcyE8bzpwPjwv bzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iVEVYVC1BTElHTjog anVzdGlmeTsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgiPjxTUEFOIGxhbmc9RU4tVVMg DQpzdHlsZT0nRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOyBDT0xPUjogIzFmNDk3ZCc+LUhhaWJpbjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJ Vj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9J0ZPTlQtU0la RTogMTAuNXB0OyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgQ09MT1I6ICMx ZjQ5N2QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxESVYgDQpzdHlsZT0iQk9SREVS LVRPUDogbWVkaXVtIG5vbmU7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IEJPUkRFUi1CT1RU T006IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5HLVRPUDogMGNtOyBQ QURESU5HLUxFRlQ6IDRwdDsgQk9SREVSLUxFRlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkct UklHSFQ6IDBjbSI+DQo8RElWPg0KPERJViANCnN0eWxlPSJCT1JERVItVE9QOiAjYjVjNGRmIDFw dCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgQk9SREVSLUJPVFRPTTogbWVkaXVt IG5vbmU7IFBBRERJTkctQk9UVE9NOiAwY207IFBBRERJTkctVE9QOiAzcHQ7IFBBRERJTkctTEVG VDogMGNtOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBjbSI+DQo8 UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSdGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiAiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9TUEFOPjwv Qj48U1BBTiANCmxhbmc9RU4tVVMgc3R5bGU9J0ZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 ICJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IA0KU3RvcmFnZXN5bmMgW21haWx0bzpzdG9yYWdlc3lu Yy1ib3VuY2VzQGlldGYub3JnXSA8Qj5PbiBCZWhhbGYgT2YgPC9CPlRlZCANCkxlbW9uPEJSPjxC PlNlbnQ6PC9CPiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNSAxMDo1NCBBTTxCUj48Qj5U bzo8L0I+IA0KcWlueGlhb3dlaUBjbm5pYy5jbjxCUj48Qj5DYzo8L0I+IExpbmh1aSBTdW47IHN0 b3JhZ2VzeW5jPEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogDQpbU3RvcmFnZXN5bmNdIFdlbGNvbWUg dG8gdGhlIERpc2N1c3Npb24gb24gSW50ZXJuZXQgU3RvcmFnZSANClN5bmM8bzpwPjwvbzpwPjwv U1BBTj48L1A+PC9ESVY+PC9ESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1V Uz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g bGFuZz1FTi1VUz5PbiBTZXAgMSwgMjAxNSwgYXQgMTA6MjUgUE0sIDxBIA0KaHJlZj0ibWFpbHRv OnFpbnhpYW93ZWlAY25uaWMuY24iPnFpbnhpYW93ZWlAY25uaWMuY248L0E+IA0Kd3JvdGU6PG86 cD48L286cD48L1NQQU4+PC9QPg0KPERJVj4NCjxCTE9DS1FVT1RFIHN0eWxlPSJNQVJHSU4tQk9U VE9NOiA1cHQ7IE1BUkdJTi1UT1A6IDVwdCI+DQogIDxESVY+DQogIDxESVY+DQogIDxQIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1Ljc1cHQiPjxTUEFOIGNsYXNzPXRleHRi bHVlPjxTUEFOIA0KICBsYW5nPUVOLVVTIA0KICBzdHlsZT0nRk9OVC1TSVpFOiAxMC41cHQ7IEZP TlQtRkFNSUxZOiAi5b6u6L2v6ZuF6buRIiwic2Fucy1zZXJpZiInPkJlc2lkZXMmbmJzcDs8L1NQ QU4+PC9TUEFOPjxTUEFOIA0KICBsYW5nPUVOLVVTIA0KICBzdHlsZT0nRk9OVC1TSVpFOiAxMC41 cHQ7IEZPTlQtRkFNSUxZOiAi5b6u6L2v6ZuF6buRIiwic2Fucy1zZXJpZiI7IEJBQ0tHUk9VTkQ6 IHdoaXRlJz4mbmJzcDtvcHRpbWl6aW5nIA0KICB0aGUmbmJzcDtzeW5jIHByb3RvY29sLCB3ZSBt YXkgY29uc2lkZXIgdG8gYXZvaWQgdGhlIA0KICB0cmFuc21pc3Npb24mbmJzcDtib3R0bGVuZWNr cyBleGlzdGluZyBpbiBsb25nIGludGVybmV0IGNvbW11bmljYXRpb24sIHN1Y2ggDQogIGFzJm5i c3A7bGF0ZW5jeSwgcGFja2V0IGxvc3MsIG5ldHdvcmsgb3V0YWdlcywgaW5lZmZpY2llbnQmbmJz cDs8L1NQQU4+PFNQQU4gDQogIGxhbmc9RU4tVVMgDQogIHN0eWxlPSdGT05ULVNJWkU6IDEwLjVw dDsgRk9OVC1GQU1JTFk6ICLlvq7ova/pm4Xpu5EiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48 L1NQQU4+PC9QPjwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyAN CiAgc3R5bGU9J0ZPTlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogIuW+rui9r+mbhem7kSIs InNhbnMtc2VyaWYiJz5wcm90b2NvbHMsIGFuZCANCiAgaW50ZXItbmV0d29yayBmcmljdGlvbiwg ZXRjLjwvU1BBTj48U1BBTiANCiAgbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9E SVY+PC9CTE9DS1FVT1RFPjwvRElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4t VVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1h bD48U1BBTiBsYW5nPUVOLVVTPlF1ZXN0aW9uOiB5b3Ugc2F5ICJvcHRpbWl6aW5nIHRoZSBzeW5j IA0KcHJvdG9jb2wsIiB3aGljaCBzb3VuZHMgbGlrZSB0aGVyZSBpcyBhbHJlYWR5IGEgc3luYyBw cm90b2NvbC4gJm5ic3A7IElzIHRoYXQgDQp0cnVlLCBvciBkbyB5b3UgbWVhbiBvcHRpbWl6aW5n IHRoZSBzeW5jIHByb3RvY29sIGFmdGVyIGl04oCZcyBiZWVuIGRldmVsb3BlZD8gDQombmJzcDsg SSBoYXZlbuKAmXQgc2VlbiBhbnkgZG9jdW1lbnRzIGFib3V0IGEgc3luYyBwcm90b2NvbCANCnll dC48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIA0KbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+PC9ESVY+PC9E SVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CT0RZPjwvSFRNTD4= --__=_Part_Boundary_006_031977.019900-- From nobody Tue Sep 1 20:25:40 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603761B2B51 for ; Tue, 1 Sep 2015 20:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BNYirrMBqHb for ; Tue, 1 Sep 2015 20:25:36 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id AF69F1AD0A8 for ; Tue, 1 Sep 2015 20:25:34 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.148]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CJtnEgbOZVzyXABw--.24190S2; Wed, 02 Sep 2015 11:25:20 +0800 (CST) Date: Wed, 2 Sep 2015 11:25:04 +0800 From: "qinxiaowei@cnnic.cn" To: lilishan48 , "Songhaibin (A)" , "Ted Lemon" References: <2015090116520811787510@cnnic.cn>, , <201509021025084691715@cnnic.cn>, <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com>, <1a97080f.20693e.14f8c074064.Coremail.lilishan48@126.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2015090211250464068219@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart042661300487_=----" X-CM-TRANSID: AQAAf0CJtnEgbOZVzyXABw--.24190S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCFy3Xry7Cw1rAFy8Gry5CFg_yoW5XFWrpF WUJr9xK3ykWF429w1vyr1IvF4ruwn5Jw47JF9Fqwn3J3sxKF90gFyjqr1UWa4fJ392qa1F vr4Fva4ayw4qqaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUJIb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2 x7xS6r1j6r4UMc02F40En4AKxVAvwIkv4cxYr24l5I8CrVAqjxCE14ACF2xKxwAqx4xG64 kEw2xG04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24l5I8CrVC2j2CEjI02ccxYII8I67AE r4CY67k08wAqx4xG6I8I3I0E8cIF7480aVAKz4kxMcIj6xIIjxv20xvE14v26r1j6r18Mc Ij6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l FcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07Mx8GjcxK6IxK0xIIj40E5I 8CrwCY02Avz4vE14v_Gr4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l x2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14 v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IY x2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I 8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAx ZFUvcSsGvfC2KfnxnUUI43ZEXa7IU0JPEPUUUUU== X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Cc: Linhui Sun , storagesync Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 03:25:38 -0000 This is a multi-part message in MIME format. ------=_001_NextPart042661300487_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 aGksTGlzaGFuDQoNCj4+Pj4+Pj5JIHRoaW5rIHRoZSBJU1MgbWF5IGhhbmRsZSBsYXJnZSBkYXRh IGZpbGVzIG1vcmUgZnJlcXVlbnRseSBhbmQgZm9jdXMgbW9yZSBvbiB0aGUgcmVtb3RlIGRhdGEg c3luYyBjYXBhYmlsaXR5Lg0KDQpJIGFncmVlIHdpdGggeW91LiAgSVNTIG1heSBmb2N1cyBvbiBs YXJnZSBjb250ZW50IGRlbGl2ZXIsIGVzcGVjaWFsbHkgdXBzdHJlYW0gdHJhZmZpYyBnZW5lcmF0 ZWQgYnkgZW5kIHVzZXJzLg0KVW5mb3J0dW5hdGVseSwgaW5oZXJlbnQgbGltaXRhdGlvbnMgaW4g dGhlIEludGVybmV04oCYcyBhcmNoaXRlY3R1cmUgbWFrZSBpdCBkaWZmaWN1bHQgdG8gYWNoaWV2 ZSBkZXNpcmVkIGxldmVscyBvZiBwZXJmb3JtYW5jZSBuYXRpdmVseSBvbiB0aGUgSW50ZXJuZXQu IERlc2lnbmVkIGFzIGEgYmVzdC1lZmZvcnQgbmV0d29yaywgdGhlIEludGVybmV0IHByb3ZpZGVz IG5vIGd1YXJhbnRlZXMgb24gZW5kLXRvLWVuZCByZWxpYWJpbGl0eSBvciBwZXJmb3JtYW5jZS4g DQpTbywgSU1PLCBmb3IgbWF4aW1pemluZyB1cHN0cmVhbSB0aHJvdWdocHV0LCAgbW92aW5nICJ0 aGUgZGVzdGluYXRpb24iIGNsb3NlciB0byB0aGUgZW5kIHVzZXIgbWF5IGJlbmVmaXQgdG8gcHJl LXVwbG9hZGVkIGNvbnRlbnQsIGxpa2UgQ0ROLg0KDQoNCg0KDQogDQpGcm9tOiBsaWxpc2hhbjQ4 DQpEYXRlOiAyMDE1LTA5LTAyIDExOjA4DQpUbzogU29uZ2hhaWJpbiAoQSk7IFRlZCBMZW1vbjsg cWlueGlhb3dlaUBjbm5pYy5jbg0KQ0M6IExpbmh1aSBTdW47IHN0b3JhZ2VzeW5jDQpTdWJqZWN0 OiBSZTogUmU6IFtTdG9yYWdlc3luY10gV2VsY29tZSB0byB0aGUgRGlzY3Vzc2lvbiBvbiBJbnRl cm5ldCBTdG9yYWdlIFN5bmMNCkRlYXIgSGFpYmluLA0KIA0KV2ViREFWIChXZWItYmFzZWQgRGlz dHJpYnV0ZWQgQXV0aG9yaW5nIGFuZCBWZXJzaW9uaW5nKSBleHRlbmRzIHRoZSBIVFRQIHByb3Rv Y29sIHRvIGVuYWJsZSB1c2VycyB0byBjb2xsYWJvcmF0aXZlbHkgZWRpdCBhbmQgbWFuYWdlIGZp bGVzIG9uIHRoZSByZW1vdGUgd2ViIHNlcnZlcnMuIFdlYkRBViBtYWlubHkgZm9jdXNlcyBvbiB0 aGUgY29sbGFib3JhdGl2ZSB3b3JrIG9uIGZpbGVzLiBJIHRoaW5rIHRoZSBJU1MgbWF5IGhhbmRs ZSBsYXJnZSBkYXRhIGZpbGVzIG1vcmUgZnJlcXVlbnRseSBhbmQgZm9jdXMgbW9yZSBvbiB0aGUg cmVtb3RlIGRhdGEgc3luYyBjYXBhYmlsaXR5Lg0KTkZTIChOZXR3b3JrIEZpbGUgU3lzdGVtKSBp cyBzb21lIGtpbmQgb2YgZGlzdHJpYnV0ZWQgZmlsZSBzeXN0ZW0gdGhhdCBlbmFibGVzIHVzZXJz IHRvIHN0b3JlIG9yIGFjY2VzcyBmaWxlcyBvbiBhIG5ldHdvcmsgYXMgaXMgdGhleSBhcmUgbWFu aXB1bGF0aW5nIGxvY2FsIGZpbGVzLiBORlMgaXMganVzdCBhIGZpbGUgc3lzdGVtIHdpdGhvdXQg YW55IHRyYW5zZmVyIGNhcGFiaWxpdHksIHRodXMgaXQgbWFrZXMgdXNlIG9mIFJQQyBwcm90b2Nv bCB0byBmdWxmaWxsIHRoZSBmaWxlIHNoYXJpbmcgcHJvY2Vzcy4NCiANCkJlc3QgUmVnYXJkcywN Ckxpc2hhbg0KDQoNCuWPkeS7tuS6uu+8miJTb25naGFpYmluIChBKSIgPGhhaWJpbi5zb25nQGh1 YXdlaS5jb20+DQrlj5HpgIHml7bpl7TvvJoyMDE1LTA5LTAyIDEwOjU2DQrkuLvpopjvvJpSZTog W1N0b3JhZ2VzeW5jXSBXZWxjb21lIHRvIHRoZSBEaXNjdXNzaW9uIG9uIEludGVybmV0IFN0b3Jh Z2UgU3luYw0K5pS25Lu25Lq677yaIlRlZCBMZW1vbiI8bWVsbG9uQGZ1Z3VlLmNvbT4sInFpbnhp YW93ZWlAY25uaWMuY24iPHFpbnhpYW93ZWlAY25uaWMuY24+DQrmioTpgIHvvJoiTGluaHVpIFN1 biI8bGguc3VubGluaEBnbWFpbC5jb20+LCJzdG9yYWdlc3luYyI8c3RvcmFnZXN5bmNAaWV0Zi5v cmc+DQogDQpJTU8sIFdlYkRBViBjYW4gYmUgc2VlbiBhcyB0aGUgSUVURiBzeW5jIHByb3RvY29s IGZvciB2ZXJzaW9uIG1hbmFnZW1lbnQuIEkgZG8gbm90IGtub3cgaWYgTkZTIGFsc28gc3VwcG9y dHMgc3luYyBvciBub3QuIA0KIA0KQmVzdCBSZWdhcmRzIQ0KLUhhaWJpbg0KIA0KRnJvbTogU3Rv cmFnZXN5bmMgW21haWx0bzpzdG9yYWdlc3luYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgVGVkIExlbW9uDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNSAxMDo1NCBB TQ0KVG86IHFpbnhpYW93ZWlAY25uaWMuY24NCkNjOiBMaW5odWkgU3VuOyBzdG9yYWdlc3luYw0K U3ViamVjdDogUmU6IFtTdG9yYWdlc3luY10gV2VsY29tZSB0byB0aGUgRGlzY3Vzc2lvbiBvbiBJ bnRlcm5ldCBTdG9yYWdlIFN5bmMNCiANCk9uIFNlcCAxLCAyMDE1LCBhdCAxMDoyNSBQTSwgcWlu eGlhb3dlaUBjbm5pYy5jbiB3cm90ZToNCkJlc2lkZXMgIG9wdGltaXppbmcgdGhlIHN5bmMgcHJv dG9jb2wsIHdlIG1heSBjb25zaWRlciB0byBhdm9pZCB0aGUgdHJhbnNtaXNzaW9uIGJvdHRsZW5l Y2tzIGV4aXN0aW5nIGluIGxvbmcgaW50ZXJuZXQgY29tbXVuaWNhdGlvbiwgc3VjaCBhcyBsYXRl bmN5LCBwYWNrZXQgbG9zcywgbmV0d29yayBvdXRhZ2VzLCBpbmVmZmljaWVudCANCnByb3RvY29s cywgYW5kIGludGVyLW5ldHdvcmsgZnJpY3Rpb24sIGV0Yy4NCiANClF1ZXN0aW9uOiB5b3Ugc2F5 ICJvcHRpbWl6aW5nIHRoZSBzeW5jIHByb3RvY29sLCIgd2hpY2ggc291bmRzIGxpa2UgdGhlcmUg aXMgYWxyZWFkeSBhIHN5bmMgcHJvdG9jb2wuICAgSXMgdGhhdCB0cnVlLCBvciBkbyB5b3UgbWVh biBvcHRpbWl6aW5nIHRoZSBzeW5jIHByb3RvY29sIGFmdGVyIGl04oCZcyBiZWVuIGRldmVsb3Bl ZD8gICBJIGhhdmVu4oCZdCBzZWVuIGFueSBkb2N1bWVudHMgYWJvdXQgYSBzeW5jIHByb3RvY29s IHlldC4NCiANCg== ------=_001_NextPart042661300487_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A=0A=0A
hi,Lish= an

>>>>>>>I think the= ISS may handle large data files more frequently and focus more on the rem= ote data sync capability.

I a= gree with you.  ISS may focus on large content deliver,&n= bsp;especially upstream traffic generated by end users.=
Unfortunately, inherent limitations in the Internet=E2=80=98s a= rchitecture=0Amake it difficult to achieve desired levels of performance n= atively=0Aon the Internet. Designed as a best-effort n= etwork, the Internet provides no guarantees on end-to-end reliability or p= erformance. 
So, I= MO, for maximizing upstream = throughput,  moving "the destination" closer to the end user may benefit to pre-uploaded content, like CDN.

=0A

=0A
= =0A
 
From: <= a href=3D"mailto:lilishan48@126.com" style=3D"color: blue; text-decoration= : underline;">lilishan48
Date: 2015-09-02 1= 1:08
Subject: Re: Re: [Storagesync] Welcome to t= he Discussion on Internet Storage Sync
=0A=0A=0A
Dear Haibin,
=0A 
=0A
WebDAV (Web-based Distributed Authoring and Version= ing) extends the HTTP =0Aprotocol to enable users to collaboratively edit = and manage files on the remote =0Aweb servers. WebDAV mainly focuses on th= e collaborative work on files. I think =0Athe ISS may handle large data fi= les more frequently and focus more on the remote =0Adata sync capability.<= br>NFS (Network File System) is some kind of distributed =0Afile system th= at enables users to store or access files on a network as is they =0Aare m= anipulating local files. NFS is just a file system without any transfer = =0Acapability, thus it makes use of RPC protocol to fulfill the file shari= ng =0Aprocess.
=0A
 
=0A
Best Regards,
=0ALishan
=0A
=0A
=0A
=E5=8F=91=E4=BB=B6= =E4=BA=BA=EF=BC=9A"Songhaibin (A)" <haibin.song@huawei.com>=
=0A
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2015-09-02 10:56
=0A
=E4=B8=BB=E9=A2=98=EF=BC=9ARe: [Storagesync] Welcome to the Discussion on Internet =0AStorage = Sync
=0A
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A"Te= d =0ALemon"<mellon@fugue.com>,"qinxiaowei@cnnic.cn"<qinxiaowei@cn= nic.cn>
=0A
=E6=8A=84=E9=80=81=EF=BC=9A"Linhu= i =0ASun"<lh.sunlinh@gmail.com>,"storagesync"<storagesync@ietf.or= g>
=0A
 
=0A
=0A
=0A

IMO, =0AWebDAV can be seen as the IE= TF sync protocol for version management. I do not =0Aknow if NFS also supp= orts sync or not.

=0A

 

=0A
=0A

Best =0ARegards!

=0A

-Haibin

=0A

 

=0A
=0A
=0A
=0A

From: =0AStora= gesync [mailto:storagesync-bounces@ietf.org] On Behalf Of Ted =0ALe= mon
Sent: Wednesday, September 02, 2015 10:54 AM
To: = =0Aqinxiaowei@cnnic.cn
Cc: Linhui Sun; storagesync
Subject= : Re: =0A[Storagesync] Welcome to the Discussion on Internet Storage = =0ASync

=0A

 

=0A

On Sep 1, 2015, at 10:25 PM, qinxiaowei@cnnic.cn =0Awrote:

=0A=0A
=0A =0A
=0A

<= span class=3D"textblue">Besides  optimizing =0A the = ;sync protocol, we may consider to avoid the =0A transmission bottle= necks existing in long internet communication, such =0A as latency, = packet loss, network outages, inefficient 

=0A=

protocols, and =0A inter-network friction, etc.

= =0A

 

=0A
=0A

Question: you say "optimizing the sync =0Aprotocol," which sounds li= ke there is already a sync protocol.   Is that =0Atrue, or do you mea= n optimizing the sync protocol after it=E2=80=99s been developed? =0A = ; I haven=E2=80=99t seen any documents about a sync protocol =0Ayet.<= /o:p>

=0A
=0A

 

<= /div>=0A ------=_001_NextPart042661300487_=------ From nobody Wed Sep 2 04:40:40 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94A41B30EE for ; Wed, 2 Sep 2015 04:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tgn6Yngr8T9s for ; Wed, 2 Sep 2015 04:40:38 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B161B30DB for ; Wed, 2 Sep 2015 04:40:37 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so15888876wic.0 for ; Wed, 02 Sep 2015 04:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XLI+T/3GX/yl3DCW5NEoukEMDA5vChRbeixGkZOuhL8=; b=keX3X8s8x5kSHhooUI8XxrvfyrYuQnt/u/VqGe0W2txIJ42iY5QxTAyclqWaac+Ufv 7vy2c6WS8qdrfBv06vca2jQDONXYq/lsjwGiUYs0a0ubx5xkBdA2ld10RM6ESYWdxFEG mzGAa2eF1YF+YQq6WW/A03u5nsbcqInh+PxIIpZguCtc+ARGmdBAtZP65+3gLJOkDK1W FGyGpwBzxHits5PPpJqH4DjYz7hYrllnGg7IyRBQgWI5XSvRXYedPXCqTyexmTwfpXvV x5PLBIgC7L96JT9ew1qrR6u3cj+sAaaCt7IJ8R/bcaXky7G4k7udk4aTzsBGRzHzWqFN 2gcw== X-Received: by 10.180.198.145 with SMTP id jc17mr3289251wic.37.1441194036497; Wed, 02 Sep 2015 04:40:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.22.209 with HTTP; Wed, 2 Sep 2015 04:40:17 -0700 (PDT) In-Reply-To: References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> From: Linhui Sun Date: Wed, 2 Sep 2015 19:40:17 +0800 Message-ID: To: "Songhaibin (A)" Content-Type: multipart/alternative; boundary=047d7b6223269913f6051ec22277 Archived-At: Cc: storagesync , Ted Lemon , "qinxiaowei@cnnic.cn" Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 11:40:40 -0000 --047d7b6223269913f6051ec22277 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think maybe we should make the definition of sync clearer. Could we explain it as a simple upload/download process. Or the sync is specifically referred to the transfer process of Network-based storage services which may employ several well-known techniques (e.g. rsync)? Best regards, Linhui 2015-09-02 10:56 GMT+08:00 Songhaibin (A) : > IMO, WebDAV can be seen as the IETF sync protocol for version management. > I do not know if NFS also supports sync or not. > > > > Best Regards! > > -Haibin > > > > *From:* Storagesync [mailto:storagesync-bounces@ietf.org] *On Behalf Of *= Ted > Lemon > *Sent:* Wednesday, September 02, 2015 10:54 AM > *To:* qinxiaowei@cnnic.cn > *Cc:* Linhui Sun; storagesync > *Subject:* Re: [Storagesync] Welcome to the Discussion on Internet > Storage Sync > > > > On Sep 1, 2015, at 10:25 PM, qinxiaowei@cnnic.cn wrote: > > Besides optimizing the sync protocol, we may consider to avoid the > transmission bottlenecks existing in long internet communication, such > as latency, packet loss, network outages, inefficient > > protocols, and inter-network friction, etc. > > > > Question: you say "optimizing the sync protocol," which sounds like there > is already a sync protocol. Is that true, or do you mean optimizing the > sync protocol after it=E2=80=99s been developed? I haven=E2=80=99t seen= any documents > about a sync protocol yet. > > > --047d7b6223269913f6051ec22277 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think maybe we should make the definition of sync c= learer. Could we explain it as a simple upload/download process. Or the syn= c is specifically referred to the transfer process of=C2=A0Network-based st= orage services which may employ several well-known techniques (e.g. rsync)?=

Best regards,
Linhui

2015-09-02 10:56 GMT+08:00= Songhaibin (A) <haibin.song@huawei.com>:

IMO, WebDA= V can be seen as the IETF sync protocol for version management. I do not kn= ow if NFS also supports sync or not.

=C2= =A0

Best Regards!=

-Haibin

=C2= =A0

From: Storagesync [mailto:storagesync-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Wednesday, September 02, 2015 10:54 AM
To: qinxiao= wei@cnnic.cn
Cc: Linhui Sun; storagesync
Subject: Re: [Storagesync] Welcome to the Discussion on Internet Sto= rage Sync

=C2=A0

On Sep 1, 2015, at 10:25 PM, qinxiaowei@cnnic.cn wrote:

Besides=C2=A0=C2=A0optimizing the=C2=A0sync protocol, we may consider to avoid the transmission=C2=A0bot= tlenecks existing in long internet communication, such as=C2=A0latency, pac= ket loss, network outages, inefficient=C2=A0

pro= tocols, and inter-network friction, etc.=

=C2=A0

Question: you say "optimiz= ing the sync protocol," which sounds like there is already a sync prot= ocol. =C2=A0 Is that true, or do you mean optimizing the sync protocol afte= r it=E2=80=99s been developed? =C2=A0 I haven=E2=80=99t seen any documents about a sync protocol yet.

=C2=A0


--047d7b6223269913f6051ec22277-- From nobody Wed Sep 2 05:08:07 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA3B1A894E for ; Wed, 2 Sep 2015 05:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dNwQp9hiiQu for ; Wed, 2 Sep 2015 05:08:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 342481B37A8 for ; Wed, 2 Sep 2015 05:08:03 -0700 (PDT) Received: from [192.168.1.109] (modemcable093.65-160-184.mc.videotron.ca [184.160.65.93]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 42DF847122; Wed, 2 Sep 2015 08:08:02 -0400 (EDT) From: "Marc Blanchet" To: "Songhaibin (A)" Date: Wed, 02 Sep 2015 08:07:51 -0400 Message-ID: <391A575D-2C0C-4081-AB29-A44D9ABB7EA8@viagenie.ca> In-Reply-To: References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Linhui Sun , storagesync , Ted Lemon , "qinxiaowei@cnnic.cn" Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 12:08:05 -0000 I’ve said to the organizers that I think a solution already implemented and deployed is rsync over webdav for this. It should be looked at carefully before reinventing a new protocol. Marc. On 1 Sep 2015, at 22:56, Songhaibin (A) wrote: > IMO, WebDAV can be seen as the IETF sync protocol for version > management. I do not know if NFS also supports sync or not. > > Best Regards! > -Haibin > > From: Storagesync [mailto:storagesync-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: Wednesday, September 02, 2015 10:54 AM > To: qinxiaowei@cnnic.cn > Cc: Linhui Sun; storagesync > Subject: Re: [Storagesync] Welcome to the Discussion on Internet > Storage Sync > > On Sep 1, 2015, at 10:25 PM, > qinxiaowei@cnnic.cn wrote: > Besides optimizing the sync protocol, we may consider to avoid the > transmission bottlenecks existing in long internet communication, such > as latency, packet loss, network outages, inefficient > protocols, and inter-network friction, etc. > > Question: you say "optimizing the sync protocol," which sounds like > there is already a sync protocol. Is that true, or do you mean > optimizing the sync protocol after it’s been developed? I > haven’t seen any documents about a sync protocol yet. > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync From nobody Wed Sep 2 05:24:20 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE1B1A8992 for ; Wed, 2 Sep 2015 05:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu81BDjGaD3g for ; Wed, 2 Sep 2015 05:24:15 -0700 (PDT) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id DF02E1A6FDA for ; Wed, 2 Sep 2015 05:24:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DAB0B981-2C0A-47D3-8B21-C85911DA4708" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Ted Lemon In-Reply-To: Date: Wed, 2 Sep 2015 08:23:47 -0400 Message-Id: <2BD03E33-4F3B-43E8-8A9A-BEA4E3415FD3@fugue.com> References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> To: Linhui Sun X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "Songhaibin \(A\)" , storagesync , "qinxiaowei@cnnic.cn" Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 12:24:18 -0000 --Apple-Mail=_DAB0B981-2C0A-47D3-8B21-C85911DA4708 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 2, 2015, at 7:40 AM, Linhui Sun > wrote: > I think maybe we should make the definition of sync clearer. Could we = explain it as a simple upload/download process. Or the sync is = specifically referred to the transfer process of Network-based storage = services which may employ several well-known techniques (e.g. rsync)? Personally I am not interested in a client/server sync protocol. What = I would like is a sync protocol more like git, where each device has a = history of the last time a sync happened, and can tell what has changed = since the last sync. When two devices connect, they compare notes and = figure out what changes have to be made on both sides to reach a new = master version. This of course means that some conflict resolution = process may be necessary. It also means that if two devices connect to = a central server on a regular basis, they will be in sync with each = other even though they have never communicated. I think this is a more useful paradigm than something like rsync, but I = realize that it=E2=80=99s a lot more complicated, and may be beyond the = scope of what the folks who proposed this mailing list intended. Is it = something you=E2=80=99d be interested in pursuing, or should I go off = and do it on my own? :) --Apple-Mail=_DAB0B981-2C0A-47D3-8B21-C85911DA4708 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Sep 2, 2015, at 7:40 AM, Linhui Sun <lh.sunlinh@gmail.com> wrote:
I think maybe we should make the definition of = sync clearer. Could we explain it as a simple upload/download process. = Or the sync is specifically referred to the transfer process = of Network-based storage services which may employ several = well-known techniques (e.g. rsync)?

Personally I am not interested in a = client/server sync protocol.   What I would like is a sync protocol = more like git, where each device has a history of the last time a sync = happened, and can tell what has changed since the last sync.   When = two devices connect, they compare notes and figure out what changes have = to be made on both sides to reach a new master version.   This of = course means that some conflict resolution process may be necessary. =   It also means that if two devices connect to a central server on = a regular basis, they will be in sync with each other even though they = have never communicated.

I think this is a more useful paradigm than something like = rsync, but I realize that it=E2=80=99s a lot more complicated, and may = be beyond the scope of what the folks who proposed this mailing list = intended.   Is it something you=E2=80=99d be interested in = pursuing, or should I go off and do it on my own?   :)

= --Apple-Mail=_DAB0B981-2C0A-47D3-8B21-C85911DA4708-- From nobody Wed Sep 2 05:39:35 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1C61B323E for ; Wed, 2 Sep 2015 05:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzbgcmGhfQj4 for ; Wed, 2 Sep 2015 05:39:31 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D71C1B318F for ; Wed, 2 Sep 2015 05:39:31 -0700 (PDT) Received: by lbpo4 with SMTP id o4so5167470lbp.2 for ; Wed, 02 Sep 2015 05:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Rfzcp+kDSlDeIXcZr52HQ6SgKTYIkIwrsOAsaXXg+Mw=; b=NVRNXj/vXFNANVqlb0ZwyNmj5hpIKVoBOPL2kf8kmTQ3cYhLrB4XbBTm2vAtMxI0mi dExK38VYWxv0mPnBEv1s2uQRXE2bP6CWbFJ9HYppHn0vtwJ//WOULDknyOTpMAvm9Hop E5rwtRYG9BUK6s7256SarFMOww1+mbMoFkGcVbwXDdhPw4ow6ijEkLEhbAYT6e0P6IgZ rlaMbfX1LuZS5ke05GdNWHLguT9zjKFxTTDnXHhyIp0z/tTaI1xkS7imKEqFrTFCy8F2 xplbEk5xKfjKZUa5MlLA9f00Ni29ztnVAnRNGzgfJ1FvtQthZ85ziMfv6Eq3zyvnFI8Y OUJg== X-Received: by 10.112.168.41 with SMTP id zt9mr15387304lbb.25.1441197569326; Wed, 02 Sep 2015 05:39:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.22.209 with HTTP; Wed, 2 Sep 2015 05:39:08 -0700 (PDT) In-Reply-To: <391A575D-2C0C-4081-AB29-A44D9ABB7EA8@viagenie.ca> References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> <391A575D-2C0C-4081-AB29-A44D9ABB7EA8@viagenie.ca> From: Linhui Sun Date: Wed, 2 Sep 2015 20:39:08 +0800 Message-ID: To: Marc Blanchet Content-Type: multipart/alternative; boundary=001a11c340142bc60e051ec2f56b Archived-At: Cc: "Songhaibin \(A\)" , storagesync , Ted Lemon , "qinxiaowei@cnnic.cn" Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 12:39:33 -0000 --001a11c340142bc60e051ec2f56b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Marc, We've refined the wiki and it includes a brief comparison between WebDAV/rsync and this ISS work ( https://github.com/iss-ietf/iss/wiki/Internet-Storage-Sync/). Actually, there exists third party software called DropDAV that user could use WebDAV to sync files with Dropbox servers. As for rsync over WebDAV, it is really a smart solution which introduce incremental sync in the original WebDAV. IMO, they are two different things which have different focuses. And I think it would be an interesting issue to introduce some features of WebDAV (e.g. version control) in the ISS work to enhance its collaborative work ability. 2015-09-02 20:07 GMT+08:00 Marc Blanchet : > I=E2=80=99ve said to the organizers that I think a solution already imple= mented > and deployed is rsync over webdav for this. It should be looked at > carefully before reinventing a new protocol. > > Marc. > > On 1 Sep 2015, at 22:56, Songhaibin (A) wrote: > > IMO, WebDAV can be seen as the IETF sync protocol for version management. >> I do not know if NFS also supports sync or not. >> >> Best Regards! >> -Haibin >> >> From: Storagesync [mailto:storagesync-bounces@ietf.org] On Behalf Of Ted >> Lemon >> Sent: Wednesday, September 02, 2015 10:54 AM >> To: qinxiaowei@cnnic.cn >> Cc: Linhui Sun; storagesync >> Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage >> Sync >> >> On Sep 1, 2015, at 10:25 PM, qinxiaowei@cnnic.cn> qinxiaowei@cnnic.cn> wrote: >> Besides optimizing the sync protocol, we may consider to avoid the >> transmission bottlenecks existing in long internet communication, such a= s >> latency, packet loss, network outages, inefficient >> protocols, and inter-network friction, etc. >> >> Question: you say "optimizing the sync protocol," which sounds like ther= e >> is already a sync protocol. Is that true, or do you mean optimizing th= e >> sync protocol after it=E2=80=99s been developed? I haven=E2=80=99t see= n any documents >> about a sync protocol yet. >> >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/storagesync >> > --001a11c340142bc60e051ec2f56b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marc,

We've refined the wiki and= it includes a brief comparison between WebDAV/rsync and this ISS work (https://github.com/= iss-ietf/iss/wiki/Internet-Storage-Sync/). Actually, there exists third= party software called DropDAV that user could use WebDAV to sync files wit= h Dropbox servers. As for rsync over WebDAV, it is really a smart solution = which introduce incremental sync in the original WebDAV.

IMO, they are two different things which have different focuses. And= I think it would be an interesting issue to introduce some features of Web= DAV (e.g. version control) in the ISS work to enhance its collaborative wor= k ability.




2015-09-02 20:07 GMT+08:0= 0 Marc Blanchet <marc.blanchet@viagenie.ca>:
I=E2=80=99ve said to the organizers that I think= a solution already implemented and deployed is rsync over webdav for this.= It should be looked at carefully before reinventing a new protocol.

Marc.

On 1 Sep 2015, at 22:56, Songhaibin (A) wrote:

IMO, WebDAV can be seen as the IETF sync protocol for version management. I= do not know if NFS also supports sync or not.

Best Regards!
-Haibin

From: Storagesync [mailto:storagesync-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, September 02, 2015 10:54 AM
To: qinxiaowei@cnn= ic.cn
Cc: Linhui Sun; storagesync
Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sy= nc

 On Sep 1, 2015, at 10:25 PM, qinxiaowei@cnnic.cn<mailto:qinxiaowei@cnnic.cn> wrote:
Besides=C2=A0 optimizing the sync protocol, we may consider to avoid the tr= ansmission bottlenecks existing in long internet communication, such as lat= ency, packet loss, network outages, inefficient
protocols, and inter-network friction, etc.

Question: you say "optimizing the sync protocol," which sounds li= ke there is already a sync protocol.=C2=A0 =C2=A0Is that true, or do you me= an optimizing the sync protocol after it=E2=80=99s been developed?=C2=A0 = =C2=A0I haven=E2=80=99t seen any documents about a sync protocol yet.

 _______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync

--001a11c340142bc60e051ec2f56b-- From nobody Wed Sep 2 05:41:19 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5C41B37BF for ; Wed, 2 Sep 2015 05:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBZ0RN1QanQ8 for ; Wed, 2 Sep 2015 05:41:16 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896CC1B38A4 for ; Wed, 2 Sep 2015 05:41:13 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so5164969lbc.3 for ; Wed, 02 Sep 2015 05:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=d4SSYhfPQvsB6ARvq7auR8O+bUSCS1+E1Idugh620tQ=; b=bYBoVEAd6ntdDkE67u+p/FucDAlgu8xA4P8JB0aGf+ocIrHBGZfe06MTPtYQ0eUiNv H1Qwf9sHKK2ZcrzH21EUDUbZGwKF0CyJAaF83l3VXOxupM4sudK4/+CjfbIY4/UTEyIX sjys7E9lKMvOZQUAI+mhoqKmNTmq5yCVCg5DMsyDogGU9JtDyI1544anbG4jTv6SS7fy QaXE36nuo3IPORKv2aV62t3o+JJtZFJZDq3C2ksUGr52SOrTZVDLBPre6mzPr4Bj/EEJ Z8ZQjZrA8BSVka5qp+5CmPmtpB8dftQ4qodn0jBfeeJ0gGCLviQINmw/IaQrPlOmp+CY BPWw== X-Received: by 10.112.182.42 with SMTP id eb10mr15555375lbc.62.1441197671799; Wed, 02 Sep 2015 05:41:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.13.105 with HTTP; Wed, 2 Sep 2015 05:40:51 -0700 (PDT) In-Reply-To: <2BD03E33-4F3B-43E8-8A9A-BEA4E3415FD3@fugue.com> References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> <2BD03E33-4F3B-43E8-8A9A-BEA4E3415FD3@fugue.com> From: Linhui Sun Date: Wed, 2 Sep 2015 20:40:51 +0800 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c36e32475fc0051ec2fb54 Archived-At: Cc: "Songhaibin \(A\)" , storagesync , "qinxiaowei@cnnic.cn" Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 12:41:18 -0000 --001a11c36e32475fc0051ec2fb54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-09-02 20:23 GMT+08:00 Ted Lemon : > On Sep 2, 2015, at 7:40 AM, Linhui Sun wrote: > > I think maybe we should make the definition of sync clearer. Could we > explain it as a simple upload/download process. Or the sync is specifical= ly > referred to the transfer process of Network-based storage services which > may employ several well-known techniques (e.g. rsync)? > > > Personally I am not interested in a client/server sync protocol. What I > would like is a sync protocol more like git, where each device has a > history of the last time a sync happened, and can tell what has changed > since the last sync. When two devices connect, they compare notes and > figure out what changes have to be made on both sides to reach a new mast= er > version. This of course means that some conflict resolution process may > be necessary. It also means that if two devices connect to a central > server on a regular basis, they will be in sync with each other even thou= gh > they have never communicated. > > [LH]: That is what we want to do in the IETF and is also what the current storage services are trying to provide. Simple C/S protocol is not satisfied. I think this is a more useful paradigm than something like rsync, but I > realize that it=E2=80=99s a lot more complicated, and may be beyond the s= cope of > what the folks who proposed this mailing list intended. Is it something > you=E2=80=99d be interested in pursuing, or should I go off and do it on = my own? > :) > > [LH]: I think rsync should not be considered as an essential part of such sync protocol. Not only because it is complicated. We usually find the rsync failed in some scenarios and sometimes causes extra sync traffic. --001a11c36e32475fc0051ec2fb54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2015-09-02 20:23 GMT+08:00 Ted Lemon <mellon@fugue.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Sep 2, 2015, at 7:40 AM, Linhui Sun <lh.sunlinh@gmail.com> wrote:
<= blockquote type=3D"cite">
I think maybe we should make the definition of sync clearer. Could we= explain it as a simple upload/download process. Or the sync is specificall= y referred to the transfer process of=C2=A0Network-based storage services w= hich may employ several well-known techniques (e.g. rsync)?

Personally I am not interested in a client/= server sync protocol. =C2=A0 What I would like is a sync protocol more like= git, where each device has a history of the last time a sync happened, and= can tell what has changed since the last sync. =C2=A0 When two devices con= nect, they compare notes and figure out what changes have to be made on bot= h sides to reach a new master version. =C2=A0 This of course means that som= e conflict resolution process may be necessary. =C2=A0 It also means that i= f two devices connect to a central server on a regular basis, they will be = in sync with each other even though they have never communicated.

[LH]: That is what we want to do in the = IETF and is also what the current storage services are trying to provide. S= imple C/S protocol is not satisfied.

I think t= his is a more useful paradigm than something like rsync, but I realize that= it=E2=80=99s a lot more complicated, and may be beyond the scope of what t= he folks who proposed this mailing list intended. =C2=A0 Is it something yo= u=E2=80=99d be interested in pursuing, or should I go off and do it on my o= wn? =C2=A0 :)

[LH]: I think rsy= nc should not be considered as an essential part of such sync protocol. Not= only because it is complicated. We usually find the rsync failed in some s= cenarios and sometimes causes extra sync traffic.

--001a11c36e32475fc0051ec2fb54-- From nobody Wed Sep 2 07:29:38 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A8B1A87ED for ; Wed, 2 Sep 2015 07:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRK593W1UI5e for ; Wed, 2 Sep 2015 07:29:29 -0700 (PDT) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id B19B91A6FDA for ; Wed, 2 Sep 2015 07:29:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_35F94697-F6B7-4E52-A35B-DDB052FDF7FA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Ted Lemon In-Reply-To: <391A575D-2C0C-4081-AB29-A44D9ABB7EA8@viagenie.ca> Date: Wed, 2 Sep 2015 10:29:01 -0400 Message-Id: <2DCBE30D-A3D3-485F-8073-FC3779DE67C7@fugue.com> References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> <391A575D-2C0C-4081-AB29-A44D9ABB7EA8@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Linhui Sun , "Songhaibin \(A\)" , storagesync , "qinxiaowei@cnnic.cn" Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 14:29:36 -0000 --Apple-Mail=_35F94697-F6B7-4E52-A35B-DDB052FDF7FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 2, 2015, at 8:07 AM, Marc Blanchet = wrote: > I=E2=80=99ve said to the organizers that I think a solution already = implemented and deployed is rsync over webdav for this. It should be = looked at carefully before reinventing a new protocol. rsync is inadequate if you have changes on both ends or more than two = copies of the sync=E2=80=99d data. An rfc describing the rsync = protocol might be useful to someone, but I don=E2=80=99t think it=E2=80=99= s interesting new work. However, this question is certainly one that = should be answered in the requirements document. Do you think rsync is = adequate because you think that parallel updates aren=E2=80=99t = important? It sounds like one motivation for this work is support for = CDNs, and for those something like rsync would be perfectly adequate, = but that=E2=80=99s not the use case I=E2=80=99m interested in. = Frankly, that seems like a solved problem to me. --Apple-Mail=_35F94697-F6B7-4E52-A35B-DDB052FDF7FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Sep 2, 2015, at 8:07 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
I=E2=80=99ve said to the organizers that I think = a solution already implemented and deployed is rsync over webdav for = this. It should be looked at carefully before reinventing a new = protocol.

rsync = is inadequate if you have changes on both ends or more than two copies = of the sync=E2=80=99d data.   An rfc describing the rsync protocol = might be useful to someone, but I don=E2=80=99t think it=E2=80=99s = interesting new work.   However, this question is certainly one = that should be answered in the requirements document.   Do you = think rsync is adequate because you think that parallel updates aren=E2=80= =99t important?   It sounds like one motivation for this work is = support for CDNs, and for those something like rsync would be perfectly = adequate, but that=E2=80=99s not the use case I=E2=80=99m interested in. =   Frankly, that seems like a solved problem to me.

= --Apple-Mail=_35F94697-F6B7-4E52-A35B-DDB052FDF7FA-- From nobody Wed Sep 2 08:27:11 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16B11ACE67 for ; Wed, 2 Sep 2015 08:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcsKltxLUdy5 for ; Wed, 2 Sep 2015 08:27:09 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE091B3C70 for ; Wed, 2 Sep 2015 08:27:05 -0700 (PDT) Received: from [192.168.1.109] (modemcable093.65-160-184.mc.videotron.ca [184.160.65.93]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AF5E840FF4; Wed, 2 Sep 2015 11:27:04 -0400 (EDT) From: "Marc Blanchet" To: "Ted Lemon" Date: Wed, 02 Sep 2015 11:26:53 -0400 Message-ID: In-Reply-To: <2DCBE30D-A3D3-485F-8073-FC3779DE67C7@fugue.com> References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> <391A575D-2C0C-4081-AB29-A44D9ABB7EA8@viagenie.ca> <2DCBE30D-A3D3-485F-8073-FC3779DE67C7@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Linhui Sun , "Songhaibin \(A\)" , storagesync , "qinxiaowei@cnnic.cn" Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:27:10 -0000 On 2 Sep 2015, at 10:29, Ted Lemon wrote: > On Sep 2, 2015, at 8:07 AM, Marc Blanchet > wrote: >> I’ve said to the organizers that I think a solution already >> implemented and deployed is rsync over webdav for this. It should be >> looked at carefully before reinventing a new protocol. > > rsync is inadequate if you have changes on both ends or more than two > copies of the sync’d data. An rfc describing the rsync protocol > might be useful to someone, but I don’t think it’s interesting new > work. However, this question is certainly one that should be > answered in the requirements document. Do you think rsync is > adequate because you think that parallel updates aren’t important? > It sounds like one motivation for this work is support for CDNs, and > for those something like rsync would be perfectly adequate, but > that’s not the use case I’m interested in. Frankly, that seems > like a solved problem to me. well, that is my point, so we agree… - webdav+rsync is providing pretty good solution. therefore, it should be clearly identified in the problem statement and also what it is not solving. - then we can discuss what other features (such as what you described) can be worth technical work, spec, etc… Marc. > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync From nobody Wed Sep 2 09:59:57 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0F41B4B7F for ; Wed, 2 Sep 2015 09:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vceLWEE8O7dX for ; Wed, 2 Sep 2015 09:59:55 -0700 (PDT) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id B87061B4F9F for ; Wed, 2 Sep 2015 09:59:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B0C1F131-D674-43C7-8E5F-7F5C1090EA54" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Ted Lemon In-Reply-To: Date: Wed, 2 Sep 2015 12:59:26 -0400 Message-Id: <5001ED45-B04B-404B-9FF5-BB3DD87D501B@fugue.com> References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> <391A575D-2C0C-4081-AB29-A44D9ABB7EA8@viagenie.ca> <2DCBE30D-A3D3-485F-8073-FC3779DE67C7@fugue.com> To: Marc Blanchet X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Linhui Sun , "Songhaibin \(A\)" , storagesync , "qinxiaowei@cnnic.cn" Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 16:59:57 -0000 --Apple-Mail=_B0C1F131-D674-43C7-8E5F-7F5C1090EA54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 2, 2015, at 11:26 AM, Marc Blanchet = wrote: > well, that is my point, so we agree=E2=80=A6 > - webdav+rsync is providing pretty good solution. therefore, it should = be clearly identified in the problem statement and also what it is not = solving. > - then we can discuss what other features (such as what you described) = can be worth technical work, spec, etc=E2=80=A6 Ah, OK, thanks for clarifying! --Apple-Mail=_B0C1F131-D674-43C7-8E5F-7F5C1090EA54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Sep 2, 2015, at 11:26 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
well, that is my point, so we agree=E2=80=A6
- webdav+rsync is providing pretty good = solution. therefore, it should be clearly identified in the problem = statement and also what it is not solving.
- then we can discuss what other features (such = as what you described) can be worth technical work, spec, = etc=E2=80=A6

Ah, OK, thanks for clarifying!

= --Apple-Mail=_B0C1F131-D674-43C7-8E5F-7F5C1090EA54-- From nobody Wed Sep 2 12:02:48 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914651B4909 for ; Wed, 2 Sep 2015 12:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3vTti7soriV for ; Wed, 2 Sep 2015 12:02:42 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A572F1A032D for ; Wed, 2 Sep 2015 12:02:42 -0700 (PDT) Received: by obbbh8 with SMTP id bh8so16468516obb.0 for ; Wed, 02 Sep 2015 12:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BObw+bYK3GrnlQSUh5N59uRqVN7vAFeGOZ5iWU+u8M8=; b=LcegpGr+KsH1PGGQSCuW+/UkrKoJ5FE5EXJco6gYO2SopPstRedFGqvnOOMB0ZkgM4 Y0uFFr4z9rLgRlUz/uIq0DHQdTXzCa95Im//2rHspuqAjrN3YPelb8G+I7tVCkI5RvP3 nLgLyRbwDHX+pK37y9HqSJOwwsTTY7cvNQAomDLTQ4znqOxOB28Ld4IWvAFjOl7zlSSj etF1elftBPuFEQ9cc7Y1PvFy0FG5V7GBG7OjMVCEua6bgrphbzybVl+bYii5bn09MdYY tthNIBLocb8AiMpzS8qZ2onShwW6cVe+XZeEL6BeL9rZ6Kd4hi1ZrfXkIGtoFMPB6pES 9asQ== MIME-Version: 1.0 X-Received: by 10.60.42.103 with SMTP id n7mr10571071oel.8.1441220561945; Wed, 02 Sep 2015 12:02:41 -0700 (PDT) Received: by 10.182.230.231 with HTTP; Wed, 2 Sep 2015 12:02:41 -0700 (PDT) Received: by 10.182.230.231 with HTTP; Wed, 2 Sep 2015 12:02:41 -0700 (PDT) Date: Wed, 2 Sep 2015 15:02:41 -0400 Message-ID: From: David Noveck To: storagesync@ietf.org Content-Type: multipart/alternative; boundary=089e01536ebaa34b08051ec84fe2 Archived-At: Subject: [Storagesync] Unsubscribe X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 19:02:45 -0000 --089e01536ebaa34b08051ec84fe2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sep 2, 2015 3:00 PM, wrote: > Send Storagesync mailing list submissions to > storagesync@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/storagesync > or, via email, send a message with subject or body 'help' to > storagesync-request@ietf.org > > You can reach the person managing the list at > storagesync-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Storagesync digest..." > > Today's Topics: > > 1. Re: Welcome to the Discussion on Internet Storage Sync > (Linhui Sun) > 2. Re: Welcome to the Discussion on Internet Storage Sync (Ted Lemon) > 3. Re: Welcome to the Discussion on Internet Storage Sync > (Marc Blanchet) > 4. Re: Welcome to the Discussion on Internet Storage Sync (Ted Lemon) > > > ---------- Forwarded message ---------- > From: Linhui Sun > To: Ted Lemon > Cc: "Songhaibin (A)" , storagesync < > storagesync@ietf.org>, "qinxiaowei@cnnic.cn" > Date: Wed, 2 Sep 2015 20:40:51 +0800 > Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage > Sync > > 2015-09-02 20:23 GMT+08:00 Ted Lemon : > >> On Sep 2, 2015, at 7:40 AM, Linhui Sun wrote: >> >> I think maybe we should make the definition of sync clearer. Could we >> explain it as a simple upload/download process. Or the sync is specifica= lly >> referred to the transfer process of Network-based storage services which >> may employ several well-known techniques (e.g. rsync)? >> >> >> Personally I am not interested in a client/server sync protocol. What = I >> would like is a sync protocol more like git, where each device has a >> history of the last time a sync happened, and can tell what has changed >> since the last sync. When two devices connect, they compare notes and >> figure out what changes have to be made on both sides to reach a new mas= ter >> version. This of course means that some conflict resolution process ma= y >> be necessary. It also means that if two devices connect to a central >> server on a regular basis, they will be in sync with each other even tho= ugh >> they have never communicated. >> >> [LH]: That is what we want to do in the IETF and is also what the curren= t > storage services are trying to provide. Simple C/S protocol is not > satisfied. > > I think this is a more useful paradigm than something like rsync, but I >> realize that it=E2=80=99s a lot more complicated, and may be beyond the = scope of >> what the folks who proposed this mailing list intended. Is it somethin= g >> you=E2=80=99d be interested in pursuing, or should I go off and do it on= my own? >> :) >> >> [LH]: I think rsync should not be considered as an essential part of suc= h > sync protocol. Not only because it is complicated. We usually find the > rsync failed in some scenarios and sometimes causes extra sync traffic. > > > > ---------- Forwarded message ---------- > From: Ted Lemon > To: Marc Blanchet > Cc: Linhui Sun , "Songhaibin (A)" < > haibin.song@huawei.com>, storagesync , " > qinxiaowei@cnnic.cn" > Date: Wed, 2 Sep 2015 10:29:01 -0400 > Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage > Sync > On Sep 2, 2015, at 8:07 AM, Marc Blanchet > wrote: > > I=E2=80=99ve said to the organizers that I think a solution already imple= mented > and deployed is rsync over webdav for this. It should be looked at > carefully before reinventing a new protocol. > > > rsync is inadequate if you have changes on both ends or more than two > copies of the sync=E2=80=99d data. An rfc describing the rsync protocol= might be > useful to someone, but I don=E2=80=99t think it=E2=80=99s interesting new= work. However, > this question is certainly one that should be answered in the requirement= s > document. Do you think rsync is adequate because you think that paralle= l > updates aren=E2=80=99t important? It sounds like one motivation for thi= s work is > support for CDNs, and for those something like rsync would be perfectly > adequate, but that=E2=80=99s not the use case I=E2=80=99m interested in. = Frankly, that > seems like a solved problem to me. > > > > ---------- Forwarded message ---------- > From: Marc Blanchet > To: Ted Lemon > Cc: Linhui Sun , "Songhaibin (A)" < > haibin.song@huawei.com>, storagesync , " > qinxiaowei@cnnic.cn" > Date: Wed, 02 Sep 2015 11:26:53 -0400 > Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage > Sync > > > On 2 Sep 2015, at 10:29, Ted Lemon wrote: > > On Sep 2, 2015, at 8:07 AM, Marc Blanchet >> wrote: >> >>> I=E2=80=99ve said to the organizers that I think a solution already imp= lemented >>> and deployed is rsync over webdav for this. It should be looked at >>> carefully before reinventing a new protocol. >>> >> >> rsync is inadequate if you have changes on both ends or more than two >> copies of the sync=E2=80=99d data. An rfc describing the rsync protoco= l might be >> useful to someone, but I don=E2=80=99t think it=E2=80=99s interesting ne= w work. However, >> this question is certainly one that should be answered in the requiremen= ts >> document. Do you think rsync is adequate because you think that parall= el >> updates aren=E2=80=99t important? It sounds like one motivation for th= is work is >> support for CDNs, and for those something like rsync would be perfectly >> adequate, but that=E2=80=99s not the use case I=E2=80=99m interested in.= Frankly, that >> seems like a solved problem to me. >> > > well, that is my point, so we agree=E2=80=A6 > - webdav+rsync is providing pretty good solution. therefore, it should be > clearly identified in the problem statement and also what it is not solvi= ng. > - then we can discuss what other features (such as what you described) ca= n > be worth technical work, spec, etc=E2=80=A6 > > Marc. > > > >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/storagesync >> > > > > > ---------- Forwarded message ---------- > From: Ted Lemon > To: Marc Blanchet > Cc: Linhui Sun , "Songhaibin (A)" < > haibin.song@huawei.com>, storagesync , " > qinxiaowei@cnnic.cn" > Date: Wed, 2 Sep 2015 12:59:26 -0400 > Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage > Sync > On Sep 2, 2015, at 11:26 AM, Marc Blanchet > wrote: > > well, that is my point, so we agree=E2=80=A6 > - webdav+rsync is providing pretty good solution. therefore, it should be > clearly identified in the problem statement and also what it is not solvi= ng. > - then we can discuss what other features (such as what you described) ca= n > be worth technical work, spec, etc=E2=80=A6 > > > Ah, OK, thanks for clarifying! > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --089e01536ebaa34b08051ec84fe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sep 2, 2015 3:00 PM, <storagesync-request@ietf.org> wrote:
Send Storagesync maili= ng list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storage= sync@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/ma= ilman/listinfo/storagesync
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s= toragesync-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Storagesync digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: Welcome to the Discussion on Internet Storage Sync
=C2=A0 =C2=A0 =C2=A0 (Linhui Sun)
=C2=A0 =C2=A02. Re: Welcome to the Discussion on Internet Storage Sync (Ted= Lemon)
=C2=A0 =C2=A03. Re: Welcome to the Discussion on Internet Storage Sync
=C2=A0 =C2=A0 =C2=A0 (Marc Blanchet)
=C2=A0 =C2=A04. Re: Welcome to the Discussion on Internet Storage Sync (Ted= Lemon)


---------- Forwarded message ----------
From:=C2=A0Linhui Sun &l= t;lh.sunlinh@gmail.com>
T= o:=C2=A0Ted Lemon <mellon@fugue.com<= /a>>
Cc:=C2=A0"Songhaibin (A)" <haibin.song@huawei.com>, storagesync <storagesync@ietf.org>, "qinxiaowei@cnnic.cn" <qinxiaowei@cnnic.cn>
Date:=C2=A0W= ed, 2 Sep 2015 20:40:51 +0800
Subject:=C2=A0Re: [Storagesync] Welcome to= the Discussion on Internet Storage Sync

2015-09-02 20:23 GMT+08:00 Ted = Lemon <mellon@fugue.com>:
<= div style=3D"word-wrap:break-word">On Sep 2, 2015, at 7:40 AM, Linhui= Sun <lh.sunli= nh@gmail.com> wrote:
I think maybe we should make the de= finition of sync clearer. Could we explain it as a simple upload/download p= rocess. Or the sync is specifically referred to the transfer process of=C2= =A0Network-based storage services which may employ several well-known techn= iques (e.g. rsync)?

Personal= ly I am not interested in a client/server sync protocol. =C2=A0 What I woul= d like is a sync protocol more like git, where each device has a history of= the last time a sync happened, and can tell what has changed since the las= t sync. =C2=A0 When two devices connect, they compare notes and figure out = what changes have to be made on both sides to reach a new master version. = =C2=A0 This of course means that some conflict resolution process may be ne= cessary. =C2=A0 It also means that if two devices connect to a central serv= er on a regular basis, they will be in sync with each other even though the= y have never communicated.

[LH]= : That is what we want to do in the IETF and is also what the current stora= ge services are trying to provide. Simple C/S protocol is not satisfied.

I think this is a more useful paradigm than somet= hing like rsync, but I realize that it=E2=80=99s a lot more complicated, an= d may be beyond the scope of what the folks who proposed this mailing list = intended. =C2=A0 Is it something you=E2=80=99d be interested in pursuing, o= r should I go off and do it on my own? =C2=A0 :)

=
[LH]: I think rsync should not be considered as an essent= ial part of such sync protocol. Not only because it is complicated. We usua= lly find the rsync failed in some scenarios and sometimes causes extra sync= traffic.



---------- Forwarded message ----------
From:=C2=A0Ted Lemon <= ;mellon@fugue.com>
To:=C2=A0M= arc Blanchet <marc.blanchet= @viagenie.ca>
Cc:=C2=A0Linhui Sun <lh.sunlinh@gmail.com>, "Songhaibin (A)" <<= a href=3D"mailto:haibin.song@huawei.com">haibin.song@huawei.com>, st= oragesync <storagesync@ietf.org<= /a>>, "qinxiaowei@cnnic.cn" <qinxiaowei@cnnic.cn= >
Date:=C2=A0Wed, 2 Sep 2015 10:29:01 -0400
Subject:=C2=A0Re: [Sto= ragesync] Welcome to the Discussion on Internet Storage Sync
On Sep 2, 2015, at 8:07 AM, Marc Blanchet <marc.blanchet@v= iagenie.ca> wrote:
I=E2=80=99ve said to the organizers th= at I think a solution already implemented and deployed is rsync over webdav= for this. It should be looked at carefully before reinventing a new protoc= ol.

rsync is inadequat= e if you have changes on both ends or more than two copies of the sync=E2= =80=99d data. =C2=A0 An rfc describing the rsync protocol might be useful t= o someone, but I don=E2=80=99t think it=E2=80=99s interesting new work. =C2= =A0 However, this question is certainly one that should be answered in the = requirements document. =C2=A0 Do you think rsync is adequate because you th= ink that parallel updates aren=E2=80=99t important? =C2=A0 It sounds like o= ne motivation for this work is support for CDNs, and for those something li= ke rsync would be perfectly adequate, but that=E2=80=99s not the use case I= =E2=80=99m interested in. =C2=A0 Frankly, that seems like a solved problem = to me.



---------- Forwarded message -----= -----
From:=C2=A0Marc Blanchet <marc.blanchet@viagenie.ca>
To:=C2=A0Ted Lemon <mellon@fugue.com>
Cc:=C2=A0Linhui Su= n <lh.sunlinh@gmail.com>,= "Songhaibin (A)" <h= aibin.song@huawei.com>, storagesync <storagesync@ietf.org>, "qinxiaowei@cnnic.cn" <qinxiaowei@cnnic.cn>
Date:=C2=A0Wed, 02 Sep 2015 11:26:= 53 -0400
Subject:=C2=A0Re: [Storagesync] Welcome to the Discussion on In= ternet Storage Sync


On 2 Sep 2015, at 10:29, Ted Lemon wrote:

On Sep 2, 2015, at 8:07 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:<= br>
I=E2=80=99ve said to the organizers that I think a solution already impleme= nted and deployed is rsync over webdav for this. It should be looked at car= efully before reinventing a new protocol.

rsync is inadequate if you have changes on both ends or more than two copie= s of the sync=E2=80=99d data.=C2=A0 =C2=A0An rfc describing the rsync proto= col might be useful to someone, but I don=E2=80=99t think it=E2=80=99s inte= resting new work.=C2=A0 =C2=A0However, this question is certainly one that = should be answered in the requirements document.=C2=A0 =C2=A0Do you think r= sync is adequate because you think that parallel updates aren=E2=80=99t imp= ortant?=C2=A0 =C2=A0It sounds like one motivation for this work is support = for CDNs, and for those something like rsync would be perfectly adequate, b= ut that=E2=80=99s not the use case I=E2=80=99m interested in.=C2=A0 =C2=A0F= rankly, that seems like a solved problem to me.

well, that is my point, so we agree=E2=80=A6
- webdav+rsync is providing pretty good solution. therefore, it should be c= learly identified in the problem statement and also what it is not solving.=
- then we can discuss what other features (such as what you described) can = be worth technical work, spec, etc=E2=80=A6

Marc.



_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync




---------- Forwarded message ----------
From:=C2=A0Ted Lemon <= ;mellon@fugue.com>
To:=C2=A0M= arc Blanchet <marc.blanchet= @viagenie.ca>
Cc:=C2=A0Linhui Sun <lh.sunlinh@gmail.com>, "Songhaibin (A)" <<= a href=3D"mailto:haibin.song@huawei.com">haibin.song@huawei.com>, st= oragesync <storagesync@ietf.org<= /a>>, "qinxiaowei@cnnic.cn" <qinxiaowei@cnnic.cn= >
Date:=C2=A0Wed, 2 Sep 2015 12:59:26 -0400
Subject:=C2=A0Re: [Sto= ragesync] Welcome to the Discussion on Internet Storage Sync
On Sep 2, 2015, at 11:26 AM, Marc Blanchet <marc.blanchet@= viagenie.ca> wrote:
well, that is my point, so we agree= =E2=80=A6
- webdav+rsync is providing pretty good solution. therefore, it should= be clearly identified in the problem statement and also what it is not sol= ving.
- then we can discuss what other features (such as what you described) can= be worth technical work, spec, etc=E2=80=A6

Ah, OK, thanks for clarifying!


____= ___________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync

--089e01536ebaa34b08051ec84fe2-- From nobody Tue Sep 8 14:05:03 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7F1B2DC5 for ; Tue, 8 Sep 2015 14:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdTPlUkTNaHt for ; Tue, 8 Sep 2015 14:04:58 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB661B2D6A for ; Tue, 8 Sep 2015 14:04:58 -0700 (PDT) Received: by ykdg206 with SMTP id g206so138990825ykd.1 for ; Tue, 08 Sep 2015 14:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f3TBl0XiZMQnaj9+2xkb4aj0psXqS1PU1mlnJfmRDpo=; b=OgmBfcM4j2uheeyhumPi00rEwQW6BKLRMgTwe52My8svnm2o5MkyBChsOuB1hmtf/H 3a4I/OuqbW0+SEZI/4vAoXTQlQz07rY6TCwfkpUzt4l3MzqyS+T5cLK0KkEUVonKsNnN +ugMn0smPsVvjqFxevMJc24CuAJczT/aQTPWUXsWOtZrN4Dai8g9uRaG/L5E6U1H6Fh5 kGrdhMHttsW0kb4ODURolaYtA8wy/w0WHLP4Gl1R3tK7PTT9bMbMMQjb7H7zxfuJhosO kCSTqNfZDHUoxRhi1mgmtiVHYyJwrN0LQaCFNJAE5COdMnrRW+uzQ+OZ/2wR5liNRC0G Xldw== MIME-Version: 1.0 X-Received: by 10.13.231.68 with SMTP id q65mr32256928ywe.79.1441746297354; Tue, 08 Sep 2015 14:04:57 -0700 (PDT) Received: by 10.37.210.17 with HTTP; Tue, 8 Sep 2015 14:04:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Sep 2015 23:04:57 +0200 Message-ID: From: ZeQi Lai To: storagesync@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07d65ae8fceb051f42b768 Archived-At: Cc: Linhui Sun , Yong Cui Subject: Re: [Storagesync] Storagesync Digest, Vol 2, Issue 6 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 21:05:02 -0000 --94eb2c07d65ae8fceb051f42b768 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ted and Marc, I am Zeqi Lai from Tsinghua University. Thanks for your suggestions! We would identify this in the problem statement later. However, I'd like to express some different viewpoints about the rsync over webdav first. Actually, I do not think rsync+WebDAV is not as good as it looks for several reasons. 1) WebDAV is not suitable for large files, e.g. a HD movie. Also WeDAV does not work well in mobile/wireless environments (high RTT/loss, intermittent connections). Temporary loss of connection may lead to sync failure. 2) There exists other capabilities (i.e. chunking, deduplication, bundling, compression) that can be used to speed up data sync. Current WebDAV does not consider these useful capabilities. 3) The limitation of rsync. Another point is that rsync works in the file granularity. That requires the entities running on two ends must have access to the entire file. However, to achieve better scalability, current network-based storage services split files into chunks and store them distributedly (chunk granularity). Directly using rsync needs to piece together all chunks to construct the whole file and would waste massive intra-cluster bandwidth. In summary, the sync protocol what we'd like to do is something more than rsync/webdav. As for the features Ted mentioned (e.g. parallel update), we haven't considered them a lot at first. After several recent discussions, we think they are really important and worth the effort. We'd like to see how many people have interests in those features? How many people think those features should be the core issue rather than improving the sync efficiency? And then we could update the problem statement and produce an appropriate charter : ) Best regards, Zeqi Lai On Thu, Sep 3, 2015 at 9:00 PM, wrote: > Send Storagesync mailing list submissions to > storagesync@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/storagesync > or, via email, send a message with subject or body 'help' to > storagesync-request@ietf.org > > You can reach the person managing the list at > storagesync-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Storagesync digest..." > > Today's Topics: > > 1. Unsubscribe (David Noveck) > > > ---------- Forwarded message ---------- > From: David Noveck > To: storagesync@ietf.org > Cc: > Date: Wed, 2 Sep 2015 15:02:41 -0400 > Subject: [Storagesync] Unsubscribe > On Sep 2, 2015 3:00 PM, wrote: > >> Send Storagesync mailing list submissions to >> storagesync@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/storagesync >> or, via email, send a message with subject or body 'help' to >> storagesync-request@ietf.org >> >> You can reach the person managing the list at >> storagesync-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Storagesync digest..." >> >> Today's Topics: >> >> 1. Re: Welcome to the Discussion on Internet Storage Sync >> (Linhui Sun) >> 2. Re: Welcome to the Discussion on Internet Storage Sync (Ted Lemon) >> 3. Re: Welcome to the Discussion on Internet Storage Sync >> (Marc Blanchet) >> 4. Re: Welcome to the Discussion on Internet Storage Sync (Ted Lemon) >> >> >> ---------- Forwarded message ---------- >> From: Linhui Sun >> To: Ted Lemon >> Cc: "Songhaibin (A)" , storagesync < >> storagesync@ietf.org>, "qinxiaowei@cnnic.cn" >> Date: Wed, 2 Sep 2015 20:40:51 +0800 >> Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage >> Sync >> >> 2015-09-02 20:23 GMT+08:00 Ted Lemon : >> >>> On Sep 2, 2015, at 7:40 AM, Linhui Sun wrote: >>> >>> I think maybe we should make the definition of sync clearer. Could we >>> explain it as a simple upload/download process. Or the sync is specific= ally >>> referred to the transfer process of Network-based storage services whic= h >>> may employ several well-known techniques (e.g. rsync)? >>> >>> >>> Personally I am not interested in a client/server sync protocol. What >>> I would like is a sync protocol more like git, where each device has a >>> history of the last time a sync happened, and can tell what has changed >>> since the last sync. When two devices connect, they compare notes and >>> figure out what changes have to be made on both sides to reach a new ma= ster >>> version. This of course means that some conflict resolution process m= ay >>> be necessary. It also means that if two devices connect to a central >>> server on a regular basis, they will be in sync with each other even th= ough >>> they have never communicated. >>> >>> [LH]: That is what we want to do in the IETF and is also what the >> current storage services are trying to provide. Simple C/S protocol is n= ot >> satisfied. >> >> I think this is a more useful paradigm than something like rsync, but I >>> realize that it=E2=80=99s a lot more complicated, and may be beyond the= scope of >>> what the folks who proposed this mailing list intended. Is it somethi= ng >>> you=E2=80=99d be interested in pursuing, or should I go off and do it o= n my own? >>> :) >>> >>> [LH]: I think rsync should not be considered as an essential part of >> such sync protocol. Not only because it is complicated. We usually find = the >> rsync failed in some scenarios and sometimes causes extra sync traffic. >> >> >> >> ---------- Forwarded message ---------- >> From: Ted Lemon >> To: Marc Blanchet >> Cc: Linhui Sun , "Songhaibin (A)" < >> haibin.song@huawei.com>, storagesync , " >> qinxiaowei@cnnic.cn" >> Date: Wed, 2 Sep 2015 10:29:01 -0400 >> Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage >> Sync >> On Sep 2, 2015, at 8:07 AM, Marc Blanchet >> wrote: >> >> I=E2=80=99ve said to the organizers that I think a solution already impl= emented >> and deployed is rsync over webdav for this. It should be looked at >> carefully before reinventing a new protocol. >> >> >> rsync is inadequate if you have changes on both ends or more than two >> copies of the sync=E2=80=99d data. An rfc describing the rsync protoco= l might be >> useful to someone, but I don=E2=80=99t think it=E2=80=99s interesting ne= w work. However, >> this question is certainly one that should be answered in the requiremen= ts >> document. Do you think rsync is adequate because you think that parall= el >> updates aren=E2=80=99t important? It sounds like one motivation for th= is work is >> support for CDNs, and for those something like rsync would be perfectly >> adequate, but that=E2=80=99s not the use case I=E2=80=99m interested in.= Frankly, that >> seems like a solved problem to me. >> >> >> >> ---------- Forwarded message ---------- >> From: Marc Blanchet >> To: Ted Lemon >> Cc: Linhui Sun , "Songhaibin (A)" < >> haibin.song@huawei.com>, storagesync , " >> qinxiaowei@cnnic.cn" >> Date: Wed, 02 Sep 2015 11:26:53 -0400 >> Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage >> Sync >> >> >> On 2 Sep 2015, at 10:29, Ted Lemon wrote: >> >> On Sep 2, 2015, at 8:07 AM, Marc Blanchet >>> wrote: >>> >>>> I=E2=80=99ve said to the organizers that I think a solution already im= plemented >>>> and deployed is rsync over webdav for this. It should be looked at >>>> carefully before reinventing a new protocol. >>>> >>> >>> rsync is inadequate if you have changes on both ends or more than two >>> copies of the sync=E2=80=99d data. An rfc describing the rsync protoc= ol might be >>> useful to someone, but I don=E2=80=99t think it=E2=80=99s interesting n= ew work. However, >>> this question is certainly one that should be answered in the requireme= nts >>> document. Do you think rsync is adequate because you think that paral= lel >>> updates aren=E2=80=99t important? It sounds like one motivation for t= his work is >>> support for CDNs, and for those something like rsync would be perfectly >>> adequate, but that=E2=80=99s not the use case I=E2=80=99m interested in= . Frankly, that >>> seems like a solved problem to me. >>> >> >> well, that is my point, so we agree=E2=80=A6 >> - webdav+rsync is providing pretty good solution. therefore, it should b= e >> clearly identified in the problem statement and also what it is not solv= ing. >> - then we can discuss what other features (such as what you described) >> can be worth technical work, spec, etc=E2=80=A6 >> >> Marc. >> >> >> >>> _______________________________________________ >>> Storagesync mailing list >>> Storagesync@ietf.org >>> https://www.ietf.org/mailman/listinfo/storagesync >>> >> >> >> >> >> ---------- Forwarded message ---------- >> From: Ted Lemon >> To: Marc Blanchet >> Cc: Linhui Sun , "Songhaibin (A)" < >> haibin.song@huawei.com>, storagesync , " >> qinxiaowei@cnnic.cn" >> Date: Wed, 2 Sep 2015 12:59:26 -0400 >> Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage >> Sync >> On Sep 2, 2015, at 11:26 AM, Marc Blanchet >> wrote: >> >> well, that is my point, so we agree=E2=80=A6 >> - webdav+rsync is providing pretty good solution. therefore, it should b= e >> clearly identified in the problem statement and also what it is not solv= ing. >> - then we can discuss what other features (such as what you described) >> can be worth technical work, spec, etc=E2=80=A6 >> >> >> Ah, OK, thanks for clarifying! >> >> >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/storagesync >> >> > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --=20 Yours sincerely LZQ --94eb2c07d65ae8fceb051f42b768 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ted and Marc,

I am Zeqi Lai from Tsinghua University.

Thanks for your suggestions! We would identify thi= s in the problem statement later. However, I'd like to express some dif= ferent viewpoints about the rsync over webdav first. Actually, I do not thi= nk rsync+WebDAV is not=C2=A0as good as it looks=C2=A0for several reasons.

1) WebDAV is not suitable=C2=A0for large files, e.g. a HD movie. Also=C2= =A0WeDAV does not work well in mobile/wireless environments=C2=A0(hi= gh RTT/loss, intermittent connections).=C2=A0Temporary loss of connection may lead to sync failure= .

2)=C2=A0There exists other capabilities (i.e. ch= unking, deduplication, bundling, compression) that can be used to speed up = data sync. Current WebDAV does not consider these useful=C2=A0capabilities.= =C2=A0

3) The limitation of rsync. Anot= her point is that rsync works in the file granularity. That requires the en= tities running on two ends must have access to the entire file. However, to= achieve better scalability, current network-based storage services split f= iles into chunks and store them distributedly (chunk granularity). Directly= using rsync needs to piece=C2=A0together all chunks to construct the whole= file and would waste massive intra-cluster bandwidth.

=
In summary, the sync protocol wh= at we'd like to do is something more than rsync/webdav. As for the feat= ures Ted mentioned (e.g. parallel update), we haven't considered them a= lot at first. After several recent discussions, we think they are really i= mportant and worth the effort. We'd like to see how many people have in= terests in those features? How many people think those features should be t= he core issue rather than improving the sync efficiency? And then we could = update the problem statement and produce an appropriate charter : )

Best regards,
Zeqi Lai

On Thu, Sep 3, 2= 015 at 9:00 PM, <storagesync-request@ietf.org> w= rote:
Send Storagesync mailing list submi= ssions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/ma= ilman/listinfo/storagesync
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Storagesync digest..."

Today's Topics:

=C2=A0 =C2=A01. Unsubscribe (David Noveck)


---------- Forwarded message ----------
From:=C2=A0David Noveck = <davenoveck@gm= ail.com>
To:=C2=A0storagesync@ietf.org
Cc:=C2=A0
Date:=C2=A0Wed, 2 Sep = 2015 15:02:41 -0400
Subject:=C2=A0[Storagesync] Unsubscribe
On Sep 2, 2015 3:00 PM, <storagesync-request@ietf.org> = wrote:
Send Storages= ync mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/ma= ilman/listinfo/storagesync
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Storagesync digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: Welcome to the Discussion on Internet Storage Sync
=C2=A0 =C2=A0 =C2=A0 (Linhui Sun)
=C2=A0 =C2=A02. Re: Welcome to the Discussion on Internet Storage Sync (Ted= Lemon)
=C2=A0 =C2=A03. Re: Welcome to the Discussion on Internet Storage Sync
=C2=A0 =C2=A0 =C2=A0 (Marc Blanchet)
=C2=A0 =C2=A04. Re: Welcome to the Discussion on Internet Storage Sync (Ted= Lemon)


---------- Forwarded message ----------
From:=C2=A0Linhui Sun &l= t;lh.sunlinh@gmai= l.com>
To:=C2=A0Ted Lemon <mellon@fugue.com>
Cc:=C2=A0"Songhaibin (A= )" <hai= bin.song@huawei.com>, storagesync <storagesync@ietf.org>, "qinxiaowei@cnnic.cn"= <qinxiaowei@cn= nic.cn>
Date:=C2=A0Wed, 2 Sep 2015 20:40:51 +0800
Subject:=C2= =A0Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync
=

= 2015-09-02 20:23 GMT+08:00 Ted Lemon <mellon@fugue.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On = Sep 2, 2015, at 7:40 AM, Linhui Sun <lh.sunlinh@gmail.com> wrote:
I think maybe we sho= uld make the definition of sync clearer. Could we explain it as a simple up= load/download process. Or the sync is specifically referred to the transfer= process of=C2=A0Network-based storage services which may employ several we= ll-known techniques (e.g. rsync)?

Personally I am not interested in a client/server sync protocol. =C2= =A0 What I would like is a sync protocol more like git, where each device h= as a history of the last time a sync happened, and can tell what has change= d since the last sync. =C2=A0 When two devices connect, they compare notes = and figure out what changes have to be made on both sides to reach a new ma= ster version. =C2=A0 This of course means that some conflict resolution pro= cess may be necessary. =C2=A0 It also means that if two devices connect to = a central server on a regular basis, they will be in sync with each other e= ven though they have never communicated.

[LH]: That is what we want to do in the IETF and is also what the= current storage services are trying to provide. Simple C/S protocol is not= satisfied.

I think this is a more useful par= adigm than something like rsync, but I realize that it=E2=80=99s a lot more= complicated, and may be beyond the scope of what the folks who proposed th= is mailing list intended. =C2=A0 Is it something you=E2=80=99d be intereste= d in pursuing, or should I go off and do it on my own? =C2=A0 :)
=
[LH]: I think rsync should not be conside= red as an essential part of such sync protocol. Not only because it is comp= licated. We usually find the rsync failed in some scenarios and sometimes c= auses extra sync traffic.



---------- Forwarded message ----------
From:=C2=A0Ted Lemon <= ;mellon@fugue.com= >
To:=C2=A0Marc Blanchet <marc.blanchet@viagenie.ca>
Cc:=C2=A0Linhui= Sun <lh.sunli= nh@gmail.com>, "Songhaibin (A)" <haibin.song@huawei.com>, stora= gesync <storag= esync@ietf.org>, "qinxiaowei@cnnic.cn" <qinxiaowei@cnnic.cn>
Date:=C2=A0Wed, = 2 Sep 2015 10:29:01 -0400
Subject:=C2=A0Re: [Storagesync] Welcome to the= Discussion on Internet Storage Sync
On Sep 2, 2015, at 8:07 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:=
I= =E2=80=99ve said to the organizers that I think a solution already implemen= ted and deployed is rsync over webdav for this. It should be looked at care= fully before reinventing a new protocol.

<= div>rsync is inadequate if you have changes on both ends or more than two c= opies of the sync=E2=80=99d data. =C2=A0 An rfc describing the rsync protoc= ol might be useful to someone, but I don=E2=80=99t think it=E2=80=99s inter= esting new work. =C2=A0 However, this question is certainly one that should= be answered in the requirements document. =C2=A0 Do you think rsync is ade= quate because you think that parallel updates aren=E2=80=99t important? =C2= =A0 It sounds like one motivation for this work is support for CDNs, and fo= r those something like rsync would be perfectly adequate, but that=E2=80=99= s not the use case I=E2=80=99m interested in. =C2=A0 Frankly, that seems li= ke a solved problem to me.



---------- For= warded message ----------
From:=C2=A0Marc Blanchet <marc.blanchet@viagenie.ca= >
To:=C2=A0Ted Lemon <mellon@fugue.com>
Cc:=C2=A0Linhui Sun <lh.sunlinh@gmail.com>= , "Songhaibin (A)" <haibin.song@huawei.com>, storagesync <storagesync@ietf.org= >, "qinxia= owei@cnnic.cn" <qinxiaowei@cnnic.cn>
Date:=C2=A0Wed, 02 Sep 2015 11:2= 6:53 -0400
Subject:=C2=A0Re: [Storagesync] Welcome to the Discussion on = Internet Storage Sync


On 2 Sep 2015, at 10:29, Ted Lemon wrote:

On Sep 2, 2015, at 8:07 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:<= br>
I=E2=80=99ve said to the organizers that I think a solution already impleme= nted and deployed is rsync over webdav for this. It should be looked at car= efully before reinventing a new protocol.

rsync is inadequate if you have changes on both ends or more than two copie= s of the sync=E2=80=99d data.=C2=A0 =C2=A0An rfc describing the rsync proto= col might be useful to someone, but I don=E2=80=99t think it=E2=80=99s inte= resting new work.=C2=A0 =C2=A0However, this question is certainly one that = should be answered in the requirements document.=C2=A0 =C2=A0Do you think r= sync is adequate because you think that parallel updates aren=E2=80=99t imp= ortant?=C2=A0 =C2=A0It sounds like one motivation for this work is support = for CDNs, and for those something like rsync would be perfectly adequate, b= ut that=E2=80=99s not the use case I=E2=80=99m interested in.=C2=A0 =C2=A0F= rankly, that seems like a solved problem to me.

well, that is my point, so we agree=E2=80=A6
- webdav+rsync is providing pretty good solution. therefore, it should be c= learly identified in the problem statement and also what it is not solving.=
- then we can discuss what other features (such as what you described) can = be worth technical work, spec, etc=E2=80=A6

Marc.



_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync




---------- Forwarded message ----------
From:=C2=A0Ted Lemon <= ;mellon@fugue.com= >
To:=C2=A0Marc Blanchet <marc.blanchet@viagenie.ca>
Cc:=C2=A0Linhui= Sun <lh.sunli= nh@gmail.com>, "Songhaibin (A)" <haibin.song@huawei.com>, stora= gesync <storag= esync@ietf.org>, "qinxiaowei@cnnic.cn" <qinxiaowei@cnnic.cn>
Date:=C2=A0Wed, = 2 Sep 2015 12:59:26 -0400
Subject:=C2=A0Re: [Storagesync] Welcome to the= Discussion on Internet Storage Sync
On Sep 2, 2015, at 11:26 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote= :
we= ll, that is my point, so we agree=E2=80=A6
- webdav+rsync is providing pretty good solution. therefore, it sho= uld be clearly identified in the problem statement and also what it is not = solving.
- then we can discuss what= other features (such as what you described) can be worth technical work, s= pec, etc=E2=80=A6

Ah, OK, thanks fo= r clarifying!


_______________________________= ________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync


_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync




--
You= rs sincerely
LZQ
--94eb2c07d65ae8fceb051f42b768-- From nobody Tue Sep 8 18:19:00 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70F51A88F9 for ; Tue, 8 Sep 2015 18:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJBQiswJtkeS for ; Tue, 8 Sep 2015 18:18:56 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 975931B30CF for ; Tue, 8 Sep 2015 18:18:51 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.29]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5pnH2iO9VBVDCBw--.25236S2; Wed, 09 Sep 2015 09:18:46 +0800 (CST) Date: Wed, 9 Sep 2015 09:18:31 +0800 From: "qinxiaowei@cnnic.cn" To: storagesync X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <201509090918313010274@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart035738076768_=----" X-CM-TRANSID: AQAAf0B5pnH2iO9VBVDCBw--.25236S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCr18tr4xGw47CrW7CF1xKrg_yoW5Gryxpa y8XrZ5Jas7Aw4xKrs2qwnYqFy5u3WrW3yIgFnrtr1Yy3s8tF1jgw1xKw4fWrW7urWUWFWq qr40va1avw1FqrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQSb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjc xK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG 6xAIxVCFxsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzxvEb7x7Mc02F40Ex2IqxVA2Yx Cjr7Iv64kEw24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvj eVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4 xvF2IEb7IF0Fy26I8I3I1lc2xSY4AK67AK6w4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC 6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWw C2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_ JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr 1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l 6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUchihUUUUU X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: [Storagesync] Fw: New Version Notification for draft-qin-appsawg-uatn-ut-00.txt X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 01:18:58 -0000 This is a multi-part message in MIME format. ------=_001_NextPart035738076768_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBmb2xrcywNCiAgIEkgcHJvcG9zZWQgYW4gYXBwcm9hY2ggdG8gdXBsb2FkIGFjY2VsZXJh dGlvbiB0cmFuc3BvcnQgbmV0d29yayBmb3IgdXBzdHJlYW0gdHJhZmZpY3MsIGFuZCB0aGUgZHJh ZnQgd2FzIHN1Ym1pdHRlZCB0byB0aGUgQVBQU0FXRy4NCkFueSBjb21tZW50cyBhcmUgd2VsY29t ZS4NCg0KTGluazogIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1x aW4tYXBwc2F3Zy11YXRuLXV0LTAwLnR4dA0KDQpSZWdhcmRzLA0KDQpYaWFvd2VpIFFpbg0KDQoN Cg0KIA0KRnJvbTogaW50ZXJuZXQtZHJhZnRzDQpEYXRlOiAyMDE1LTA4LTA1IDE1OjUwDQpUbzog WGlhb0RvbmcgTGVlOyBYaWFvd2VpIFFpbjsgWGlhb2RvbmcgTGVlOyBYaWFvd2VpIFFpbjsgTmlu ZyBLb25nOyBOaW5nIEtvbmcNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtcWluLWFwcHNhd2ctdWF0bi11dC0wMC50eHQNCiANCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1xaW4tYXBwc2F3Zy11YXRuLXV0LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBYaWFvd2VpIFFpbiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0 b3J5Lg0KIA0KTmFtZTogZHJhZnQtcWluLWFwcHNhd2ctdWF0bi11dA0KUmV2aXNpb246IDAwDQpU aXRsZTogVXBsb2FkIEFjY2VsZXJhdGlvbiBUcmFuc3BvcnQgTmV0d29yayBmb3IgVXBzdHJlYW0g VHJhZmZpY3MgDQpEb2N1bWVudCBkYXRlOiAyMDE1LTA4LTA1DQpHcm91cDogSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpQYWdlczogMTUNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcWluLWFwcHNhd2ctdWF0bi11dC0wMC50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xaW4tYXBw c2F3Zy11YXRuLXV0Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1xaW4tYXBwc2F3Zy11YXRuLXV0LTAwDQogDQogDQpBYnN0cmFjdDoNCiAgIE1vdmlu ZyBkYXRhIGNlbnRlciBjbG9zZXIgdG8gZW5kIHVzZXJzIGNhbiBwcm92aWRlIG51bWVyb3VzIGJl bmVmaXRzDQogICBmb3IgcHJlLXVwbG9hZGVkIGNvbnRlbnQ6IGxvd2VyIGxhdGVuY3ksIGluY3Jl YXNlZCByb2J1c3RuZXNzIG9mDQogICBkZWxpdmVyeSwgYW5kIGltcHJvdmVkIHF1YWxpdHkgb2Yg dXNlciBleHBlcmllbmNlLiAgRm9yIHRoZXNlDQogICByZWFzb25zLCBtYW55IE9ubGluZSBTdG9y YWdlIFNlcnZpY2UgUHJvdmlkZXJzKE9TU1BzKSxQaG90b3MgU2hhcmluZw0KICAgU2VydmljZSBQ cm92aWRlcnMgKFBTU1BzKSwgYW5kIFZpZGVvcyBTaGFyaW5nIFNlcnZpY2UNCiAgIFByb3ZpZGVy cyhWU1NQcyksIGV0Yy4sIGFyZSBzY2FsaW5nIHVwIHRoZWlyIGluZnJhc3RydWN0dXJlLCBhbmQg bWFueQ0KICAgYWJvdmUgVXBsb2FkIFNlcnZpY2UgUHJvdmlkZXJzKFVTUHMpYXJlIGFsc28gZGVw bG95aW5nIHRoZWlyIG93bg0KICAgY2xvdWQgcGxhdGZvcm1zIHRvIGltcHJvdmUgZGF0YSB1cGxv YWQgcmF0ZS4gIEl0IGlzIGdlbmVyYWxseQ0KICAgZGVzaXJhYmxlIHRoYXQgYSBnaXZlbiBjb250 ZW50IGl0ZW0gZ2VuZXJhdGVkIGJ5IGVuZCB1c2VycyBjYW4gYmUNCiAgIHF1aWNrbHkgYW5kIHJv YnVzdGx5IGRlbGl2ZXJlZCB0byB0aGUgZGVzdGluYXRpb24gcmVnYXJkbGVzcyBvZiB0aGF0DQog ICBlbmQgdXNlcidzIGxvY2F0aW9uIG9yIGF0dGFjaG1lbnQgbmV0d29yay4gIFRoaXMgaXMgdGhl IG1vdGl2YXRpb24NCiAgIGZvciBkZXBsb3lpbmcgVXBsb2FkIEFjY2VsZXJhdGlvbiBUcmFuc3Bv cnQgTmV0d29yayhVQVROKSBzbyBpdCBjYW4NCiAgIHByb3Bvc2UgYW4gb3BlbiBjb250ZW50IGRl bGl2ZXJ5IGluZnJhc3RydWN0dXJlIGZvciB0aGUgZW5kLXRvLWVuZA0KICAgZGVsaXZlcnkgb2Yg Y29udGVudCBmcm9tIGVuZCB1c2VycyB0byB0aGUgZGVzdGluYXRpb24oZGF0YSBjZW50ZXIgb3IN CiAgIGFub3RoZXIgZW5kIHVzZXIsIGV0Yy4pLiAgSG93ZXZlciwgbm8gc3RhbmRhcmRzIG9yIG9w ZW4NCiAgIHNwZWNpZmljYXRpb25zIGN1cnJlbnRseSBleGlzdCB0byBmYWNpbGl0YXRlIHN1Y2gg YW4gdXBsb2FkDQogICBhY2NlbGVyYXRpb24gbWVjaGFuaXNtLg0KIA0KICAgVGhlIGdvYWwgb2Yg dGhpcyBkb2N1bWVudCBpcyB0byBleHBsYWluIHRoZSBwcm9wb3NlZCBVQVROIGluIGRldGFpbA0K ICAgZm9yIHByb3ZpZGluZyBwdWJsaWMgdXBsb2FkIGFjY2VsZXJhdGlvbiBzZXJ2aWNlIGFuZCBp bnRlcmNvbm5lY3QNCiAgIGV4aXN0aW5nIHVwbG9hZCBhY2NlbGVyYXRpb24gc3lzdGVtcyBhcyBh biBvcGVuIGNvbnRlbnQgZGVsaXZlcnkNCiAgIGluZnJhc3RydWN0dXIuDQogDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogDQogDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K IA0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCiANCg== ------=_001_NextPart035738076768_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
= Dear folks,
   I proposed an approach to up= load acceleration transport network for upstream traffics, and the draft was submitted to the APPSAWG.
Any commen= ts are welcome.

Link:  http= s://www.ietf.org/internet-drafts/draft-qin-appsawg-uatn-ut-00.txt

Regards,

Xiaowei Qi= n
=0A

=0A
=0A
 
From:<= /b> internet-drafts
Date: 2015-08-05 15:50
Subject: New Version Notification for dr= aft-qin-appsawg-uatn-ut-00.txt
 
=0A<= div>A new version of I-D, draft-qin-appsawg-uatn-ut-00.txt
=0A
ha= s been successfully submitted by Xiaowei Qin and posted to the
=0AIETF repository.
=0A
 
=0A
Name: draft-qin-appsa= wg-uatn-ut
=0A
Revision: 00
=0A
Title: Upload Accelerat= ion Transport Network for Upstream Traffics
=0A
Document date: 2= 015-08-05
=0A
Group: Individual Submission
=0A
Pages: = 15
=0A
URL:         =    https://www.ietf.org/internet-drafts/draft-qin-appsawg-uatn-u= t-00.txt
=0A
Status:       &nb= sp; https://datatracker.ietf.org/doc/draft-qin-appsawg-uatn-ut/
=0AHtmlized:       https://tools.ietf.org/ht= ml/draft-qin-appsawg-uatn-ut-00
=0A
 
=0A
 =0A
Abstract:
=0A
   Moving data center closer t= o end users can provide numerous benefits
=0A
   for pr= e-uploaded content: lower latency, increased robustness of
=0A
&n= bsp;  delivery, and improved quality of user experience.  For th= ese
=0A
   reasons, many Online Storage Service Provide= rs(OSSPs),Photos Sharing
=0A
   Service Providers (PSSP= s), and Videos Sharing Service
=0A
   Providers(VSSPs),= etc., are scaling up their infrastructure, and many
=0A
 &n= bsp; above Upload Service Providers(USPs)are also deploying their own=0A
   cloud platforms to improve data upload rate.  I= t is generally
=0A
   desirable that a given content it= em generated by end users can be
=0A
   quickly and rob= ustly delivered to the destination regardless of that
=0A
 &= nbsp; end user's location or attachment network.  This is the motivat= ion
=0A
   for deploying Upload Acceleration Transport = Network(UATN) so it can
=0A
   propose an open content = delivery infrastructure for the end-to-end
=0A
   deliv= ery of content from end users to the destination(data center or
=0A   another end user, etc.).  However, no standards or op= en
=0A
   specifications currently exist to facilitate = such an upload
=0A
   acceleration mechanism.
=0A<= div> 
=0A
   The goal of this document is to expla= in the proposed UATN in detail
=0A
   for providing pub= lic upload acceleration service and interconnect
=0A
  = existing upload acceleration systems as an open content delivery
=0A=
   infrastructur.
=0A
 
=0A
 &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;     
=0A
 
=0A
 = ;
=0A
Please note that it may take a couple of minutes from the t= ime of submission
=0A
until the htmlized version and diff are ava= ilable at tools.ietf.org.
=0A
 
=0A
The IETF Secret= ariat
=0A
 
=0A
=0A
=0A ------=_001_NextPart035738076768_=------ From nobody Wed Sep 9 03:09:43 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDD11B3417 for ; Wed, 9 Sep 2015 03:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.411 X-Spam-Level: * X-Spam-Status: No, score=1.411 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-GYKcGxgI6B for ; Wed, 9 Sep 2015 03:09:40 -0700 (PDT) Received: from tsinghua.edu.cn (smtp09.tsinghua.edu.cn [166.111.204.38]) by ietfa.amsl.com (Postfix) with ESMTP id 934D31B3412 for ; Wed, 9 Sep 2015 03:09:38 -0700 (PDT) Received: from mail-ig0-f177.google.com (unknown [209.85.213.177]) by app1 (Coremail) with SMTP id CsxvpgC3vPBeBfBVWoYTAQ--.13048S2; Wed, 09 Sep 2015 18:09:35 +0800 (CST) Received: by igcrk20 with SMTP id rk20so96038548igc.1 for ; Wed, 09 Sep 2015 03:09:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.46.65 with SMTP id t1mr48112306igm.25.1441793374201; Wed, 09 Sep 2015 03:09:34 -0700 (PDT) Received: by 10.64.163.73 with HTTP; Wed, 9 Sep 2015 03:09:34 -0700 (PDT) In-Reply-To: <2BD03E33-4F3B-43E8-8A9A-BEA4E3415FD3@fugue.com> References: <2015090116520811787510@cnnic.cn> <201509021025084691715@cnnic.cn> <812036C8-FF08-433F-A8E5-9100DAEC040A@fugue.com> <2BD03E33-4F3B-43E8-8A9A-BEA4E3415FD3@fugue.com> Date: Wed, 9 Sep 2015 18:09:34 +0800 Message-ID: From: Zhenhua Li To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11346c8ee8ba4b051f4dad06 X-CM-TRANSID: CsxvpgC3vPBeBfBVWoYTAQ--.13048S2 X-Coremail-Antispam: 1UD129KBjvJXoWxGr4fCr47ZFW3ZFWUXr4rGrg_yoW5tFyfpa yUXr45Kr4kKr4fC397Aw1I9r1FvrZxArZ8G3Z8tw17Ary5JFy0qw4xta1ruFZrArZ3C3Wj qFWY9Fy5Gw1kZ3DanT9S1TB71UUUUbUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUB0b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAaw2AFwI0_JF0_Jw1lnxkEFVAIw20F6cxK64vIFxWle2I262IYc4CY6c8Ij28IcVAa Y2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2I x0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8 JwCY1x0262kKe7AKxVWUAVWUtwCY1Ik267vv6cIUMxkIecxEwVCI4VW8twCF04k20xvY0x 0EwIxGrwCFI7km07C267AKxVWUXVWUAwC20s026c02F40E14v26r106r1rMI8I3I0E7480 Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7 IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k2 6cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x 0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvj7UU6EPUUUUU X-CM-SenderInfo: xol2xv5qkxtiazytq3pvlqwxlxdovvfxof0/ Archived-At: Cc: Linhui Sun , "Songhaibin \(A\)" , storagesync , "qinxiaowei@cnnic.cn" Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 10:09:43 -0000 --001a11346c8ee8ba4b051f4dad06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, I'm Zhenhua Li, who has been investigating cloud storage services for several years at Tsinghua University. I used to make a horizontal comparison of the network-level efficiency for cloud storage services, and the resulting paper is published in ACM IMC'14 conference: http://www.greenorbs.org/people/lzh/papers/[IMC'14]%20Cloud%20Sync%20TUE.pd= f Besides, I also made an in-depth study of the data sync process for Dropbox-like cloud storage services, and the resulting paper is published in ACM Middleware'13 conference: http://www.greenorbs.org/people/lzh/papers/[Middleware'13]%20Dropbox.pdf In my opinion, ISS (Internet Storage Sync) services lie between rsync and git/svn/WebDAV for two reasons: 1) rsync cannot satisfy the requirements of ISS even under today's typical application scenarios (let alone other potential scenarios in the future). Several technical papers have reported the performance issues of rsync, including Prof. Yong Cui's MobiCom'15 paper and my IMC'14 and Middleware'13 paper. Thus, the design of ISS is more complicated that rsync. 2) ISS should be less complicated than git/svn/WebDAV. First, I agree with others' opinion that ISS is mostly used for syncing (possibly large) files rather than only small documents. Second, most files hosted by ISS would not be frequently modified, or are not expected to be written such as image, audio, or video files. As a result, the application scenarios of ISS are different from git/svn/WebDAV. Of course, ISS can provide some simplified "version rollback" functions as what Dropbox have done. My two cents :) Zhenhua On Wed, Sep 2, 2015 at 8:23 PM, Ted Lemon wrote: > On Sep 2, 2015, at 7:40 AM, Linhui Sun wrote: > > I think maybe we should make the definition of sync clearer. Could we > explain it as a simple upload/download process. Or the sync is specifical= ly > referred to the transfer process of Network-based storage services which > may employ several well-known techniques (e.g. rsync)? > > > Personally I am not interested in a client/server sync protocol. What I > would like is a sync protocol more like git, where each device has a > history of the last time a sync happened, and can tell what has changed > since the last sync. When two devices connect, they compare notes and > figure out what changes have to be made on both sides to reach a new mast= er > version. This of course means that some conflict resolution process may > be necessary. It also means that if two devices connect to a central > server on a regular basis, they will be in sync with each other even thou= gh > they have never communicated. > > I think this is a more useful paradigm than something like rsync, but I > realize that it=E2=80=99s a lot more complicated, and may be beyond the s= cope of > what the folks who proposed this mailing list intended. Is it something > you=E2=80=99d be interested in pursuing, or should I go off and do it on = my own? > :) > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --=20 Zhenhua Li, homepage: http://www.greenorbs.org/people/lzh/ Associate Researcher, GreenOrbs - Cloud Computing Group, TNLIST, Tsinghua University PostDoc, School of Software, Tsinghua University, Beijing, China Email: lizhenhua1983@tsinghua.edu.cn, lizhenhua1983@gmail.com Phone: +86-13552819836 (@Beijing) --001a11346c8ee8ba4b051f4dad06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

I'm Zhenhua Li, who has b= een investigating cloud storage services for several years at Tsinghua Univ= ersity.
I used to make a horizontal comparison of the network-lev= el efficiency for cloud storage services, and the resulting paper is publis= hed in ACM IMC'14 conference:=C2=A0http://www.greenor= bs.org/people/lzh/papers/[IMC'14]%20Cloud%20Sync%20TUE.pdf=C2=A0
Besides, I also made an in-depth study of the data sync process for= Dropbox-like cloud storage services, and the resulting paper is published = in ACM Middleware'13 conference:=C2=A0http://www.greenorb= s.org/people/lzh/papers/[Middleware'13]%20Dropbox.pdf
In my opinion, ISS (Internet Storage Sync) services lie between= rsync and git/svn/WebDAV for two reasons:

1) rsyn= c cannot satisfy the requirements of ISS even under today's typical app= lication scenarios (let alone other potential scenarios in the future).=C2= =A0
Several technical papers have reported the performance issues= of rsync, including Prof. Yong Cui's MobiCom'15 paper and my IMC&#= 39;14 and Middleware'13 paper.
Thus, the design of ISS is mor= e complicated that rsync.

2) ISS should be less co= mplicated than git/svn/WebDAV. First, I agree with others' opinion that= ISS is mostly used for syncing (possibly large) files rather than only sma= ll documents.=C2=A0
Second, most files hosted by ISS would not be= frequently modified, or are not expected to be written such as image, audi= o, or video files.=C2=A0
As a result, the application scenarios o= f ISS are different from git/svn/WebDAV.=C2=A0
Of course, ISS can= provide some simplified "version rollback" functions as what Dro= pbox have done.

My two cents :) =C2=A0 =C2=A0

Zhenhua

On Wed, Sep 2, 2015 at 8:23 PM, Ted Lemon <mellon@f= ugue.com> wrote:
On Sep 2, 2015, at 7:40 AM, Li= nhui Sun <lh.s= unlinh@gmail.com> wrote:
I think maybe we should make the= definition of sync clearer. Could we explain it as a simple upload/downloa= d process. Or the sync is specifically referred to the transfer process of= =C2=A0Network-based storage services which may employ several well-known te= chniques (e.g. rsync)?

Perso= nally I am not interested in a client/server sync protocol. =C2=A0 What I w= ould like is a sync protocol more like git, where each device has a history= of the last time a sync happened, and can tell what has changed since the = last sync. =C2=A0 When two devices connect, they compare notes and figure o= ut what changes have to be made on both sides to reach a new master version= . =C2=A0 This of course means that some conflict resolution process may be = necessary. =C2=A0 It also means that if two devices connect to a central se= rver on a regular basis, they will be in sync with each other even though t= hey have never communicated.

I think this is a mor= e useful paradigm than something like rsync, but I realize that it=E2=80=99= s a lot more complicated, and may be beyond the scope of what the folks who= proposed this mailing list intended. =C2=A0 Is it something you=E2=80=99d = be interested in pursuing, or should I go off and do it on my own? =C2=A0 := )


___________________________________________= ____
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync




--
Zhenhua Li, =C2=A0 homepage:=C2=A0<= a href=3D"http://www.greenorbs.org/people/lzh/" target=3D"_blank">http://ww= w.greenorbs.org/people/lzh/
Associate Researcher, GreenOrbs - Cloud = Computing Group, TNLIST, Tsinghua University
PostDoc, School of Software= , Tsinghua University, Beijing, China
Email: lizhenhua1983@tsinghua.edu.cn,= =C2=A0lizhenhu= a1983@gmail.com
Phone: +86-13552819836 (@Beijing)
--001a11346c8ee8ba4b051f4dad06-- From nobody Wed Sep 9 03:18:37 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27781B3658 for ; Wed, 9 Sep 2015 03:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_aJd1sz5tcz for ; Wed, 9 Sep 2015 03:18:33 -0700 (PDT) Received: from tsinghua.edu.cn (smtp09.tsinghua.edu.cn [166.111.204.38]) by ietfa.amsl.com (Postfix) with ESMTP id A0A761B3648 for ; Wed, 9 Sep 2015 03:18:32 -0700 (PDT) Received: from mail-io0-f181.google.com (unknown [209.85.223.181]) by app5 (Coremail) with SMTP id DsxvpgDnyRJzB_BVBrXRAA--.13039S2; Wed, 09 Sep 2015 18:18:28 +0800 (CST) Received: by ioiz6 with SMTP id z6so16262399ioi.2 for ; Wed, 09 Sep 2015 03:18:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.19.70 with SMTP id b67mr46531573ioj.144.1441793907413; Wed, 09 Sep 2015 03:18:27 -0700 (PDT) Received: by 10.64.163.73 with HTTP; Wed, 9 Sep 2015 03:18:27 -0700 (PDT) In-Reply-To: References: <2015090116520811787510@cnnic.cn> Date: Wed, 9 Sep 2015 18:18:27 +0800 Message-ID: From: Zhenhua Li To: Linhui Sun Content-Type: multipart/alternative; boundary=001a113dea22b0e126051f4dcdb1 X-CM-TRANSID: DsxvpgDnyRJzB_BVBrXRAA--.13039S2 X-Coremail-Antispam: 1UD129KBjvJXoWxGr47tFyDtFy5tFW5Jr4fKrg_yoW5KFW3pF 43Jry3Gr4UKFW7Gw1kJr1jvr10yry5KrW5Grn8Jr18Ary5AFyjqw1xtr4FyrWUJr93Gr4S qr17WF15Gw1UZFJanT9S1TB71UUUUUDqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmab7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_ Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2vYz4IE04k24VAvwVAKI4IrM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xv s2x26I8E6xACxx1l5I8CrVAaz4v26cxKscIFY7kG0wAqx4xG64xvF2IEw4CE5I8CrVC2j2 Wl5I8CrVC2j2CEjI02ccxYII8I67AEr4CY67k08wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv 7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UMx8GjcxK6IxK0xIIj40E5I 8CrwCY1Ik267vv6cIUMxkIecxEwVCI4VW8twCF04k20xvY0x0EwIxGrwCFI7km07C267AK xVWUAVWUtwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr 1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsG vfC2KfnxnUUI43ZEXa7xUUe_BUUUUUU== X-CM-SenderInfo: xol2xv5qkxtiazytq3pvlqwxlxdovvfxof0/ Archived-At: Cc: storagesync , "qinxiaowei@cnnic.cn" Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 10:18:36 -0000 --001a113dea22b0e126051f4dcdb1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Linhui, I suggest we consider an additional problem, *Key Metrics for Internet Storage Sync*. At the moment, we even don't know what are the key metrics to correctly evaluate an Internet Storage Sync service/operation. For your reference :) Zhenhua On Tue, Sep 1, 2015 at 9:09 PM, Linhui Sun wrote: > Hi Xiaowei, > > Thanks for sharing your thoughts. I think the things you mentioned are no= t > conflicting when considering the standardization of sync protocol. If we > could come up with an open and standard sync protocol, the third-party AP= Is > could be significantly simplified. And it is reasonable and necessary tha= t > such standard sync protocol should pay more attention to the sync > efficiency to allow users have an ideal upload rate. > > Any comments? > > Actually we outline five different problems in the problem statement > draft. Problem 4 and 5 reveals why most existing proprietary sync protoco= ls > do not have a satisfactory sync efficiency (e.g. poor performance on uplo= ad > rate). > > 1) *Complicated Support for APIs* > 2) *Unavailable Cross-service Sync* > 3) *Redundant Similar Clients* > 4) *Different Capability Configurations and Implementations* > 5) *Challenges in Mobile and Wireless Environments * > (More detailed descriptions could be found in: > http://datatracker.ietf.org/doc/draft-cui-iss-problem/) > > In addition, I think the most urgent task of this Non-WG list is to have > an agreement on the specified problems and the scope of work. Thus may I > ask the people in this list to share your thoughts on the problems and > scope of work? Which problem do you think is not required or is there any > other problems we haven't mentioned in the draft? Please feel free to > comment on it. > > Best regards, > Linhui > > 2015-09-01 16:52 GMT+08:00 qinxiaowei@cnnic.cn : > >> hi, >> Third-party API and optimizing the sync protocols may be important for >> Online storage. But, IMO, the most important is improving data upload ra= te >> that end users can obtain. >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------= ---------------------------------------------------------------------------= ----------------------------------------- >> >> Hi folks, >> Welcome to the mailing list of Internet Storage Sync (Storagesync@ietf.o= rg). This list is for the discussions of Internet Storage Sync work. You ar= e welcome to introduce yourself here and start related discussions. >> We've produced a draft to outline the main problems in existing Internet= storage services, please find the document with the following link. Please= feel free to comment on it and your valuable comments are more than welcom= e.http://datatracker.ietf.org/doc/draft-cui-iss-problem/ >> A wiki for some useful resources and links could be found. Please feel f= ree to edit it or let us know if we've missed something. https://github.com= /iss-ietf/iss/wiki/Internet-Storage-Sync/ >> Regards, >> Yong Cui, >> Professor, Tsinghua University, Beijing, China >> Associate Editor on IEEE TPDS, IEEE TCC >> URL: http://www.4over6.edu.cn/cuiyong/index.html >> >> >> ------------------------------ >> >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/storagesync >> >> > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --=20 Zhenhua Li, homepage: http://www.greenorbs.org/people/lzh/ Associate Researcher, GreenOrbs - Cloud Computing Group, TNLIST, Tsinghua University PostDoc, School of Software, Tsinghua University, Beijing, China Email: lizhenhua1983@tsinghua.edu.cn, lizhenhua1983@gmail.com Phone: +86-13552819836 (@Beijing) --001a113dea22b0e126051f4dcdb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Linhui,

I suggest we consider an add= itional problem, Key Metrics for Internet Storage Sync.
At= the moment, we even don't know what are the key metrics to correctly e= valuate an Internet Storage Sync service/operation.=C2=A0

For your reference :)

Zhenhua
<= div class=3D"gmail_extra">
On Tue, Sep 1, 201= 5 at 9:09 PM, Linhui Sun <lh.sunlinh@gmail.com> wrote:
Hi Xiaowei,

=
Thanks for sharing your thoughts. I think the things you mentioned are= not conflicting when considering the standardization of sync protocol. If = we could come up with an open and standard sync protocol, the third-party A= PIs could be significantly simplified. And it is reasonable and necessary t= hat such standard sync protocol should pay more attention to the sync effic= iency to allow users have an ideal upload rate.

An= y comments?

Actually we outline five different pro= blems in the problem statement draft. Problem 4 and 5 reveals why most exis= ting proprietary sync protocols do not have a=C2=A0satisfactory sync effici= ency (e.g. poor performance on upload rate).

1) Complicated Support for APIs
2) Unavailable Cross-ser= vice Sync
3) Redundant Similar Clients
4) Different Capability Configurations and Implementations
5) Challenges in Mobile and Wireless Environments=C2=A0
<= /div>
(More detailed descriptions could be found in:=C2=A0htt= p://datatracker.ietf.org/doc/draft-cui-iss-problem/)

In addition, I think the most urgent task of this Non-WG list is to = have an agreement on the specified problems and the scope of work. Thus may= I ask the people in this list to share your thoughts on the problems and s= cope of work? Which problem do you think is not required or is there any ot= her problems we haven't mentioned in the draft? Please feel free to com= ment on it.

Best regards,
Linhui

2015-09-01 16:52 GMT+08:00 qinxiaowei@cnnic.cn <qinxiaowei@cnnic.cn>= :
hi,=C2=A0
Third-party API and optimizing the sync protocols may be important for On= line storage. But, IMO, the most important is improving data upload rate th= at end users can obtain.






---= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -----------------------------------
Hi folks,
Welcome to the mailing list of Internet Storage Sync (Storagesync@ietf.org). This list i=
s for the discussions of Internet Storage Sync work. You are welcome to int=
roduce yourself here and start related discussions.
We've produced a draft to outline the main problems in existing Interne=
t storage services, please find the document with the following link. Pleas=
e feel free to comment on it and your valuable comments are more than welco=
me.
http://datatracker.ietf.org/doc/draft-cui-iss-problem/
A wiki for some useful resources and links could be found. Please feel free=
 to edit it or let us know if we've missed something.=20
https://github.com/iss-ietf/iss/wiki/Internet-Storage-Sync/<=
/a>
Regards,
Yong Cui,
Professor, Tsinghua University, Beijing, China
Associate Editor on IEEE TPDS, IEEE TCC
URL: http://www.4over6.edu.cn/cuiyong/index.html


______________________________________________= _
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync



_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync




--
Zhenhua Li, =C2=A0 homepage:=C2=A0<= a href=3D"http://www.greenorbs.org/people/lzh/" target=3D"_blank">http://ww= w.greenorbs.org/people/lzh/
Associate Researcher, GreenOrbs - Cloud = Computing Group, TNLIST, Tsinghua University
PostDoc, School of Software= , Tsinghua University, Beijing, China
Email: lizhenhua1983@tsinghua.edu.cn,= =C2=A0lizhenhu= a1983@gmail.com
Phone: +86-13552819836 (@Beijing)
--001a113dea22b0e126051f4dcdb1-- From nobody Wed Sep 9 03:51:49 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B340B1AC41B for ; Wed, 9 Sep 2015 03:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC9OvqJO2EgP for ; Wed, 9 Sep 2015 03:51:43 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9B41A89AB for ; Wed, 9 Sep 2015 03:51:43 -0700 (PDT) Received: by ykcf206 with SMTP id f206so8392300ykc.3 for ; Wed, 09 Sep 2015 03:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/Q7XQing/4vtdiAarFnYK/2W1OZFHp+bfKHQHrovwyQ=; b=QnPpwatBHyE84vS3lcBoacVacMs5QjGcbzfML1xqvco/jU4blNn5h8ghH+TOONLAiE IdvFjzhUwFh3Je1WCZ2+7uu8laXQQOPqTdyL1K05parXIysf3uiEI5w+9QWys3SMNgKx rcIVqVjr9ONo0T34L3QR9gaiAPYU9qpA8NhB9R1YzEgZdE8ho+VfnXt9fbXCsmiQodU7 2eCG4WUPtiz0iM285EuqsOfRNtwour3Bcc07m4W8q/7eL1aG2OZj6dc3BTuGoBoe2KCS 26vsf3cZGv3JEuB7ut/ZdwbS3Fhn+TPDo7yFGeynZ1ejfPMUeEA8HfwTDlBexbdcHjW3 p7aA== MIME-Version: 1.0 X-Received: by 10.13.255.2 with SMTP id p2mr36868503ywf.115.1441795902537; Wed, 09 Sep 2015 03:51:42 -0700 (PDT) Received: by 10.37.210.17 with HTTP; Wed, 9 Sep 2015 03:51:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Sep 2015 12:51:42 +0200 Message-ID: From: ZeQi Lai To: storagesync@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0888f69c085d051f4e4461 Archived-At: Cc: Linhui Sun , Yong Cui Subject: Re: [Storagesync] Storagesync Digest, Vol 2, Issue 7 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 10:51:47 -0000 --94eb2c0888f69c085d051f4e4461 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Ted and Marc: I think WebDAV is originally designed for authoring and versioning. It allows users to collaboratively edit and manage files on remote web services. However it does not consider how to make transmission efficient. For example if we modify a small portion of a large file in local device, WebDAV needs to upload the full file to the server. Of course we can combine WebDAV with rsync to improve the transmission efficiency. However I think this is still inadequate. As we mentioned previously, in a cloud storage system files are split into chunks. The rsync algorithm is designed to find the delta content between two files. rsync works well in file granularity, but we need an approach that can work in chunk granularity, and find the delta of two file versions even though they are split into many chunks. Besides, there are some other techniques (e.g. deduplication, bundling and compression) that can be used to speed up transmission for cloud storage services. Deduplication is to avoid the transmission of files that already exist in the server. These techniques are complemented with rsync. Overall, we think the existed solution (e.g. WebDAV+rsync) is inadequate. We hope to design a standard sync protocol combining and extending existed techniques to efficiently synchronize data between client and server. We also think the approach to merge parallel changes on two ends is very important and should be considered in the sync protocol. Best regards, Zeqi Lai On Tue, Sep 8, 2015 at 11:05 PM, wrote: > Send Storagesync mailing list submissions to > storagesync@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/storagesync > or, via email, send a message with subject or body 'help' to > storagesync-request@ietf.org > > You can reach the person managing the list at > storagesync-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Storagesync digest..." > > Today's Topics: > > 1. Re: Storagesync Digest, Vol 2, Issue 6 (ZeQi Lai) > > > ---------- Forwarded message ---------- > From: ZeQi Lai > To: storagesync@ietf.org > Cc: Linhui Sun , Yong Cui > Date: Tue, 8 Sep 2015 23:04:57 +0200 > Subject: Re: [Storagesync] Storagesync Digest, Vol 2, Issue 6 > Hi Ted and Marc, > > I am Zeqi Lai from Tsinghua University. > > Thanks for your suggestions! We would identify this in the problem > statement later. However, I'd like to express some different viewpoints > about the rsync over webdav first. Actually, I do not think rsync+WebDAV = is > not as good as it looks for several reasons. > > 1) WebDAV is not suitable for large files, e.g. a HD movie. Also WeDAV > does not work well in mobile/wireless environments (high RTT/loss, > intermittent connections). Temporary loss of connection may lead to sync > failure. > > 2) There exists other capabilities (i.e. chunking, deduplication, > bundling, compression) that can be used to speed up data sync. Current > WebDAV does not consider these useful capabilities. > > 3) The limitation of rsync. Another point is that rsync works in the file > granularity. That requires the entities running on two ends must have > access to the entire file. However, to achieve better scalability, curren= t > network-based storage services split files into chunks and store them > distributedly (chunk granularity). Directly using rsync needs to > piece together all chunks to construct the whole file and would waste > massive intra-cluster bandwidth. > > In summary, the sync protocol what we'd like to do is something more than > rsync/webdav. As for the features Ted mentioned (e.g. parallel update), w= e > haven't considered them a lot at first. After several recent discussions, > we think they are really important and worth the effort. We'd like to see > how many people have interests in those features? How many people think > those features should be the core issue rather than improving the sync > efficiency? And then we could update the problem statement and produce an > appropriate charter : ) > > Best regards, > Zeqi Lai > > On Thu, Sep 3, 2015 at 9:00 PM, wrote: > >> Send Storagesync mailing list submissions to >> storagesync@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/storagesync >> or, via email, send a message with subject or body 'help' to >> storagesync-request@ietf.org >> >> You can reach the person managing the list at >> storagesync-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Storagesync digest..." >> >> Today's Topics: >> >> 1. Unsubscribe (David Noveck) >> >> >> ---------- Forwarded message ---------- >> From: David Noveck >> To: storagesync@ietf.org >> Cc: >> Date: Wed, 2 Sep 2015 15:02:41 -0400 >> Subject: [Storagesync] Unsubscribe >> On Sep 2, 2015 3:00 PM, wrote: >> >>> Send Storagesync mailing list submissions to >>> storagesync@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/storagesync >>> or, via email, send a message with subject or body 'help' to >>> storagesync-request@ietf.org >>> >>> You can reach the person managing the list at >>> storagesync-owner@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Storagesync digest..." >>> >>> Today's Topics: >>> >>> 1. Re: Welcome to the Discussion on Internet Storage Sync >>> (Linhui Sun) >>> 2. Re: Welcome to the Discussion on Internet Storage Sync (Ted Lemon= ) >>> 3. Re: Welcome to the Discussion on Internet Storage Sync >>> (Marc Blanchet) >>> 4. Re: Welcome to the Discussion on Internet Storage Sync (Ted Lemon= ) >>> >>> >>> ---------- Forwarded message ---------- >>> From: Linhui Sun >>> To: Ted Lemon >>> Cc: "Songhaibin (A)" , storagesync < >>> storagesync@ietf.org>, "qinxiaowei@cnnic.cn" >>> Date: Wed, 2 Sep 2015 20:40:51 +0800 >>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storag= e >>> Sync >>> >>> 2015-09-02 20:23 GMT+08:00 Ted Lemon : >>> >>>> On Sep 2, 2015, at 7:40 AM, Linhui Sun wrote: >>>> >>>> I think maybe we should make the definition of sync clearer. Could we >>>> explain it as a simple upload/download process. Or the sync is specifi= cally >>>> referred to the transfer process of Network-based storage services whi= ch >>>> may employ several well-known techniques (e.g. rsync)? >>>> >>>> >>>> Personally I am not interested in a client/server sync protocol. Wha= t >>>> I would like is a sync protocol more like git, where each device has a >>>> history of the last time a sync happened, and can tell what has change= d >>>> since the last sync. When two devices connect, they compare notes an= d >>>> figure out what changes have to be made on both sides to reach a new m= aster >>>> version. This of course means that some conflict resolution process = may >>>> be necessary. It also means that if two devices connect to a central >>>> server on a regular basis, they will be in sync with each other even t= hough >>>> they have never communicated. >>>> >>>> [LH]: That is what we want to do in the IETF and is also what the >>> current storage services are trying to provide. Simple C/S protocol is = not >>> satisfied. >>> >>> I think this is a more useful paradigm than something like rsync, but I >>>> realize that it=E2=80=99s a lot more complicated, and may be beyond th= e scope of >>>> what the folks who proposed this mailing list intended. Is it someth= ing >>>> you=E2=80=99d be interested in pursuing, or should I go off and do it = on my own? >>>> :) >>>> >>>> [LH]: I think rsync should not be considered as an essential part of >>> such sync protocol. Not only because it is complicated. We usually find= the >>> rsync failed in some scenarios and sometimes causes extra sync traffic. >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Ted Lemon >>> To: Marc Blanchet >>> Cc: Linhui Sun , "Songhaibin (A)" < >>> haibin.song@huawei.com>, storagesync , " >>> qinxiaowei@cnnic.cn" >>> Date: Wed, 2 Sep 2015 10:29:01 -0400 >>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storag= e >>> Sync >>> On Sep 2, 2015, at 8:07 AM, Marc Blanchet >>> wrote: >>> >>> I=E2=80=99ve said to the organizers that I think a solution already imp= lemented >>> and deployed is rsync over webdav for this. It should be looked at >>> carefully before reinventing a new protocol. >>> >>> >>> rsync is inadequate if you have changes on both ends or more than two >>> copies of the sync=E2=80=99d data. An rfc describing the rsync protoc= ol might be >>> useful to someone, but I don=E2=80=99t think it=E2=80=99s interesting n= ew work. However, >>> this question is certainly one that should be answered in the requireme= nts >>> document. Do you think rsync is adequate because you think that paral= lel >>> updates aren=E2=80=99t important? It sounds like one motivation for t= his work is >>> support for CDNs, and for those something like rsync would be perfectly >>> adequate, but that=E2=80=99s not the use case I=E2=80=99m interested in= . Frankly, that >>> seems like a solved problem to me. >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Marc Blanchet >>> To: Ted Lemon >>> Cc: Linhui Sun , "Songhaibin (A)" < >>> haibin.song@huawei.com>, storagesync , " >>> qinxiaowei@cnnic.cn" >>> Date: Wed, 02 Sep 2015 11:26:53 -0400 >>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storag= e >>> Sync >>> >>> >>> On 2 Sep 2015, at 10:29, Ted Lemon wrote: >>> >>> On Sep 2, 2015, at 8:07 AM, Marc Blanchet >>>> wrote: >>>> >>>>> I=E2=80=99ve said to the organizers that I think a solution already >>>>> implemented and deployed is rsync over webdav for this. It should be = looked >>>>> at carefully before reinventing a new protocol. >>>>> >>>> >>>> rsync is inadequate if you have changes on both ends or more than two >>>> copies of the sync=E2=80=99d data. An rfc describing the rsync proto= col might be >>>> useful to someone, but I don=E2=80=99t think it=E2=80=99s interesting = new work. However, >>>> this question is certainly one that should be answered in the requirem= ents >>>> document. Do you think rsync is adequate because you think that para= llel >>>> updates aren=E2=80=99t important? It sounds like one motivation for = this work is >>>> support for CDNs, and for those something like rsync would be perfectl= y >>>> adequate, but that=E2=80=99s not the use case I=E2=80=99m interested i= n. Frankly, that >>>> seems like a solved problem to me. >>>> >>> >>> well, that is my point, so we agree=E2=80=A6 >>> - webdav+rsync is providing pretty good solution. therefore, it should >>> be clearly identified in the problem statement and also what it is not >>> solving. >>> - then we can discuss what other features (such as what you described) >>> can be worth technical work, spec, etc=E2=80=A6 >>> >>> Marc. >>> >>> >>> >>>> _______________________________________________ >>>> Storagesync mailing list >>>> Storagesync@ietf.org >>>> https://www.ietf.org/mailman/listinfo/storagesync >>>> >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Ted Lemon >>> To: Marc Blanchet >>> Cc: Linhui Sun , "Songhaibin (A)" < >>> haibin.song@huawei.com>, storagesync , " >>> qinxiaowei@cnnic.cn" >>> Date: Wed, 2 Sep 2015 12:59:26 -0400 >>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storag= e >>> Sync >>> On Sep 2, 2015, at 11:26 AM, Marc Blanchet >>> wrote: >>> >>> well, that is my point, so we agree=E2=80=A6 >>> - webdav+rsync is providing pretty good solution. therefore, it should >>> be clearly identified in the problem statement and also what it is not >>> solving. >>> - then we can discuss what other features (such as what you described) >>> can be worth technical work, spec, etc=E2=80=A6 >>> >>> >>> Ah, OK, thanks for clarifying! >>> >>> >>> _______________________________________________ >>> Storagesync mailing list >>> Storagesync@ietf.org >>> https://www.ietf.org/mailman/listinfo/storagesync >>> >>> >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/storagesync >> >> > > > -- > Yours sincerely > LZQ > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --=20 Yours sincerely LZQ --94eb2c0888f69c085d051f4e4461 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Ted and Marc:

I think W= ebDAV is originally designed for authoring and versioning. It allows users = to collaboratively edit and manage files on remote web services. However it= does not consider how to make transmission efficient. For example if we mo= dify a small portion of a large file in local device, WebDAV needs to uploa= d the full file to the server.

Of course we can co= mbine WebDAV with rsync to improve the transmission efficiency. However I t= hink this is still=C2=A0inadequate.=C2=A0As we mentioned previously, in a c= loud storage system files are split into chunks. The rsync algorithm is des= igned to find the delta content between two files.=C2=A0rsync works well in= file granularity, but we need an approach that can work in chunk granulari= ty, and find the delta of two file versions even though they are split into= many chunks.

Besides, there are some other techni= ques (e.g. deduplication, bundling and compression) that can be used to spe= ed up transmission for cloud storage services. Deduplication is to avoid th= e transmission of files that already exist in the server. These techniques = are complemented with rsync.

Overall, we think the= existed solution (e.g. WebDAV+rsync) is inadequate. We hope to design a st= andard sync=C2=A0protocol combining and extending existed techniques to eff= iciently=C2=A0synchronize data between client and server. We also think the= approach to merge parallel changes on two ends is very important=C2=A0and = should be considered in the sync protocol.

Best re= gards,
Zeqi Lai

On Tue, Sep 8, 2015 at 11:05 PM, <storagesync-re= quest@ietf.org> wrote:
Send Storagesync m= ailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storage= sync@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/ma= ilman/listinfo/storagesync
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s= toragesync-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Storagesync digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: Storagesync Digest, Vol 2, Issue 6 (ZeQi Lai)


---------- Forwarded message ----------
From:=C2=A0ZeQi Lai <= uestclzq@gmail.com>
To:=C2= =A0storagesync@ietf.org
Cc:= =C2=A0Linhui Sun <lh.sunlinh@gma= il.com>, Yong Cui <cui= yong@tsinghua.edu.cn>
Date:=C2=A0Tue, 8 Sep 2015 23:04:57 +0200Subject:=C2=A0Re: [Storagesync] Storagesync Digest, Vol 2, Issue 6
Hi Ted and Marc,=

I am Zeqi Lai from Tsinghua University.

Thanks for your suggestions! We would identify this i= n the problem statement later. However, I'd like to express some differ= ent viewpoints about the rsync over webdav first. Actually, I do not think = rsync+WebDAV is not=C2=A0as good as it looks=C2=A0for several reasons.

1) WebDAV is not suitable=C2=A0for large files, e.g. a HD movie. Also=C2=A0WeDAV does not work well in mobile/wireless environments=C2=A0(high RT= T/loss, intermittent connections).=C2=A0Temporary loss of connection may lead to sync failure.

2)=C2=A0There exists other capabilities (i.e. chunking= , deduplication, bundling, compression) that can be used to speed up data s= ync. Current WebDAV does not consider these useful=C2=A0capabilities.=C2=A0=

3) The limitation of rsync. Another po= int is that rsync works in the file granularity. That requires the entities= running on two ends must have access to the entire file. However, to achie= ve better scalability, current network-based storage services split files i= nto chunks and store them distributedly (chunk granularity). Directly using= rsync needs to piece=C2=A0together all chunks to construct the whole file = and would waste massive intra-cluster bandwidth.

=
In summary, the sync protocol what we&= #39;d like to do is something more than rsync/webdav. As for the features T= ed mentioned (e.g. parallel update), we haven't considered them a lot a= t first. After several recent discussions, we think they are really importa= nt and worth the effort. We'd like to see how many people have interest= s in those features? How many people think those features should be the cor= e issue rather than improving the sync efficiency? And then we could update= the problem statement and produce an appropriate charter : )

Best regards,
Zeqi Lai

On Thu, Sep 3, 2= 015 at 9:00 PM, <storagesync-request@ietf.org> w= rote:
Send Storagesync mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/ma= ilman/listinfo/storagesync
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Storagesync digest..."

Today's Topics:

=C2=A0 =C2=A01. Unsubscribe (David Noveck)


---------- Forwarded message ----------
From:=C2=A0David Noveck = <davenoveck@gm= ail.com>
To:=C2=A0storagesync@ietf.org
Cc:=C2=A0
Date:=C2=A0Wed, 2 Sep = 2015 15:02:41 -0400
Subject:=C2=A0[Storagesync] Unsubscribe
On Sep 2, 2015 3:00 PM, <storagesync-request@ietf.org> = wrote:
Send Storagesync mailing li= st submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/ma= ilman/listinfo/storagesync
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 storagesync-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Storagesync digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: Welcome to the Discussion on Internet Storage Sync
=C2=A0 =C2=A0 =C2=A0 (Linhui Sun)
=C2=A0 =C2=A02. Re: Welcome to the Discussion on Internet Storage Sync (Ted= Lemon)
=C2=A0 =C2=A03. Re: Welcome to the Discussion on Internet Storage Sync
=C2=A0 =C2=A0 =C2=A0 (Marc Blanchet)
=C2=A0 =C2=A04. Re: Welcome to the Discussion on Internet Storage Sync (Ted= Lemon)


---------- Forwarded message ----------
From:=C2=A0Linhui Sun &l= t;lh.sunlinh@gmai= l.com>
To:=C2=A0Ted Lemon <mellon@fugue.com>
Cc:=C2=A0"Songhaibin (A= )" <hai= bin.song@huawei.com>, storagesync <storagesync@ietf.org>, "qinxiaowei@cnnic.cn"= <qinxiaowei@cn= nic.cn>
Date:=C2=A0Wed, 2 Sep 2015 20:40:51 +0800
Subject:=C2= =A0Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync
=

= 2015-09-02 20:23 GMT+08:00 Ted Lemon <mellon@fugue.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
On Sep 2, 2015, a= t 7:40 AM, Linhui Sun <lh.sunlinh@gmail.com> wrote:
=
I think maybe we should make the d= efinition of sync clearer. Could we explain it as a simple upload/download = process. Or the sync is specifically referred to the transfer process of=C2= =A0Network-based storage services which may employ several well-known techn= iques (e.g. rsync)?

Personal= ly I am not interested in a client/server sync protocol. =C2=A0 What I woul= d like is a sync protocol more like git, where each device has a history of= the last time a sync happened, and can tell what has changed since the las= t sync. =C2=A0 When two devices connect, they compare notes and figure out = what changes have to be made on both sides to reach a new master version. = =C2=A0 This of course means that some conflict resolution process may be ne= cessary. =C2=A0 It also means that if two devices connect to a central serv= er on a regular basis, they will be in sync with each other even though the= y have never communicated.

[LH]= : That is what we want to do in the IETF and is also what the current stora= ge services are trying to provide. Simple C/S protocol is not satisfied.

I think this is a more useful paradigm than something like rsyn= c, but I realize that it=E2=80=99s a lot more complicated, and may be beyon= d the scope of what the folks who proposed this mailing list intended. =C2= =A0 Is it something you=E2=80=99d be interested in pursuing, or should I go= off and do it on my own? =C2=A0 :)

=
[LH]: I think rsync should not be considered as an essential part of s= uch sync protocol. Not only because it is complicated. We usually find the = rsync failed in some scenarios and sometimes causes extra sync traffic.



---------- Forwarded message ----------
From:=C2=A0Ted Lemon <= ;mellon@fugue.com= >
To:=C2=A0Marc Blanchet <marc.blanchet@viagenie.ca>
Cc:=C2=A0Linhui= Sun <lh.sunli= nh@gmail.com>, "Songhaibin (A)" <haibin.song@huawei.com>, stora= gesync <storag= esync@ietf.org>, "qinxiaowei@cnnic.cn" <qinxiaowei@cnnic.cn>
Date:=C2=A0Wed, = 2 Sep 2015 10:29:01 -0400
Subject:=C2=A0Re: [Storagesync] Welcome to the= Discussion on Internet Storage Sync
On Sep 2, 2015, at 8:07 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:=
I= =E2=80=99ve said to the organizers that I think a solution already implemen= ted and deployed is rsync over webdav for this. It should be looked at care= fully before reinventing a new protocol.

<= div>rsync is inadequate if you have changes on both ends or more than two c= opies of the sync=E2=80=99d data. =C2=A0 An rfc describing the rsync protoc= ol might be useful to someone, but I don=E2=80=99t think it=E2=80=99s inter= esting new work. =C2=A0 However, this question is certainly one that should= be answered in the requirements document. =C2=A0 Do you think rsync is ade= quate because you think that parallel updates aren=E2=80=99t important? =C2= =A0 It sounds like one motivation for this work is support for CDNs, and fo= r those something like rsync would be perfectly adequate, but that=E2=80=99= s not the use case I=E2=80=99m interested in. =C2=A0 Frankly, that seems li= ke a solved problem to me.



---------- For= warded message ----------
From:=C2=A0Marc Blanchet <marc.blanchet@viagenie.ca= >
To:=C2=A0Ted Lemon <mellon@fugue.com>
Cc:=C2=A0Linhui Sun <lh.sunlinh@gmail.com>= , "Songhaibin (A)" <haibin.song@huawei.com>, storagesync <storagesync@ietf.org= >, "qinxia= owei@cnnic.cn" <qinxiaowei@cnnic.cn>
Date:=C2=A0Wed, 02 Sep 2015 11:2= 6:53 -0400
Subject:=C2=A0Re: [Storagesync] Welcome to the Discussion on = Internet Storage Sync


On 2 Sep 2015, at 10:29, Ted Lemon wrote:

On Sep 2, 2015, at 8:07 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:<= br>
I=E2=80=99ve said to the organizers that I think a solution already impleme= nted and deployed is rsync over webdav for this. It should be looked at car= efully before reinventing a new protocol.

rsync is inadequate if you have changes on both ends or more than two copie= s of the sync=E2=80=99d data.=C2=A0 =C2=A0An rfc describing the rsync proto= col might be useful to someone, but I don=E2=80=99t think it=E2=80=99s inte= resting new work.=C2=A0 =C2=A0However, this question is certainly one that = should be answered in the requirements document.=C2=A0 =C2=A0Do you think r= sync is adequate because you think that parallel updates aren=E2=80=99t imp= ortant?=C2=A0 =C2=A0It sounds like one motivation for this work is support = for CDNs, and for those something like rsync would be perfectly adequate, b= ut that=E2=80=99s not the use case I=E2=80=99m interested in.=C2=A0 =C2=A0F= rankly, that seems like a solved problem to me.

well, that is my point, so we agree=E2=80=A6
- webdav+rsync is providing pretty good solution. therefore, it should be c= learly identified in the problem statement and also what it is not solving.=
- then we can discuss what other features (such as what you described) can = be worth technical work, spec, etc=E2=80=A6

Marc.



_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync




---------- Forwarded message ----------
From:=C2=A0Ted Lemon <= ;mellon@fugue.com= >
To:=C2=A0Marc Blanchet <marc.blanchet@viagenie.ca>
Cc:=C2=A0Linhui= Sun <lh.sunli= nh@gmail.com>, "Songhaibin (A)" <haibin.song@huawei.com>, stora= gesync <storag= esync@ietf.org>, "qinxiaowei@cnnic.cn" <qinxiaowei@cnnic.cn>
Date:=C2=A0Wed, = 2 Sep 2015 12:59:26 -0400
Subject:=C2=A0Re: [Storagesync] Welcome to the= Discussion on Internet Storage Sync
On Sep 2, 2015, at 11:26 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote= :
we= ll, that is my point, so we agree=E2=80=A6
- webdav+rsync is providing pretty good solution. therefore, it sho= uld be clearly identified in the problem statement and also what it is not = solving.
- then we can discuss what= other features (such as what you described) can be worth technical work, s= pec, etc=E2=80=A6

Ah, OK, thanks fo= r clarifying!


_______________________________= ________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync


_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync




--
You= rs sincerely
LZQ

_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync




--
Yours sincerely
LZQ
--94eb2c0888f69c085d051f4e4461-- From nobody Wed Sep 9 04:34:33 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C31E1A87A5 for ; Wed, 9 Sep 2015 04:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9VWyw0vPEci for ; Wed, 9 Sep 2015 04:34:29 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC291A702B for ; Wed, 9 Sep 2015 04:34:29 -0700 (PDT) Received: from [192.168.1.109] (modemcable093.65-160-184.mc.videotron.ca [184.160.65.93]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6E5CB40411; Wed, 9 Sep 2015 07:34:28 -0400 (EDT) From: "Marc Blanchet" To: "ZeQi Lai" Date: Wed, 09 Sep 2015 07:34:17 -0400 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Linhui Sun , storagesync@ietf.org, Yong Cui Subject: Re: [Storagesync] Storagesync Digest, Vol 2, Issue 7 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 11:34:32 -0000 On 9 Sep 2015, at 6:51, ZeQi Lai wrote: > Dear Ted and Marc: > > I think WebDAV is originally designed for authoring and versioning. It > allows users to collaboratively edit and manage files on remote web > services. However it does not consider how to make transmission > efficient. > For example if we modify a small portion of a large file in local > device, > WebDAV needs to upload the full file to the server. > > Of course we can combine WebDAV with rsync to improve the transmission > efficiency. However I think this is still inadequate. As we mentioned > previously, in a cloud storage system files are split into chunks. The > rsync algorithm is designed to find the delta content between two > files. rsync works well in file granularity, but we need an approach > that > can work in chunk granularity, and find the delta of two file versions > even > though they are split into many chunks. > > Besides, there are some other techniques (e.g. deduplication, bundling > and > compression) that can be used to speed up transmission for cloud > storage > services. Deduplication is to avoid the transmission of files that > already > exist in the server. These techniques are complemented with rsync. > > Overall, we think the existed solution (e.g. WebDAV+rsync) is > inadequate. I’m not trying to say that webdav+rsync is better or worst. I’m saying it should be clearly discussed (and documented if we have a problem statement kind of document) so that we know why we are designing another protocol. Marc. > We hope to design a standard sync protocol combining and extending > existed > techniques to efficiently synchronize data between client and server. > We > also think the approach to merge parallel changes on two ends is very > important and should be considered in the sync protocol. > > Best regards, > Zeqi Lai > > On Tue, Sep 8, 2015 at 11:05 PM, wrote: > >> Send Storagesync mailing list submissions to >> storagesync@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/storagesync >> or, via email, send a message with subject or body 'help' to >> storagesync-request@ietf.org >> >> You can reach the person managing the list at >> storagesync-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Storagesync digest..." >> >> Today's Topics: >> >> 1. Re: Storagesync Digest, Vol 2, Issue 6 (ZeQi Lai) >> >> >> ---------- Forwarded message ---------- >> From: ZeQi Lai >> To: storagesync@ietf.org >> Cc: Linhui Sun , Yong Cui >> >> Date: Tue, 8 Sep 2015 23:04:57 +0200 >> Subject: Re: [Storagesync] Storagesync Digest, Vol 2, Issue 6 >> Hi Ted and Marc, >> >> I am Zeqi Lai from Tsinghua University. >> >> Thanks for your suggestions! We would identify this in the problem >> statement later. However, I'd like to express some different >> viewpoints >> about the rsync over webdav first. Actually, I do not think >> rsync+WebDAV is >> not as good as it looks for several reasons. >> >> 1) WebDAV is not suitable for large files, e.g. a HD movie. Also >> WeDAV >> does not work well in mobile/wireless environments (high RTT/loss, >> intermittent connections). Temporary loss of connection may lead to >> sync >> failure. >> >> 2) There exists other capabilities (i.e. chunking, deduplication, >> bundling, compression) that can be used to speed up data sync. >> Current >> WebDAV does not consider these useful capabilities. >> >> 3) The limitation of rsync. Another point is that rsync works in the >> file >> granularity. That requires the entities running on two ends must have >> access to the entire file. However, to achieve better scalability, >> current >> network-based storage services split files into chunks and store them >> distributedly (chunk granularity). Directly using rsync needs to >> piece together all chunks to construct the whole file and would waste >> massive intra-cluster bandwidth. >> >> In summary, the sync protocol what we'd like to do is something more >> than >> rsync/webdav. As for the features Ted mentioned (e.g. parallel >> update), we >> haven't considered them a lot at first. After several recent >> discussions, >> we think they are really important and worth the effort. We'd like to >> see >> how many people have interests in those features? How many people >> think >> those features should be the core issue rather than improving the >> sync >> efficiency? And then we could update the problem statement and >> produce an >> appropriate charter : ) >> >> Best regards, >> Zeqi Lai >> >> On Thu, Sep 3, 2015 at 9:00 PM, wrote: >> >>> Send Storagesync mailing list submissions to >>> storagesync@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/storagesync >>> or, via email, send a message with subject or body 'help' to >>> storagesync-request@ietf.org >>> >>> You can reach the person managing the list at >>> storagesync-owner@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Storagesync digest..." >>> >>> Today's Topics: >>> >>> 1. Unsubscribe (David Noveck) >>> >>> >>> ---------- Forwarded message ---------- >>> From: David Noveck >>> To: storagesync@ietf.org >>> Cc: >>> Date: Wed, 2 Sep 2015 15:02:41 -0400 >>> Subject: [Storagesync] Unsubscribe >>> On Sep 2, 2015 3:00 PM, wrote: >>> >>>> Send Storagesync mailing list submissions to >>>> storagesync@ietf.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://www.ietf.org/mailman/listinfo/storagesync >>>> or, via email, send a message with subject or body 'help' to >>>> storagesync-request@ietf.org >>>> >>>> You can reach the person managing the list at >>>> storagesync-owner@ietf.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of Storagesync digest..." >>>> >>>> Today's Topics: >>>> >>>> 1. Re: Welcome to the Discussion on Internet Storage Sync >>>> (Linhui Sun) >>>> 2. Re: Welcome to the Discussion on Internet Storage Sync (Ted >>>> Lemon) >>>> 3. Re: Welcome to the Discussion on Internet Storage Sync >>>> (Marc Blanchet) >>>> 4. Re: Welcome to the Discussion on Internet Storage Sync (Ted >>>> Lemon) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Linhui Sun >>>> To: Ted Lemon >>>> Cc: "Songhaibin (A)" , storagesync < >>>> storagesync@ietf.org>, "qinxiaowei@cnnic.cn" >>>> Date: Wed, 2 Sep 2015 20:40:51 +0800 >>>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet >>>> Storage >>>> Sync >>>> >>>> 2015-09-02 20:23 GMT+08:00 Ted Lemon : >>>> >>>>> On Sep 2, 2015, at 7:40 AM, Linhui Sun >>>>> wrote: >>>>> >>>>> I think maybe we should make the definition of sync clearer. Could >>>>> we >>>>> explain it as a simple upload/download process. Or the sync is >>>>> specifically >>>>> referred to the transfer process of Network-based storage services >>>>> which >>>>> may employ several well-known techniques (e.g. rsync)? >>>>> >>>>> >>>>> Personally I am not interested in a client/server sync protocol. >>>>> What >>>>> I would like is a sync protocol more like git, where each device >>>>> has a >>>>> history of the last time a sync happened, and can tell what has >>>>> changed >>>>> since the last sync. When two devices connect, they compare >>>>> notes and >>>>> figure out what changes have to be made on both sides to reach a >>>>> new master >>>>> version. This of course means that some conflict resolution >>>>> process may >>>>> be necessary. It also means that if two devices connect to a >>>>> central >>>>> server on a regular basis, they will be in sync with each other >>>>> even though >>>>> they have never communicated. >>>>> >>>>> [LH]: That is what we want to do in the IETF and is also what the >>>> current storage services are trying to provide. Simple C/S protocol >>>> is not >>>> satisfied. >>>> >>>> I think this is a more useful paradigm than something like rsync, >>>> but I >>>>> realize that it’s a lot more complicated, and may be beyond the >>>>> scope of >>>>> what the folks who proposed this mailing list intended. Is it >>>>> something >>>>> you’d be interested in pursuing, or should I go off and do it on >>>>> my own? >>>>> :) >>>>> >>>>> [LH]: I think rsync should not be considered as an essential part >>>>> of >>>> such sync protocol. Not only because it is complicated. We usually >>>> find the >>>> rsync failed in some scenarios and sometimes causes extra sync >>>> traffic. >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Ted Lemon >>>> To: Marc Blanchet >>>> Cc: Linhui Sun , "Songhaibin (A)" < >>>> haibin.song@huawei.com>, storagesync , " >>>> qinxiaowei@cnnic.cn" >>>> Date: Wed, 2 Sep 2015 10:29:01 -0400 >>>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet >>>> Storage >>>> Sync >>>> On Sep 2, 2015, at 8:07 AM, Marc Blanchet >>>> >>>> wrote: >>>> >>>> I’ve said to the organizers that I think a solution already >>>> implemented >>>> and deployed is rsync over webdav for this. It should be looked at >>>> carefully before reinventing a new protocol. >>>> >>>> >>>> rsync is inadequate if you have changes on both ends or more than >>>> two >>>> copies of the sync’d data. An rfc describing the rsync protocol >>>> might be >>>> useful to someone, but I don’t think it’s interesting new work. >>>> However, >>>> this question is certainly one that should be answered in the >>>> requirements >>>> document. Do you think rsync is adequate because you think that >>>> parallel >>>> updates aren’t important? It sounds like one motivation for >>>> this work is >>>> support for CDNs, and for those something like rsync would be >>>> perfectly >>>> adequate, but that’s not the use case I’m interested in. >>>> Frankly, that >>>> seems like a solved problem to me. >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Marc Blanchet >>>> To: Ted Lemon >>>> Cc: Linhui Sun , "Songhaibin (A)" < >>>> haibin.song@huawei.com>, storagesync , " >>>> qinxiaowei@cnnic.cn" >>>> Date: Wed, 02 Sep 2015 11:26:53 -0400 >>>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet >>>> Storage >>>> Sync >>>> >>>> >>>> On 2 Sep 2015, at 10:29, Ted Lemon wrote: >>>> >>>> On Sep 2, 2015, at 8:07 AM, Marc Blanchet >>>> >>>>> wrote: >>>>> >>>>>> I’ve said to the organizers that I think a solution already >>>>>> implemented and deployed is rsync over webdav for this. It should >>>>>> be looked >>>>>> at carefully before reinventing a new protocol. >>>>>> >>>>> >>>>> rsync is inadequate if you have changes on both ends or more than >>>>> two >>>>> copies of the sync’d data. An rfc describing the rsync >>>>> protocol might be >>>>> useful to someone, but I don’t think it’s interesting new >>>>> work. However, >>>>> this question is certainly one that should be answered in the >>>>> requirements >>>>> document. Do you think rsync is adequate because you think that >>>>> parallel >>>>> updates aren’t important? It sounds like one motivation for >>>>> this work is >>>>> support for CDNs, and for those something like rsync would be >>>>> perfectly >>>>> adequate, but that’s not the use case I’m interested in. >>>>> Frankly, that >>>>> seems like a solved problem to me. >>>>> >>>> >>>> well, that is my point, so we agree… >>>> - webdav+rsync is providing pretty good solution. therefore, it >>>> should >>>> be clearly identified in the problem statement and also what it is >>>> not >>>> solving. >>>> - then we can discuss what other features (such as what you >>>> described) >>>> can be worth technical work, spec, etc… >>>> >>>> Marc. >>>> >>>> >>>> >>>>> _______________________________________________ >>>>> Storagesync mailing list >>>>> Storagesync@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/storagesync >>>>> >>>> >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Ted Lemon >>>> To: Marc Blanchet >>>> Cc: Linhui Sun , "Songhaibin (A)" < >>>> haibin.song@huawei.com>, storagesync , " >>>> qinxiaowei@cnnic.cn" >>>> Date: Wed, 2 Sep 2015 12:59:26 -0400 >>>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet >>>> Storage >>>> Sync >>>> On Sep 2, 2015, at 11:26 AM, Marc Blanchet >>>> >>>> wrote: >>>> >>>> well, that is my point, so we agree… >>>> - webdav+rsync is providing pretty good solution. therefore, it >>>> should >>>> be clearly identified in the problem statement and also what it is >>>> not >>>> solving. >>>> - then we can discuss what other features (such as what you >>>> described) >>>> can be worth technical work, spec, etc… >>>> >>>> >>>> Ah, OK, thanks for clarifying! >>>> >>>> >>>> _______________________________________________ >>>> Storagesync mailing list >>>> Storagesync@ietf.org >>>> https://www.ietf.org/mailman/listinfo/storagesync >>>> >>>> >>> _______________________________________________ >>> Storagesync mailing list >>> Storagesync@ietf.org >>> https://www.ietf.org/mailman/listinfo/storagesync >>> >>> >> >> >> -- >> Yours sincerely >> LZQ >> >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/storagesync >> >> > > > -- > Yours sincerely > LZQ > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync From nobody Wed Sep 9 05:08:36 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB891B38E8 for ; Wed, 9 Sep 2015 05:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BahH99wS4IVc for ; Wed, 9 Sep 2015 05:08:29 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152F81B38CE for ; Wed, 9 Sep 2015 05:08:29 -0700 (PDT) Received: by ykdu9 with SMTP id u9so11114210ykd.2 for ; Wed, 09 Sep 2015 05:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/EZNA6PoH9+uBWcwDBb/TU49klFIKno//mosy22DPPs=; b=q5pZOEbVGjvuZDt+K84vUy2ByiLqzvPpWAINIdi7W7PUV3sWQuKx2Sh/rqhpxgMzvX eORy6BKJorzijJ13IX3xEpfQJtwbu/MqwriVdgkf9zkaSkzbhdHXjzuHXo9H3Uslyo5q cDeeIl7Xw25xU98LrNqU0tDhn0P6zHyow+JTRTJ/duQ6JBvknlMaz7mIHQ7j4+SBiHiQ 8HUVr/40UDVuHZ6h7+szwZlnAc0Snu1drNKzRMMrJ7QkNZKgDuTA/7R7I3UqnqixjAvm vgDKQMO4mKAGTTjZyw0DBfAjGfw844hGzihn+L+aBnuhKOF+9OsbUc1rPUnwIOzwxyrg 6H0w== MIME-Version: 1.0 X-Received: by 10.170.143.132 with SMTP id k126mr34776183ykc.121.1441800508333; Wed, 09 Sep 2015 05:08:28 -0700 (PDT) Received: by 10.37.210.17 with HTTP; Wed, 9 Sep 2015 05:08:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Sep 2015 14:08:28 +0200 Message-ID: From: ZeQi Lai To: Marc Blanchet Content-Type: multipart/alternative; boundary=001a11399b9a22e85e051f4f5774 Archived-At: Cc: Linhui Sun , storagesync@ietf.org, Yong Cui Subject: Re: [Storagesync] Storagesync Digest, Vol 2, Issue 7 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 12:08:34 -0000 --001a11399b9a22e85e051f4f5774 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Marc: Thank you very much for your suggestion! We will clearly identify the problem in the problem statement. Best regards, Zeqi Lai On Wed, Sep 9, 2015 at 1:34 PM, Marc Blanchet wrote: > > > On 9 Sep 2015, at 6:51, ZeQi Lai wrote: > > Dear Ted and Marc: >> >> I think WebDAV is originally designed for authoring and versioning. It >> allows users to collaboratively edit and manage files on remote web >> services. However it does not consider how to make transmission efficien= t. >> For example if we modify a small portion of a large file in local device= , >> WebDAV needs to upload the full file to the server. >> >> Of course we can combine WebDAV with rsync to improve the transmission >> efficiency. However I think this is still inadequate. As we mentioned >> previously, in a cloud storage system files are split into chunks. The >> rsync algorithm is designed to find the delta content between two >> files. rsync works well in file granularity, but we need an approach tha= t >> can work in chunk granularity, and find the delta of two file versions >> even >> though they are split into many chunks. >> >> Besides, there are some other techniques (e.g. deduplication, bundling a= nd >> compression) that can be used to speed up transmission for cloud storage >> services. Deduplication is to avoid the transmission of files that alrea= dy >> exist in the server. These techniques are complemented with rsync. >> >> Overall, we think the existed solution (e.g. WebDAV+rsync) is inadequate= . >> > > I=E2=80=99m not trying to say that webdav+rsync is better or worst. I=E2= =80=99m saying it > should be clearly discussed (and documented if we have a problem statemen= t > kind of document) so that we know why we are designing another protocol. > > Marc. > > > We hope to design a standard sync protocol combining and extending existe= d >> techniques to efficiently synchronize data between client and server. We >> also think the approach to merge parallel changes on two ends is very >> important and should be considered in the sync protocol. >> >> Best regards, >> Zeqi Lai >> >> On Tue, Sep 8, 2015 at 11:05 PM, wrote: >> >> Send Storagesync mailing list submissions to >>> storagesync@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/storagesync >>> or, via email, send a message with subject or body 'help' to >>> storagesync-request@ietf.org >>> >>> You can reach the person managing the list at >>> storagesync-owner@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Storagesync digest..." >>> >>> Today's Topics: >>> >>> 1. Re: Storagesync Digest, Vol 2, Issue 6 (ZeQi Lai) >>> >>> >>> ---------- Forwarded message ---------- >>> From: ZeQi Lai >>> To: storagesync@ietf.org >>> Cc: Linhui Sun , Yong Cui >> > >>> Date: Tue, 8 Sep 2015 23:04:57 +0200 >>> Subject: Re: [Storagesync] Storagesync Digest, Vol 2, Issue 6 >>> Hi Ted and Marc, >>> >>> I am Zeqi Lai from Tsinghua University. >>> >>> Thanks for your suggestions! We would identify this in the problem >>> statement later. However, I'd like to express some different viewpoints >>> about the rsync over webdav first. Actually, I do not think rsync+WebDA= V >>> is >>> not as good as it looks for several reasons. >>> >>> 1) WebDAV is not suitable for large files, e.g. a HD movie. Also WeDAV >>> does not work well in mobile/wireless environments (high RTT/loss, >>> intermittent connections). Temporary loss of connection may lead to syn= c >>> failure. >>> >>> 2) There exists other capabilities (i.e. chunking, deduplication, >>> bundling, compression) that can be used to speed up data sync. Current >>> WebDAV does not consider these useful capabilities. >>> >>> 3) The limitation of rsync. Another point is that rsync works in the fi= le >>> granularity. That requires the entities running on two ends must have >>> access to the entire file. However, to achieve better scalability, >>> current >>> network-based storage services split files into chunks and store them >>> distributedly (chunk granularity). Directly using rsync needs to >>> piece together all chunks to construct the whole file and would waste >>> massive intra-cluster bandwidth. >>> >>> In summary, the sync protocol what we'd like to do is something more th= an >>> rsync/webdav. As for the features Ted mentioned (e.g. parallel update), >>> we >>> haven't considered them a lot at first. After several recent discussion= s, >>> we think they are really important and worth the effort. We'd like to s= ee >>> how many people have interests in those features? How many people think >>> those features should be the core issue rather than improving the sync >>> efficiency? And then we could update the problem statement and produce = an >>> appropriate charter : ) >>> >>> Best regards, >>> Zeqi Lai >>> >>> On Thu, Sep 3, 2015 at 9:00 PM, wrote: >>> >>> Send Storagesync mailing list submissions to >>>> storagesync@ietf.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://www.ietf.org/mailman/listinfo/storagesync >>>> or, via email, send a message with subject or body 'help' to >>>> storagesync-request@ietf.org >>>> >>>> You can reach the person managing the list at >>>> storagesync-owner@ietf.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of Storagesync digest..." >>>> >>>> Today's Topics: >>>> >>>> 1. Unsubscribe (David Noveck) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: David Noveck >>>> To: storagesync@ietf.org >>>> Cc: >>>> Date: Wed, 2 Sep 2015 15:02:41 -0400 >>>> Subject: [Storagesync] Unsubscribe >>>> On Sep 2, 2015 3:00 PM, wrote: >>>> >>>> Send Storagesync mailing list submissions to >>>>> storagesync@ietf.org >>>>> >>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>> https://www.ietf.org/mailman/listinfo/storagesync >>>>> or, via email, send a message with subject or body 'help' to >>>>> storagesync-request@ietf.org >>>>> >>>>> You can reach the person managing the list at >>>>> storagesync-owner@ietf.org >>>>> >>>>> When replying, please edit your Subject line so it is more specific >>>>> than "Re: Contents of Storagesync digest..." >>>>> >>>>> Today's Topics: >>>>> >>>>> 1. Re: Welcome to the Discussion on Internet Storage Sync >>>>> (Linhui Sun) >>>>> 2. Re: Welcome to the Discussion on Internet Storage Sync (Ted Lemon) >>>>> 3. Re: Welcome to the Discussion on Internet Storage Sync >>>>> (Marc Blanchet) >>>>> 4. Re: Welcome to the Discussion on Internet Storage Sync (Ted Lemon) >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Linhui Sun >>>>> To: Ted Lemon >>>>> Cc: "Songhaibin (A)" , storagesync < >>>>> storagesync@ietf.org>, "qinxiaowei@cnnic.cn" >>>>> Date: Wed, 2 Sep 2015 20:40:51 +0800 >>>>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet >>>>> Storage >>>>> Sync >>>>> >>>>> 2015-09-02 20:23 GMT+08:00 Ted Lemon : >>>>> >>>>> On Sep 2, 2015, at 7:40 AM, Linhui Sun wrote: >>>>>> >>>>>> I think maybe we should make the definition of sync clearer. Could w= e >>>>>> explain it as a simple upload/download process. Or the sync is >>>>>> specifically >>>>>> referred to the transfer process of Network-based storage services >>>>>> which >>>>>> may employ several well-known techniques (e.g. rsync)? >>>>>> >>>>>> >>>>>> Personally I am not interested in a client/server sync protocol. >>>>>> What >>>>>> I would like is a sync protocol more like git, where each device has= a >>>>>> history of the last time a sync happened, and can tell what has >>>>>> changed >>>>>> since the last sync. When two devices connect, they compare notes >>>>>> and >>>>>> figure out what changes have to be made on both sides to reach a new >>>>>> master >>>>>> version. This of course means that some conflict resolution proces= s >>>>>> may >>>>>> be necessary. It also means that if two devices connect to a centr= al >>>>>> server on a regular basis, they will be in sync with each other even >>>>>> though >>>>>> they have never communicated. >>>>>> >>>>>> [LH]: That is what we want to do in the IETF and is also what the >>>>>> >>>>> current storage services are trying to provide. Simple C/S protocol i= s >>>>> not >>>>> satisfied. >>>>> >>>>> I think this is a more useful paradigm than something like rsync, but= I >>>>> >>>>>> realize that it=E2=80=99s a lot more complicated, and may be beyond = the scope >>>>>> of >>>>>> what the folks who proposed this mailing list intended. Is it >>>>>> something >>>>>> you=E2=80=99d be interested in pursuing, or should I go off and do i= t on my >>>>>> own? >>>>>> :) >>>>>> >>>>>> [LH]: I think rsync should not be considered as an essential part of >>>>>> >>>>> such sync protocol. Not only because it is complicated. We usually >>>>> find the >>>>> rsync failed in some scenarios and sometimes causes extra sync traffi= c. >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Ted Lemon >>>>> To: Marc Blanchet >>>>> Cc: Linhui Sun , "Songhaibin (A)" < >>>>> haibin.song@huawei.com>, storagesync , " >>>>> qinxiaowei@cnnic.cn" >>>>> Date: Wed, 2 Sep 2015 10:29:01 -0400 >>>>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet >>>>> Storage >>>>> Sync >>>>> On Sep 2, 2015, at 8:07 AM, Marc Blanchet >>>>> wrote: >>>>> >>>>> I=E2=80=99ve said to the organizers that I think a solution already i= mplemented >>>>> and deployed is rsync over webdav for this. It should be looked at >>>>> carefully before reinventing a new protocol. >>>>> >>>>> >>>>> rsync is inadequate if you have changes on both ends or more than two >>>>> copies of the sync=E2=80=99d data. An rfc describing the rsync prot= ocol >>>>> might be >>>>> useful to someone, but I don=E2=80=99t think it=E2=80=99s interesting= new work. >>>>> However, >>>>> this question is certainly one that should be answered in the >>>>> requirements >>>>> document. Do you think rsync is adequate because you think that >>>>> parallel >>>>> updates aren=E2=80=99t important? It sounds like one motivation for= this >>>>> work is >>>>> support for CDNs, and for those something like rsync would be perfect= ly >>>>> adequate, but that=E2=80=99s not the use case I=E2=80=99m interested = in. Frankly, >>>>> that >>>>> seems like a solved problem to me. >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Marc Blanchet >>>>> To: Ted Lemon >>>>> Cc: Linhui Sun , "Songhaibin (A)" < >>>>> haibin.song@huawei.com>, storagesync , " >>>>> qinxiaowei@cnnic.cn" >>>>> Date: Wed, 02 Sep 2015 11:26:53 -0400 >>>>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet >>>>> Storage >>>>> Sync >>>>> >>>>> >>>>> On 2 Sep 2015, at 10:29, Ted Lemon wrote: >>>>> >>>>> On Sep 2, 2015, at 8:07 AM, Marc Blanchet >>>>> >>>>>> wrote: >>>>>> >>>>>> I=E2=80=99ve said to the organizers that I think a solution already >>>>>>> implemented and deployed is rsync over webdav for this. It should b= e >>>>>>> looked >>>>>>> at carefully before reinventing a new protocol. >>>>>>> >>>>>>> >>>>>> rsync is inadequate if you have changes on both ends or more than tw= o >>>>>> copies of the sync=E2=80=99d data. An rfc describing the rsync pro= tocol >>>>>> might be >>>>>> useful to someone, but I don=E2=80=99t think it=E2=80=99s interestin= g new work. >>>>>> However, >>>>>> this question is certainly one that should be answered in the >>>>>> requirements >>>>>> document. Do you think rsync is adequate because you think that >>>>>> parallel >>>>>> updates aren=E2=80=99t important? It sounds like one motivation fo= r this >>>>>> work is >>>>>> support for CDNs, and for those something like rsync would be >>>>>> perfectly >>>>>> adequate, but that=E2=80=99s not the use case I=E2=80=99m interested= in. Frankly, >>>>>> that >>>>>> seems like a solved problem to me. >>>>>> >>>>>> >>>>> well, that is my point, so we agree=E2=80=A6 >>>>> - webdav+rsync is providing pretty good solution. therefore, it shoul= d >>>>> be clearly identified in the problem statement and also what it is no= t >>>>> solving. >>>>> - then we can discuss what other features (such as what you described= ) >>>>> can be worth technical work, spec, etc=E2=80=A6 >>>>> >>>>> Marc. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>>> Storagesync mailing list >>>>>> Storagesync@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/storagesync >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Ted Lemon >>>>> To: Marc Blanchet >>>>> Cc: Linhui Sun , "Songhaibin (A)" < >>>>> haibin.song@huawei.com>, storagesync , " >>>>> qinxiaowei@cnnic.cn" >>>>> Date: Wed, 2 Sep 2015 12:59:26 -0400 >>>>> Subject: Re: [Storagesync] Welcome to the Discussion on Internet >>>>> Storage >>>>> Sync >>>>> On Sep 2, 2015, at 11:26 AM, Marc Blanchet >>>>> wrote: >>>>> >>>>> well, that is my point, so we agree=E2=80=A6 >>>>> - webdav+rsync is providing pretty good solution. therefore, it shoul= d >>>>> be clearly identified in the problem statement and also what it is no= t >>>>> solving. >>>>> - then we can discuss what other features (such as what you described= ) >>>>> can be worth technical work, spec, etc=E2=80=A6 >>>>> >>>>> >>>>> Ah, OK, thanks for clarifying! >>>>> >>>>> >>>>> _______________________________________________ >>>>> Storagesync mailing list >>>>> Storagesync@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/storagesync >>>>> >>>>> >>>>> _______________________________________________ >>>> Storagesync mailing list >>>> Storagesync@ietf.org >>>> https://www.ietf.org/mailman/listinfo/storagesync >>>> >>>> >>>> >>> >>> -- >>> Yours sincerely >>> LZQ >>> >>> _______________________________________________ >>> Storagesync mailing list >>> Storagesync@ietf.org >>> https://www.ietf.org/mailman/listinfo/storagesync >>> >>> >>> >> >> -- >> Yours sincerely >> LZQ >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/storagesync >> > --=20 Yours sincerely LZQ --001a11399b9a22e85e051f4f5774 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Marc:

Thank you very much for your= suggestion! We will clearly identify the problem in the problem statement.=

Best regards,
Zeqi Lai

On Wed, Sep 9, 2015 at= 1:34 PM, Marc Blanchet <marc.blanchet@viagenie.ca> = wrote:


On 9 Sep 2015, at 6:51, ZeQi Lai wrote:

Dear Ted and Marc:

I think WebDAV is originally designed for authoring and versioning. It
allows users to collaboratively edit and manage files on remote web
services. However it does not consider how to make transmission efficient.<= br> For example if we modify a small portion of a large file in local device, WebDAV needs to upload the full file to the server.

Of course we can combine WebDAV with rsync to improve the transmission
efficiency. However I think this is still inadequate. As we mentioned
previously, in a cloud storage system files are split into chunks. The
rsync algorithm is designed to find the delta content between two
files. rsync works well in file granularity, but we need an approach that can work in chunk granularity, and find the delta of two file versions even=
though they are split into many chunks.

Besides, there are some other techniques (e.g. deduplication, bundling and<= br> compression) that can be used to speed up transmission for cloud storage services. Deduplication is to avoid the transmission of files that already<= br> exist in the server. These techniques are complemented with rsync.

Overall, we think the existed solution (e.g. WebDAV+rsync) is inadequate.

I=E2=80=99m not trying to say that webdav+rsync is better or worst. I=E2=80= =99m saying it should be clearly discussed (and documented if we have a pro= blem statement kind of document) so that we know why we are designing anoth= er protocol.

Marc.


We hope to design a standard sync protocol combining and extending existed<= br> techniques to efficiently synchronize data between client and server. We also think the approach to merge parallel changes on two ends is very
important and should be considered in the sync protocol.

Best regards,
Zeqi Lai

On Tue, Sep 8, 2015 at 11:05 PM, <storagesync-request@ietf.org> wrote:

Send Storagesync mailing list submissions to
=C2=A0 =C2=A0 =C2=A0storagesync@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/storagesync
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Storagesync digest..."

Today's Topics:

1. Re: Storagesync Digest, Vol 2, Issue 6 (ZeQi Lai)


---------- Forwarded message ----------
From: ZeQi Lai <= uestclzq@gmail.com>
To: storagesync@i= etf.org
Cc: Linhui Sun <lh.sunlinh@gmail.com>, Yong Cui <cuiyong@tsinghua.edu.cn>
Date: Tue, 8 Sep 2015 23:04:57 +0200
Subject: Re: [Storagesync] Storagesync Digest, Vol 2, Issue 6
Hi Ted and Marc,

I am Zeqi Lai from Tsinghua University.

Thanks for your suggestions! We would identify this in the problem
statement later. However, I'd like to express some different viewpoints=
about the rsync over webdav first. Actually, I do not think rsync+WebDAV is=
not as good as it looks for several reasons.

1) WebDAV is not suitable for large files, e.g. a HD movie. Also WeDAV
does not work well in mobile/wireless environments (high RTT/loss,
intermittent connections). Temporary loss of connection may lead to sync failure.

2) There exists other capabilities (i.e. chunking, deduplication,
bundling, compression) that can be used to speed up data sync. Current
WebDAV does not consider these useful capabilities.

3) The limitation of rsync. Another point is that rsync works in the file granularity. That requires the entities running on two ends must have
access to the entire file. However, to achieve better scalability, current<= br> network-based storage services split files into chunks and store them
distributedly (chunk granularity). Directly using rsync needs to
piece together all chunks to construct the whole file and would waste
massive intra-cluster bandwidth.

In summary, the sync protocol what we'd like to do is something more th= an
rsync/webdav. As for the features Ted mentioned (e.g. parallel update), we<= br> haven't considered them a lot at first. After several recent discussion= s,
we think they are really important and worth the effort. We'd like to s= ee
how many people have interests in those features? How many people think
those features should be the core issue rather than improving the sync
efficiency? And then we could update the problem statement and produce an appropriate charter : )

Best regards,
Zeqi Lai

On Thu, Sep 3, 2015 at 9:00 PM, <storagesync-request@ietf.org> wrote:

Send Storagesync mailing list submissions to
=C2=A0 =C2=A0 =C2=A0storagesync@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/storagesync
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Storagesync digest..."

Today's Topics:

1. Unsubscribe (David Noveck)


---------- Forwarded message ----------
From: David Noveck <davenoveck@gmail.com>
To: storagesync@i= etf.org
Cc:
Date: Wed, 2 Sep 2015 15:02:41 -0400
Subject: [Storagesync] Unsubscribe
On Sep 2, 2015 3:00 PM, <storagesync-request@ietf.org> wrote:

Send Storagesync mailing list submissions to
=C2=A0 =C2=A0 =C2=A0storagesync@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/storagesync
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Storagesync digest..."

Today's Topics:

1. Re: Welcome to the Discussion on Internet Storage Sync
=C2=A0 =C2=A0(Linhui Sun)
2. Re: Welcome to the Discussion on Internet Storage Sync (Ted Lemon)
3. Re: Welcome to the Discussion on Internet Storage Sync
=C2=A0 =C2=A0(Marc Blanchet)
4. Re: Welcome to the Discussion on Internet Storage Sync (Ted Lemon)


---------- Forwarded message ----------
From: Linhui Sun <lh.sunlinh@gmail.com>
To: Ted Lemon <mel= lon@fugue.com>
Cc: "Songhaibin (A)" <haibin.song@huawei.com>, storagesync <
storagesync@ietf.= org>, "qinxiaowei@cnnic.cn" <qinxiaowei@cnnic.cn>
Date: Wed, 2 Sep 2015 20:40:51 +0800
Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync

2015-09-02 20:23 GMT+08:00 Ted Lemon <mellon@fugue.com>:

On Sep 2, 2015, at 7:40 AM, Linhui Sun <lh.sunlinh@gmail.com> wrote:

I think maybe we should make the definition of sync clearer. Could we
explain it as a simple upload/download process. Or the sync is specifically=
referred to the transfer process of Network-based storage services which may employ several well-known techniques (e.g. rsync)?


Personally I am not interested in a client/server sync protocol.=C2=A0 =C2= =A0What
I would like is a sync protocol more like git, where each device has a
history of the last time a sync happened, and can tell what has changed
since the last sync.=C2=A0 =C2=A0When two devices connect, they compare not= es and
figure out what changes have to be made on both sides to reach a new master=
version.=C2=A0 =C2=A0This of course means that some conflict resolution pro= cess may
be necessary.=C2=A0 =C2=A0It also means that if two devices connect to a ce= ntral
server on a regular basis, they will be in sync with each other even though=
they have never communicated.

[LH]: That is what we want to do in the IETF and is also what the
current storage services are trying to provide. Simple C/S protocol is not<= br> satisfied.

I think this is a more useful paradigm than something like rsync, but I
realize that it=E2=80=99s a lot more complicated, and may be beyond the sco= pe of
what the folks who proposed this mailing list intended.=C2=A0 =C2=A0Is it s= omething
you=E2=80=99d be interested in pursuing, or should I go off and do it on my= own?
:)

[LH]: I think rsync should not be considered as an essential part of
such sync protocol. Not only because it is complicated. We usually find the=
rsync failed in some scenarios and sometimes causes extra sync traffic.



---------- Forwarded message ----------
From: Ted Lemon <m= ellon@fugue.com>
To: Marc Blanchet <marc.blanchet@viagenie.ca>
Cc: Linhui Sun <lh.sunlinh@gmail.com>, "Songhaibin (A)" <
haibin.song@hua= wei.com>, storagesync <storagesync@ietf.org>, "
qinxiaowei@cnnic.c= n" <qi= nxiaowei@cnnic.cn>
Date: Wed, 2 Sep 2015 10:29:01 -0400
Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync
On Sep 2, 2015, at 8:07 AM, Marc Blanchet <marc.blanchet@viagenie.ca>
wrote:

I=E2=80=99ve said to the organizers that I think a solution already impleme= nted
and deployed is rsync over webdav for this. It should be looked at
carefully before reinventing a new protocol.


rsync is inadequate if you have changes on both ends or more than two
copies of the sync=E2=80=99d data.=C2=A0 =C2=A0An rfc describing the rsync = protocol might be
useful to someone, but I don=E2=80=99t think it=E2=80=99s interesting new w= ork.=C2=A0 =C2=A0However,
this question is certainly one that should be answered in the requirements<= br> document.=C2=A0 =C2=A0Do you think rsync is adequate because you think that= parallel
updates aren=E2=80=99t important?=C2=A0 =C2=A0It sounds like one motivation= for this work is
support for CDNs, and for those something like rsync would be perfectly
adequate, but that=E2=80=99s not the use case I=E2=80=99m interested in.=C2= =A0 =C2=A0Frankly, that
seems like a solved problem to me.



---------- Forwarded message ----------
From: Marc Blanchet <marc.blanchet@viagenie.ca>
To: Ted Lemon <mel= lon@fugue.com>
Cc: Linhui Sun <lh.sunlinh@gmail.com>, "Songhaibin (A)" <
haibin.song@hua= wei.com>, storagesync <storagesync@ietf.org>, "
qinxiaowei@cnnic.c= n" <qi= nxiaowei@cnnic.cn>
Date: Wed, 02 Sep 2015 11:26:53 -0400
Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync


On 2 Sep 2015, at 10:29, Ted Lemon wrote:

On Sep 2, 2015, at 8:07 AM, Marc Blanchet <marc.blanchet@viagenie.ca>
wrote:

I=E2=80=99ve said to the organizers that I think a solution already
implemented and deployed is rsync over webdav for this. It should be looked=
at carefully before reinventing a new protocol.


rsync is inadequate if you have changes on both ends or more than two
copies of the sync=E2=80=99d data.=C2=A0 =C2=A0An rfc describing the rsync = protocol might be
useful to someone, but I don=E2=80=99t think it=E2=80=99s interesting new w= ork.=C2=A0 =C2=A0However,
this question is certainly one that should be answered in the requirements<= br> document.=C2=A0 =C2=A0Do you think rsync is adequate because you think that= parallel
updates aren=E2=80=99t important?=C2=A0 =C2=A0It sounds like one motivation= for this work is
support for CDNs, and for those something like rsync would be perfectly
adequate, but that=E2=80=99s not the use case I=E2=80=99m interested in.=C2= =A0 =C2=A0Frankly, that
seems like a solved problem to me.


well, that is my point, so we agree=E2=80=A6
- webdav+rsync is providing pretty good solution. therefore, it should
be clearly identified in the problem statement and also what it is not
solving.
- then we can discuss what other features (such as what you described)
can be worth technical work, spec, etc=E2=80=A6

Marc.



_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync





---------- Forwarded message ----------
From: Ted Lemon <m= ellon@fugue.com>
To: Marc Blanchet <marc.blanchet@viagenie.ca>
Cc: Linhui Sun <lh.sunlinh@gmail.com>, "Songhaibin (A)" <
haibin.song@hua= wei.com>, storagesync <storagesync@ietf.org>, "
qinxiaowei@cnnic.c= n" <qi= nxiaowei@cnnic.cn>
Date: Wed, 2 Sep 2015 12:59:26 -0400
Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync
On Sep 2, 2015, at 11:26 AM, Marc Blanchet <marc.blanchet@viagenie.ca>
wrote:

well, that is my point, so we agree=E2=80=A6
- webdav+rsync is providing pretty good solution. therefore, it should
be clearly identified in the problem statement and also what it is not
solving.
- then we can discuss what other features (such as what you described)
can be worth technical work, spec, etc=E2=80=A6


Ah, OK, thanks for clarifying!


_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync


_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync




--
Yours sincerely
LZQ

_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync




--
Yours sincerely
LZQ
_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync



--
=
Yours sincerely
LZQ
--001a11399b9a22e85e051f4f5774-- From nobody Wed Sep 9 06:42:10 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6B81A916B for ; Wed, 9 Sep 2015 06:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idTG4XEqJ4Rz for ; Wed, 9 Sep 2015 06:42:02 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79B31A702D for ; Wed, 9 Sep 2015 06:42:01 -0700 (PDT) Received: by qgez77 with SMTP id z77so7605170qge.1 for ; Wed, 09 Sep 2015 06:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:from:to:cc:in-reply-to:references:subject:date :message-id:mime-version; bh=8MZPe/FnI71/NuTkh8CS6vw/gFpdAAdVd/CZMpOQdlo=; b=v0aNrHadEIcK+t0YaTx9TWPTotaihguHPQ1iVGvQJ7fWpWOPTGO0fc8Q5VuWbd67gu +gu0EMcOj3mgOnsxGoHyBW56+KXTFd+y6cHTCaN9n+5AVstTqhdjqr4ElmnzPzZCo/ZJ rNgcsTKRzt4amGnu15F3WhUC0/zodOlBqjvb+TVvz8rdH41518BwKTQmNfTWJHkn8HLy u8fUFsXnMXzXe8ITLOSAAmgMfZparEFSc5Iur2LOLosDmpGykEFGERV4anxnSqOyTA9x drMGVnsNDbHXIRL6AakqzaGMT1A5juKfZoduLQqAkLiL1JbkaM8XddfZuENx7TkAB6Le ap1A== X-Received: by 10.140.19.227 with SMTP id 90mr43484010qgh.51.1441806120863; Wed, 09 Sep 2015 06:42:00 -0700 (PDT) Received: from [127.0.0.1] (ec2-54-210-254-140.compute-1.amazonaws.com. [54.210.254.140]) by smtp.gmail.com with ESMTPSA id r22sm3926606qkh.10.2015.09.09.06.41.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Sep 2015 06:41:59 -0700 (PDT) Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14418061188840.3930706512182951" From: Linhui Sun To: Zhenhua Li In-Reply-To: References: <2015090116520811787510@cnnic.cn> Date: Wed, 09 Sep 2015 21:41:54 +0800 X-Cm-Message-Id: 144180611877929022456b43d1ce3a62358075e3e3d8e31955f03726be4d3778950627 X-Cm-Draft-Id: WyJhIiwzLCJkcmFmdF9pZCIsIjE0NDE4MDYxMTQwMDAiLCJjIiwiMTUxMDY1NzIxMjg4NzA1MjgwMCIsInYiLDFd X-Mailer: CloudMagic Message-Id: <1441806119140-46fe784d-6824169f-da5e8348@gmail.com> MIME-Version: 1.0 Archived-At: Cc: storagesync , qinxiaowei@cnnic.cn Subject: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 13:42:09 -0000 ------sinikael-?=_1-14418061188840.3930706512182951 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Zhenhua, Thanks for your comment. It sounds like the output of this = problem is an evaluation document for the sync protocol. Am I right? If so,= personally I think this could be considered later. Currently, we should = make it clear why we would like to propose such a work as Marc suggested. Comments are welcome. Best regards, Linhui On =E5=91=A8=E4=B8=89, = 9=E6=9C=88 9, 2015 at 18:18, Zhenhua Li = wrote: Hi Linhui, I suggest we consider an additional problem, Key Metrics = for Internet Storage Sync . At the moment, we even don't know what are the = key metrics to correctly evaluate an Internet Storage Sync = service/operation. For your reference :) Zhenhua On Tue, Sep 1, 2015 at = 9:09 PM, Linhui Sun < lh.sunlinh@gmail.com [lh.sunlinh@gmail.com] > wrote: Hi Xiaowei, Thanks for sharing your thoughts. I think the things you = mentioned are not conflicting when considering the standardization of sync = protocol. If we could come up with an open and standard sync protocol, the = third-party APIs could be significantly simplified. And it is reasonable = and necessary that such standard sync protocol should pay more attention to= the sync efficiency to allow users have an ideal upload rate. Any comments? Actually we outline five different problems in the problem = statement draft. Problem 4 and 5 reveals why most existing proprietary sync= protocols do not have a satisfactory sync efficiency (e.g. poor = performance on upload rate). 1) Complicated Support for APIs 2) Unavailable Cross-service Sync 3) Redundant Similar Clients 4) Different Capability Configurations and Implementations 5) Challenges in Mobile and Wireless Environments (More detailed = descriptions could be found in: http://datatracker.ietf.= org/doc/draft-cui-iss-problem/ [http://datatracker.ietf.= org/doc/draft-cui-iss-problem/] ) In addition, I think the most urgent task= of this Non-WG list is to have an agreement on the specified problems and = the scope of work. Thus may I ask the people in this list to share your = thoughts on the problems and scope of work? Which problem do you think is = not required or is there any other problems we haven't mentioned in the = draft? Please feel free to comment on it. Best regards, Linhui 2015-09-01 16:52 GMT+08:00 qinxiaowei@cnnic.cn [qinxiaowei@cnnic.cn] < = qinxiaowei@cnnic.cn [qinxiaowei@cnnic.cn] > : hi, Third-party API and = optimizing the sync protocols may be important for Online storage. But, IMO, the most important is improving data upload rate that = end users can obtain. ----------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------------------------------Hi folks= , Welcome to the mailing list of Internet Storage Sync (Storagesync@ietf.= org [Storagesync@ietf.org]). This list is for the discussions of Internet = Storage Sync work. You are welcome to introduce yourself here and start = related discussions. We've produced a draft to outline the main problems in= existing Internet storage services, please find the document with the = following link. Please feel free to comment on it and your valuable = comments are more than welcome. http://datatracker.ietf.= org/doc/draft-cui-iss-problem/ [http://datatracker.ietf.= org/doc/draft-cui-iss-problem/] A wiki for some useful resources and links = could be found. Please feel free to edit it or let us know if we've missed = something.=20 https://github.com/iss-ietf/iss/wiki/Internet-Storage-Sync/ = [https://github.com/iss-ietf/iss/wiki/Internet-Storage-Sync/] Regards, Yong Cui, Professor, Tsinghua University, Beijing, China Associate Editor on IEEE TPDS, IEEE TCC URL: http://www.4over6.edu.= cn/cuiyong/index.html [http://www.4over6.edu.cn/cuiyong/index.html] ---------------------------------------------------------------------------= ----- _______________________________________________ Storagesync mailing list Storagesync@ietf.org [Storagesync@ietf.org] https://www.ietf.org/mailman/listinfo/storagesync [https://www.ietf.= org/mailman/listinfo/storagesync] ______________________________________= _________ Storagesync mailing list Storagesync@ietf.org [Storagesync@ietf.= org] https://www.ietf.org/mailman/listinfo/storagesync [https://www.ietf.org/mailman/listinfo/storagesync] -- Zhenhua Li, homepage: http://www.greenorbs.org/people/lzh/ [http://www.= greenorbs.org/people/lzh/] Associate Researcher, GreenOrbs - Cloud = Computing Group, TNLIST, Tsinghua University PostDoc, School of Software, = Tsinghua University, Beijing, China Email: lizhenhua1983@tsinghua.edu.cn = [lizhenhua1983@tsinghua.edu.cn] , lizhenhua1983@gmail.com = [lizhenhua1983@gmail.com] Phone: +86-13552819836 = (@Beijing) ------sinikael-?=_1-14418061188840.3930706512182951 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Zhenhua,

Thanks for your comment. It sounds like = the output of this problem is an evaluation document for the sync protocol.= Am I right? If so,  personally I think this could be considered later= . Currently, we should make it clear why we would like to propose such a = work as Marc suggested.

Comments are welcome.=

Best regards,
Linhui 

On =E5=91=A8=E4=B8=89, 9=E6=9C=88 9, 2015 at 18:18, = Zhenhua Li <lizhenhua1983@tsinghua.edu.cn> wrote:
Hi Linhui,=

I suggest we consider an additional problem, Key = Metrics for Internet Storage Sync.
At the moment, we even = don't know what are the key metrics to correctly evaluate an Internet = Storage Sync service/operation.

For your = reference :)

Zhenhua

On Tue, Sep 1, 2015 at= 9:09 PM, Linhui Sun <lh.sunlinh@gmail.com> = wrote:
Hi = Xiaowei,

Thanks for sharing your thoughts. I think the = things you mentioned are not conflicting when considering the = standardization of sync protocol. If we could come up with an open and = standard sync protocol, the third-party APIs could be significantly = simplified. And it is reasonable and necessary that such standard sync = protocol should pay more attention to the sync efficiency to allow users = have an ideal upload rate.

Any comments?=

Actually we outline five different problems in = the problem statement draft. Problem 4 and 5 reveals why most existing = proprietary sync protocols do not have a satisfactory sync efficiency (e.g.= poor performance on upload rate).

1) = Complicated Support for APIs
2) Unavailable = Cross-service Sync
3) Redundant Similar = Clients
4) Different Capability Configurations and = Implementations
5) Challenges in Mobile and Wireless = Environments
(More detailed descriptions could be found = in: http= ://datatracker.ietf.org/doc/draft-cui-iss-problem/)

In addition, I think the most urgent task of this Non-WG list is to = have an agreement on the specified problems and the scope of work. Thus may= I ask the people in this list to share your thoughts on the problems and = scope of work? Which problem do you think is not required or is there any = other problems we haven't mentioned in the draft? Please feel free to = comment on it.

Best regards,=
Linhui

2015-09-01 16:52 GMT+08:00 qinxiaowei@cnnic.cn <qinxiaowei@cnnic.= cn>:
hi, =
Third-party API and optimizing the sync protocols may be important for = Online storage. But, IMO, the most important is improving data upload rate = that end users can obtain.


<= br>




-= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------
Hi folks,
Welcome to the mailing list of Internet Storage Sync (Storagesync@ietf.org). This list =
is for the discussions of Internet Storage Sync work. You are welcome to =
introduce yourself here and start related discussions.
We've produced a draft to outline the main problems in existing Internet =
storage services, please find the document with the following link. Please =
feel free to comment on it and your valuable comments are more than welcome=
.
http:/=
/datatracker.ietf.org/doc/draft-cui-iss-problem/
A wiki for some useful resources and links could be found. Please feel free=
 to edit it or let us know if we've missed something.=20
htt=
ps://github.com/iss-ietf/iss/wiki/Internet-Storage-Sync/
Regards,
Yong Cui,
Professor, Tsinghua University, Beijing, China
Associate Editor on IEEE TPDS, IEEE TCC
URL: http://www.4over6.edu.cn/cuiyong/index.=
html


______________________________________________= _
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.= org/mailman/listinfo/storagesync


<= /div>
_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.= org/mailman/listinfo/storagesync




--
Zhenhua Li, homepage: http://www.greenorbs.org/people/lzh/
Associate = Researcher, GreenOrbs - Cloud Computing Group, TNLIST, Tsinghua = University
PostDoc, School of Software, Tsinghua University, Beijing, = China
Email: lizhenhua1983@tsinghua.edu.cn, lizhenhua1983@gmail.com
Phone: +86-13552819836 = (@Beijing)
= ------sinikael-?=_1-14418061188840.3930706512182951-- From nobody Wed Sep 9 06:58:18 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69B41B3681 for ; Wed, 9 Sep 2015 06:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcSArqC-av_e for ; Wed, 9 Sep 2015 06:58:10 -0700 (PDT) Received: from tsinghua.edu.cn (smtp07.tsinghua.edu.cn [166.111.204.36]) by ietfa.amsl.com (Postfix) with ESMTP id 442FF1B3608 for ; Wed, 9 Sep 2015 06:58:09 -0700 (PDT) Received: from mail-io0-f176.google.com (unknown [209.85.223.176]) by app5 (Coremail) with SMTP id DsxvpgCXPkDpOvBVVP_RAA--.13272S2; Wed, 09 Sep 2015 21:58:02 +0800 (CST) Received: by iofh134 with SMTP id h134so22891762iof.0 for ; Wed, 09 Sep 2015 06:58:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.170.223 with SMTP id g92mr47641809ioj.79.1441807080994; Wed, 09 Sep 2015 06:58:00 -0700 (PDT) Received: by 10.64.163.73 with HTTP; Wed, 9 Sep 2015 06:58:00 -0700 (PDT) In-Reply-To: <1441806119140-46fe784d-6824169f-da5e8348@gmail.com> References: <2015090116520811787510@cnnic.cn> <1441806119140-46fe784d-6824169f-da5e8348@gmail.com> Date: Wed, 9 Sep 2015 21:58:00 +0800 Message-ID: From: Zhenhua Li To: Linhui Sun Content-Type: multipart/alternative; boundary=001a1142ef3ee5c8e0051f50de79 X-CM-TRANSID: DsxvpgCXPkDpOvBVVP_RAA--.13272S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWrW3AF4DuFW3JFykWFW3Jrb_yoWrKr43pF 43Jr13Kr4UKFW7Gw1kJ3Wjvr1YyryrKrW5G3Z8Jry8Ary5AFy0qw18tr4FkryUJr93Gr1F qr12gF15Gw18ZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv2b7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAac4AC62xK8xCEY4vEwIxC4wAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AI YIkI8VC2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJV WUGwAv7VC2z280aVAFwI0_Gr0_Cr1lOx8S6xCaFVCjc4AY6r1j6r4UMx8GjcxK6IxK0xII j40E5I8CrwCY1Ik267vv6cIUMxkIecxEwVCI4VW5GwCF04k20xvY0x0EwIxGrwC20s026c 02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_ JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7 CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa 7xUUe_BUUUUUU== X-CM-SenderInfo: xol2xv5qkxtiazytq3pvlqwxlxdovvfxof0/ Archived-At: Cc: storagesync , qinxiaowei@cnnic.cn Subject: Re: [Storagesync] Welcome to the Discussion on Internet Storage Sync X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 13:58:15 -0000 --001a1142ef3ee5c8e0051f50de79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree. The performance metrics are not the first-place problem at the moment. We can keep it in mind and consider later. Zhenhua On Wed, Sep 9, 2015 at 9:41 PM, Linhui Sun wrote: > Hi Zhenhua, > > Thanks for your comment. It sounds like the output of this problem is an > evaluation document for the sync protocol. Am I right? If so, personally= I > think this could be considered later. Currently, we should make it clear > why we would like to propose such a work as Marc suggested. > > Comments are welcome. > > Best regards, > Linhui > > > On =E5=91=A8=E4=B8=89, 9=E6=9C=88 9, 2015 at 18:18, Zhenhua Li > wrote: > > Hi Linhui, > > I suggest we consider an additional problem, *Key Metrics for Internet > Storage Sync*. > At the moment, we even don't know what are the key metrics to correctly > evaluate an Internet Storage Sync service/operation. > > For your reference :) > > Zhenhua > > On Tue, Sep 1, 2015 at 9:09 PM, Linhui Sun wrote: > >> Hi Xiaowei, >> >> Thanks for sharing your thoughts. I think the things you mentioned are >> not conflicting when considering the standardization of sync protocol. I= f >> we could come up with an open and standard sync protocol, the third-part= y >> APIs could be significantly simplified. And it is reasonable and necessa= ry >> that such standard sync protocol should pay more attention to the sync >> efficiency to allow users have an ideal upload rate. >> >> Any comments? >> >> Actually we outline five different problems in the problem statement >> draft. Problem 4 and 5 reveals why most existing proprietary sync protoc= ols >> do not have a satisfactory sync efficiency (e.g. poor performance on upl= oad >> rate). >> >> 1) *Complicated Support for APIs* >> 2) *Unavailable Cross-service Sync* >> 3) *Redundant Similar Clients* >> 4) *Different Capability Configurations and Implementations* >> 5) *Challenges in Mobile and Wireless Environments * >> (More detailed descriptions could be found in: >> http://datatracker.ietf.org/doc/draft-cui-iss-problem/) >> >> In addition, I think the most urgent task of this Non-WG list is to have >> an agreement on the specified problems and the scope of work. Thus may I >> ask the people in this list to share your thoughts on the problems and >> scope of work? Which problem do you think is not required or is there an= y >> other problems we haven't mentioned in the draft? Please feel free to >> comment on it. >> >> Best regards, >> Linhui >> >> 2015-09-01 16:52 GMT+08:00 qinxiaowei@cnnic.cn : >> >>> hi, >>> Third-party API and optimizing the sync protocols may be important for >>> Online storage. But, IMO, the most important is improving data upload r= ate >>> that end users can obtain. >>> >>> >>> >>> >>> >>> >>> >>> >>> -----------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------------------------------------ >>> >>> Hi folks, >>> Welcome to the mailing list of Internet Storage Sync (Storagesync@ietf.= org). This list is for the discussions of Internet Storage Sync work. You a= re welcome to introduce yourself here and start related discussions. >>> We've produced a draft to outline the main problems in existing Interne= t storage services, please find the document with the following link. Pleas= e feel free to comment on it and your valuable comments are more than welco= me.http://datatracker.ietf.org/doc/draft-cui-iss-problem/ >>> A wiki for some useful resources and links could be found. Please feel = free to edit it or let us know if we've missed something. https://github.co= m/iss-ietf/iss/wiki/Internet-Storage-Sync/ >>> Regards, >>> Yong Cui, >>> Professor, Tsinghua University, Beijing, China >>> Associate Editor on IEEE TPDS, IEEE TCC >>> URL: http://www.4over6.edu.cn/cuiyong/index.html >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> Storagesync mailing list >>> Storagesync@ietf.org >>> https://www.ietf.org/mailman/listinfo/storagesync >>> >>> >> >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/storagesync >> >> > > > -- > Zhenhua Li, homepage: http://www.greenorbs.org/people/lzh/ > Associate Researcher, GreenOrbs - Cloud Computing Group, TNLIST, Tsinghua > University > PostDoc, School of Software, Tsinghua University, Beijing, China > Email: lizhenhua1983@tsinghua.edu.cn, lizhenhua1983@gmail.com > Phone: +86-13552819836 (@Beijing) > > --=20 Zhenhua Li, homepage: http://www.greenorbs.org/people/lzh/ Associate Researcher, GreenOrbs - Cloud Computing Group, TNLIST, Tsinghua University PostDoc, School of Software, Tsinghua University, Beijing, China Email: lizhenhua1983@tsinghua.edu.cn, lizhenhua1983@gmail.com Phone: +86-13552819836 (@Beijing) --001a1142ef3ee5c8e0051f50de79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree. The performance metrics are not the first-place p= roblem at the moment. We can keep it in mind and consider later.

Zhenhua

On Wed, Sep 9, 2015 at 9:41 PM, Linhui Sun <= ;lh.sunlinh@gmail= .com> wrote:
Hi Zhenhua,<= div>
Thanks for your comment. It sounds like the output of th= is problem is an evaluation document for the sync protocol. Am I right? If = so, =C2=A0personally I think this could be considered later. Currently, we = should make it clear why we would like to propose such a work as Marc sugge= sted.

Comments are welcome.

Best regards,
Linhui=C2=A0


On =E5=91=A8=E4= =B8=89, 9=E6=9C=88 9, 2015 at 18:18, Zhenhua Li <lizhenhua1983@tsinghua.edu.cn<= /a>> wrote:
Hi Linhui,

I sug= gest we consider an additional problem, Key Metrics for Internet Storage= Sync.
At the moment, we even don't know what are the key= metrics to correctly evaluate an Internet Storage Sync service/operation. =

For your reference :)

Zh= enhua

= On Tue, Sep 1, 2015 at 9:09 PM, Linhui Sun <lh.sunlinh@gmail.com>= ; wrote:
Hi Xiaow= ei,

Thanks for sharing your thoughts. I think the things= you mentioned are not conflicting when considering the standardization of = sync protocol. If we could come up with an open and standard sync protocol,= the third-party APIs could be significantly simplified. And it is reasonab= le and necessary that such standard sync protocol should pay more attention= to the sync efficiency to allow users have an ideal upload rate.

Any comments?

Actually we outline = five different problems in the problem statement draft. Problem 4 and 5 rev= eals why most existing proprietary sync protocols do not have a satisfactor= y sync efficiency (e.g. poor performance on upload rate).

1) Complicated Support for APIs
2) Unavaila= ble Cross-service Sync
3) Redundant Similar Clients
4) Different Capability Configurations and Implementatio= ns
5) Challenges in Mobile and Wireless Environments <= /b>
(More detailed descriptions could be found in: = http://datatracker.ietf.org/doc/draft-cui-iss-problem/)

<= /div>
In addition, I think the most urgent task of this Non-WG list is = to have an agreement on the specified problems and the scope of work. Thus = may I ask the people in this list to share your thoughts on the problems an= d scope of work? Which problem do you think is not required or is there any= other problems we haven't mentioned in the draft? Please feel free to = comment on it.

Best regards,
Linhui

2015-0= 9-01 16:52 GMT+08:00 qinxiaowei@cnnic.cn <qinxiaowei@cnnic.cn>:
hi,
Third-party API and optimizing the sync protocols may be important for= Online storage. But, IMO, the most important is improving data upload rate= that end users can obtain.


=




= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------------------------------
Hi folks,
Welcome to the mailing list of Internet Storage Sync (Storagesync@ietf.org). This list i=
s for the discussions of Internet Storage Sync work. You are welcome to int=
roduce yourself here and start related discussions.
We've produced a draft to outline the main problems in existing Interne=
t storage services, please find the document with the following link. Pleas=
e feel free to comment on it and your valuable comments are more than welco=
me.
http://datatracker.ietf.org/doc/draft-cui-iss-problem/
A wiki for some useful resources and links could be found. Please feel free=
 to edit it or let us know if we've missed something.=20
https://github.com/iss-ietf/iss/wiki/Internet-Storage-Sync/<=
/a>
Regards,
Yong Cui,
Professor, Tsinghua University, Beijing, China
Associate Editor on IEEE TPDS, IEEE TCC
URL: http://www.4over6.edu.cn/cuiyong/index.html


______________________________________________= _
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync



_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync




--
Zhenhua Li, homepage: http://www.greenorbs.org/people/lzh/
A= ssociate Researcher, GreenOrbs - Cloud Computing Group, TNLIST, Tsinghua Un= iversity
PostDoc, School of Software, Tsinghua University, Beijing, Chin= a
Email: lizhenhua1983@tsinghua.edu.cn, lizhenhua1983@gmail.com
Phone: +86-13552819= 836 (@Beijing)



--
Zhenhua Li, =C2=A0 homepage:=C2=A0http://www.gree= norbs.org/people/lzh/
Associate Researcher, GreenOrbs - Cloud Comput= ing Group, TNLIST, Tsinghua University
PostDoc, School of Software, Tsin= ghua University, Beijing, China
Email: lizhenhua1983@tsinghua.edu.cn,=C2=A0<= a href=3D"mailto:lizhenhua1983@gmail.com" target=3D"_blank">lizhenhua1983@g= mail.com
Phone: +86-13552819836 (@Beijing)
--001a1142ef3ee5c8e0051f50de79-- From nobody Thu Sep 10 18:44:59 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8A61A3BA1 for ; Thu, 10 Sep 2015 18:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7XsAn14BRa6 for ; Thu, 10 Sep 2015 18:44:56 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D85B1B3CE3 for ; Thu, 10 Sep 2015 18:44:56 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so60212121pac.2 for ; Thu, 10 Sep 2015 18:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:cc:references:subject:mime-version :content-type:content-transfer-encoding:content-disposition; bh=4OYHV8R7nzTlthSQWOBBfW+Kx3Pm1zqQ/P+Hh9lc9MY=; b=LKPJFtGc2UXs2v7nxEt+l1aZN++kTMdVf76rDxiz7rYuY+gfE4X0hEJMBxctYf49sS si1+aniL90ED6YPoOjSbuUZsjiYMDOXaWpqRarr6SCQ/ohAx2i4BINIIlinZ0Nf1xDw3 b4fqLVfn2TWGJs+oUO/UaTkfvnaSNPxduiBz4xRtfSgCY2aFDqcn5l3BR08vIb/G8Nuh l+KXzw22jCmi12t2+GU5K8sfIboyzhGMku59XuygSFbU2ZBloh9lyVWXAhoVtkG7jPVu j+2I+sX+bHOKHtqt3e9NzKTb0bNor2J6LiSo2Dyh7N0v2EuHWiiNMewWDYpNCec17L4f m73A== X-Received: by 10.68.98.5 with SMTP id ee5mr89871475pbb.95.1441935896219; Thu, 10 Sep 2015 18:44:56 -0700 (PDT) Received: from [10.205.37.166] ([119.28.3.169]) by smtp.gmail.com with ESMTPSA id ki3sm14402175pbc.9.2015.09.10.18.44.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Sep 2015 18:44:55 -0700 (PDT) Message-ID: <55f23217.83ca440a.d1d99.770f@mx.google.com> X-Google-Original-Message-ID: Date: Fri, 11 Sep 2015 09:44:50 +0800 From: Linhui Sun To: storagesync References: <20150911012237.11127.4193.idtracker@ietfa.amsl.com> X-Mailer: YoMail.Win X-YoMail-GUID: emc_e2254b6ff2644f43b908c794d4999a87 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 Content-Disposition: inline Archived-At: Cc: Marc Blanchet , Yong Cui , Ted Lemon Subject: [Storagesync] fw:New Version Notification for draft-cui-iss-problem-01.txt X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 01:44:57 -0000 PGJvZHk+PGRpdiBzdHlsZT0iIj4KCQkJCQpIaSBhbGwsPGRpdj48YnI+PC9kaXY+PGRpdj5XZSd2 ZSB1cGRhdGVkIHRoZSBuZXcgdmVyc2lvbiBmb3ImbmJzcDtkcmFmdC1jdWktaXNzLXByb2JsZW0s IHRoZSBtYWpvciBjaGFuZ2VzIGluY2x1ZGUsPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4xKSBB ZGQgYSBuZXcgc2VjdGlvbiBjYWxsZWQgIlJlbGF0ZWQgV29yayIgdG8gbGlzdCB0aGUgZGlmZmVy ZW5jZXMgYmV0d2VlbiBJU1MgYW5kIHJzeW5jIG92ZXIgV2ViREFWLiBIb3BlIHRoaXMgY291bGQg aGVscCB0byBtYWtlIGl0IGNsZWFyZXIgd2h5IHdlJ2QgbGlrZSB0byBwcm9wb3NlIHRoZSBJU1Mg d29yayB3aXRoIHRoZSBleGlzdGVuY2Ugb2YgcnN5bmMgb3ZlciBXZWJEQVYuPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj4yKSBBZGQgYSBuZXcgcHJvYmxlbSBjYWxsZWQgIlVuc2F0aXNmYWN0b3J5 IENvbGxhYm9yYXRpdmUgV29yayBBYmlsaXR5Ii4gVW5leHBlY3RlZCBiZWhhdmlvciBvZiBwYXJh bGxlbCB1cGRhdGUgKHZlcnNpb24gY29uZmxpY3QpIGlzIGlsbHVzdHJhdGVkIGhlcmUuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5XZSBob3BlIHRvIGdldCBmZWVkYmFjay9pbnB1dCBmcm9tIHRo ZSBsaXN0IGFuZCBjb21tZW50cyBhcmUgbW9yZSB0aGFuIHdlbGNvbWUuPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+PGRpdj5MaW5odWk8L2Rpdj48ZGl2Pjxicj4K PGRpdj48YnI+PC9kaXY+Cjxicj4KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPgoJPHNwYW4gZGly PSJsdHIiPiZsdDsKCQk8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+ aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwvYT4mZ3Q7IDIwMTUtMDktMTEgMDk6MjI6Mzcg d3JvdGU6Cgk8L3NwYW4+Cgk8YnI+Cgk8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij4KCQk8ZGl2IGRpcj0ibHRyIj4KCQkJPGJyPjxicj5BIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtY3VpLWlzcy1wcm9ibGVtLTAxLnR4dDxicj5oYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IExpbmh1aSBTdW4gYW5kIHBvc3RlZCB0byB0aGU8YnI+SUVURiByZXBv c2l0b3J5Ljxicj48YnI+PGJyPk5hbWU6CQlkcmFmdC1jdWktaXNzLXByb2JsZW08YnI+UmV2aXNp b246CTAxPGJyPlRpdGxlOgkJSW50ZXJuZXQgU3RvcmFnZSBTeW5jOiBQcm9ibGVtIFN0YXRlbWVu dDxicj5Eb2N1bWVudCBkYXRlOgkyMDE1LTA5LTEwPGJyPkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uPGJyPlBhZ2VzOgkJMTQ8YnI+VVJMOiAgICAgICAgICAgIGh0dHBzOi8vPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZyI+d3d3Lmll dGYub3JnPC9hPjwvYT4vaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWN1aS1pc3MtcHJvYmxlbS0wMS50 eHQ8YnI+U3RhdHVzOiAgICAgICAgIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWN1aS1pc3MtcHJvYmxlbS8iPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWN1aS1pc3MtcHJvYmxlbS8iPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWN1aS1pc3MtcHJvYmxlbS88L2E+PC9hPjxicj5IdG1saXpl ZDogICAgICAgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWN1aS1p c3MtcHJvYmxlbS0wMSI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWN1aS1pc3MtcHJvYmxlbS0wMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWN1 aS1pc3MtcHJvYmxlbS0wMTwvYT48L2E+PGJyPkRpZmY6ICAgICAgICAgICA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY3VpLWlzcy1wcm9ibGVtLTAxIj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY3VpLWlzcy1w cm9ibGVtLTAxIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY3VpLWlz cy1wcm9ibGVtLTAxPC9hPjwvYT48YnI+PGJyPjxicj5BYnN0cmFjdDo8YnI+ICAgSW50ZXJuZXQg c3RvcmFnZSBzZXJ2aWNlcyBoYXZlIGJlY29tZSBtb3JlIGFuZCBtb3JlIHBvcHVsYXIuICBUaGV5 PGJyPiAgIGF0dHJhY3QgaHVnZSBudW1iZXIgb2YgdXNlcnMgYW5kIHByb2R1Y2UgYSBzaWduaWZp Y2FudCBzaGFyZSBvZjxicj4gICBJbnRlcm5ldCB0cmFmZmljLiAgSG93ZXZlciwgbW9zdCBleGlz dGluZyBJbnRlcm5ldCBzdG9yYWdlIHNlcnZpY2VzPGJyPiAgIG1ha2UgdXNlIG9mIHByb3ByaWV0 YXJ5IHN5bmMgcHJvdG9jb2xzIHRvIGFjaGlldmUgdGhlIGRhdGE8YnI+ICAgc3luY2hyb25pemF0 aW9uLiAgQW5kIGFsbW9zdCBhbGwgb2YgdGhlbSBhcmUgcHJvdmVkIHRvIGJlIG5vdDxicj4gICBl ZmZpY2llbnQgZW5vdWdoIGFuZCBoYXZlIHJvb20gZm9yIGltcHJvdmVtZW50LiAgVGhpcyBkb2N1 bWVudDxicj4gICBvdXRsaW5lcyB0aGUgcmVsYXRlZCBwcm9ibGVtcyBjYXVzZWQgYnkgaW5lZmZp Y2llbnQgcHJvcHJpZXRhcnkgc3luYzxicj4gICBwcm90b2NvbHMgYW5kIHNob3dzIGEgZGVtYW5k IGZvciBhbiBlZmZpY2llbnQgYW5kIHN0YW5kYXJkIHN5bmM8YnI+ICAgcHJvdG9jb2wuPGJyPjxi cj48YnI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj48YnI+PGJyPjxicj48YnI+UGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbjxicj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxicj48YnI+PGJyPlRoZSBJRVRGIFNlY3JldGFy aWF0PGJyPjxicj48YnI+PGJyPgoJCTwvZGl2PgoJPC9ibG9ja3F1b3RlPgo8L2Rpdj4KCQkJPC9k aXY+PC9kaXY+PC9ib2R5Pg==