Re: [core] group-comm comments
"weigengyu" <weigengyu@bupt.edu.cn> Wed, 06 November 2013 03:25 UTC
Return-Path: <weigengyu@bupt.edu.cn>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ADC21E80CA for <core@ietfa.amsl.com>; Tue, 5 Nov 2013 19:25:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.709
X-Spam-Level:
X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnk4Kka3Nqvs for <core@ietfa.amsl.com>; Tue, 5 Nov 2013 19:25:16 -0800 (PST)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id BF39621E80C9 for <core@ietf.org>; Tue, 5 Nov 2013 19:25:14 -0800 (PST)
Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id D263119F36A; Wed, 6 Nov 2013 11:25:12 +0800 (HKT)
Message-ID: <270AD365740547C1B9F081BD43C30DD3@WeiGengyuPC>
From: weigengyu <weigengyu@bupt.edu.cn>
To: Carsten Bormann <cabo@tzi.org>, consultancy@vanderstok.org
References: <e372c544e2ce817afbd93182edf3ccf3@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com><8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl><031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> <9C4EB1ACA8514ED98F88FBEC588C2FCA@WeiGengyuPC> <D60519DB022FFA48974A25955FFEC08C0561B12E@SAM.InterDigital.com> <39388FEE15F74FECA2DCE5B2C27F2FF6@WeiGengyuPC> <00bc875979c9100652c83cc262a26dac@xs4all.nl> <958625B0F6EC4C44B0E146CD46E4ABBD@WeiGengyuPC> <8e1539df1fad55638a5399a3d3ca0b9f@xs4all.nl> <3B0D81D9-BC1C-4280-BB4B-442FB454D719@tzi.org>
In-Reply-To: <3B0D81D9-BC1C-4280-BB4B-442FB454D719@tzi.org>
Date: Wed, 06 Nov 2013 11:25:12 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="UTF-8"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3505.912
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912
Cc: core <core@ietf.org>
Subject: Re: [core] group-comm comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2013 03:25:19 -0000
Hi, Carsten, Thank you for the information. > Because of the complexity of the subject, CoRE is explicitly chartered not > to attempt work on Reliable Multicast: > »The working group will not develop a reliable multicast solution, > […]«.https://datatracker.ietf.org/wg/core/charter/ Regards, Gengyu Network Technology Center, School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Wednesday, November 06, 2013 12:12 AM To: consultancy@vanderstok.org Cc: weigengyu ; core Subject: Re: [core] group-comm comments On 05 Nov 2013, at 07:34, peter van der Stok <stokcons@xs4all.nl> wrote: > As far as I know algorithms exist, but I don't know about standardization. Reliable multicast has a long history in the IETF. It is not an easy problem, so there even was an IRTF research group for it: http://irtf.org/concluded/rmrg The RMT (reliable multicast transport) working group has concluded in 2006: http://tools.ietf.org/wg/rmt/ The main standards document to look at is RFC5401 in conjunction with RFC 5740 (NORM). Another output of the RMRG, RFC 3208 (PGM) has never been advanced to the standards track, but enjoys some deployment. Other approaches such as RFC 6726 (FLUTE, File Delivery over Unidirectional Transport) are more oriented towards content distribution. None of these attempt to achieve group-wide consistency. RFC 1301 did, as did follow-on proposals such as draft-bormann-mtp-so, but there are strong limitations. If you really need this, you are looking for algorithms such as Paxos: http://en.wikipedia.org/wiki/Paxos_(computer_science) More generally speaking, the CAP theorem applies: http://en.wikipedia.org/wiki/CAP_theorem I.e., you only get at most two out of the three: • Consistency (all nodes see the same data at the same time) • Availability (a guarantee that every request receives a response about whether it was successful or failed) • Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system) Because of the complexity of the subject, CoRE is explicitly chartered not to attempt work on Reliable Multicast: »The working group will not develop a reliable multicast solution, […]«. https://datatracker.ietf.org/wg/core/charter/ Grüße, Carsten
- [core] group-comm comments peter van der Stok
- Re: [core] group-comm comments Dijk, Esko
- Re: [core] group-comm comments peter van der Stok
- Re: [core] group-comm comments Dijk, Esko
- Re: [core] group-comm comments weigengyu
- Re: [core] group-comm comments Rahman, Akbar
- Re: [core] group-comm comments weigengyu
- Re: [core] group-comm comments peter van der Stok
- Re: [core] group-comm comments weigengyu
- Re: [core] group-comm comments peter van der Stok
- Re: [core] group-comm comments Carsten Bormann
- Re: [core] group-comm comments Carsten Bormann
- Re: [core] group-comm comments weigengyu
- Re: [core] group-comm comments weigengyu
- [core] Fw: group-comm comments weigengyu