From trac+ppsp@trac.tools.ietf.org Wed Oct 31 09:45:04 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751A121F8595 for ; Wed, 31 Oct 2012 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79d2V2W6zEfK for ; Wed, 31 Oct 2012 09:45:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id B3C7A21F8472 for ; Wed, 31 Oct 2012 09:45:03 -0700 (PDT) Received: from localhost ([127.0.0.1]:58870 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTbPN-0006HP-2g; Wed, 31 Oct 2012 17:44:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Wed, 31 Oct 2012 16:44:49 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/4#comment:2 Message-ID: <067.31282d0e8c77d73e41437a1eaf655128@trac.tools.ietf.org> References: <052.1b07620768e850cd97c62b8362f9fa05@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <052.1b07620768e850cd97c62b8362f9fa05@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com Resent-Message-Id: <20121031164503.B3C7A21F8472@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 09:45:03 -0700 (PDT) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Thu, 01 Nov 2012 02:18:32 -0700 Cc: ppsp@ietf.org Subject: Re: [ppsp] #4: Should we have explicit CHOKE/UNCHOKE messages? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:45:04 -0000 #4: Should we have explicit CHOKE/UNCHOKE messages? Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Yes. Added in -03. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Wed Oct 31 09:45:58 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8C121F862B for ; Wed, 31 Oct 2012 09:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrjB0435Yhpw for ; Wed, 31 Oct 2012 09:45:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id ECDFE21F8605 for ; Wed, 31 Oct 2012 09:45:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:59073 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTbQR-0001ZG-NA; Wed, 31 Oct 2012 17:45:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Wed, 31 Oct 2012 16:45:55 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/21#comment:1 Message-ID: <067.3ea531fc98927a44cf17526326ba0bd7@trac.tools.ietf.org> References: <052.df4650be53c3a3b114f24d675f7b67d2@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <052.df4650be53c3a3b114f24d675f7b67d2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com Resent-Message-Id: <20121031164557.ECDFE21F8605@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 09:45:57 -0700 (PDT) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Thu, 01 Nov 2012 02:18:32 -0700 Cc: ppsp@ietf.org Subject: Re: [ppsp] #21: What information is required in on-the-wire protocol to allow for different congestion control mechanisms? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:45:58 -0000 #21: What information is required in on-the-wire protocol to allow for different congestion control mechanisms? Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: -03 follows the LEDBAT spec, which means timing info in DATA and ACK messages. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Wed Oct 31 09:46:37 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEB521F870F for ; Wed, 31 Oct 2012 09:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cz15IrJKT4O for ; Wed, 31 Oct 2012 09:46:37 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E046621F86EF for ; Wed, 31 Oct 2012 09:46:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:59106 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTbR4-00056v-N3; Wed, 31 Oct 2012 17:46:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Wed, 31 Oct 2012 16:46:34 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/24#comment:1 Message-ID: <067.cd5d623075e77e3953ada9b2410ee8d2@trac.tools.ietf.org> References: <052.60abb28ba94f970e3a015d5accea5ff9@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <052.60abb28ba94f970e3a015d5accea5ff9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com Resent-Message-Id: <20121031164636.E046621F86EF@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 09:46:36 -0700 (PDT) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Thu, 01 Nov 2012 02:18:32 -0700 Cc: ppsp@ietf.org Subject: Re: [ppsp] #24: Should we remove "RTP Profile for PPSP"? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:46:37 -0000 #24: Should we remove "RTP Profile for PPSP"? Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Yes, UDP+congestion control is the choice of transport in -03. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Wed Oct 31 09:47:31 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7F21F86EB for ; Wed, 31 Oct 2012 09:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbeum3XTg4K5 for ; Wed, 31 Oct 2012 09:47:30 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 49BB921F862B for ; Wed, 31 Oct 2012 09:47:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:59181 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTbRu-0003tD-DB; Wed, 31 Oct 2012 17:47:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Wed, 31 Oct 2012 16:47:26 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/25#comment:1 Message-ID: <067.3b10cecb89e3214d53094d8336326dab@trac.tools.ietf.org> References: <052.cda06177142e828d5f5462edfca8c299@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <052.cda06177142e828d5f5462edfca8c299@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com Resent-Message-Id: <20121031164730.49BB921F862B@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 09:47:28 -0700 (PDT) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Thu, 01 Nov 2012 02:18:32 -0700 Cc: ppsp@ietf.org Subject: Re: [ppsp] #25: Should we define how congestion control is signalled between peers? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:47:31 -0000 #25: Should we define how congestion control is signalled between peers? Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Currently we support only LEDBAT. Should the RMCAT WG give new results a protocol option can be added in the HANDSHAKE. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Wed Oct 31 09:47:59 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A103821F862D for ; Wed, 31 Oct 2012 09:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d98tX1e-VN5h for ; Wed, 31 Oct 2012 09:47:59 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 693F621F862B for ; Wed, 31 Oct 2012 09:47:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:59214 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTbSO-000573-7v; Wed, 31 Oct 2012 17:47:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Wed, 31 Oct 2012 16:47:56 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/27#comment:1 Message-ID: <067.d61777e9be07491c6d98901b31fc7ce2@trac.tools.ietf.org> References: <052.cc6551291f142279089ec6f001995db6@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <052.cc6551291f142279089ec6f001995db6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com Resent-Message-Id: <20121031164758.693F621F862B@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 09:47:58 -0700 (PDT) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Thu, 01 Nov 2012 02:18:32 -0700 Cc: ppsp@ietf.org Subject: Re: [ppsp] #27: Which transport should we support? UDP or TCP? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:47:59 -0000 #27: Which transport should we support? UDP or TCP? Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: UDP with LEDBAT for congestion control in -03. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Wed Oct 31 09:51:47 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAF121F87CC for ; Wed, 31 Oct 2012 09:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQgWdw2P3hEW for ; Wed, 31 Oct 2012 09:51:47 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1427F21F87B5 for ; Wed, 31 Oct 2012 09:51:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:59320 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTbVh-0006On-NK; Wed, 31 Oct 2012 17:51:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Wed, 31 Oct 2012 16:51:21 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/22#comment:1 Message-ID: <067.151a11706f0766b7ed0081e56dcc0dc2@trac.tools.ietf.org> References: <052.b7284c79ac86b8bfac53df4426cee929@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <052.b7284c79ac86b8bfac53df4426cee929@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com Resent-Message-Id: <20121031165147.1427F21F87B5@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 09:51:47 -0700 (PDT) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Thu, 01 Nov 2012 02:18:32 -0700 Cc: ppsp@ietf.org Subject: Re: [ppsp] #22: Should we define failure behaviour and semantics? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:51:47 -0000 #22: Should we define failure behaviour and semantics? Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: In -03 we chose not to, peers are judged by their behaviour (responding with DATA is good, otherwise bad) and only good peers are used. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Wed Oct 31 09:51:48 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A5A21F87FA for ; Wed, 31 Oct 2012 09:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPcifJKHOBqX for ; Wed, 31 Oct 2012 09:51:47 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8A921F87C6 for ; Wed, 31 Oct 2012 09:51:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:59325 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTbW5-00058F-BK; Wed, 31 Oct 2012 17:51:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Wed, 31 Oct 2012 16:51:45 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/23#comment:1 Message-ID: <067.366904644907130a9cfc11fbde18a561@trac.tools.ietf.org> References: <052.64d57a8d1d692b5960547e31a7b7bf6e@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <052.64d57a8d1d692b5960547e31a7b7bf6e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com Resent-Message-Id: <20121031165147.7A8A921F87C6@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 09:51:47 -0700 (PDT) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Thu, 01 Nov 2012 02:18:32 -0700 Cc: ppsp@ietf.org Subject: Re: [ppsp] #23: Should we define error codes? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:51:48 -0000 #23: Should we define error codes? Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: In -03 we chose not to, peers are judged by their behaviour (responding with DATA is good, otherwise bad) and only good peers are used. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Wed Oct 31 09:52:08 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A8721F87B5 for ; Wed, 31 Oct 2012 09:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3fr9NgyUkE0 for ; Wed, 31 Oct 2012 09:52:08 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E2F4C21F87A2 for ; Wed, 31 Oct 2012 09:52:04 -0700 (PDT) Received: from localhost ([127.0.0.1]:59334 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTbWM-0002pY-A9; Wed, 31 Oct 2012 17:52:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Wed, 31 Oct 2012 16:52:02 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/28#comment:1 Message-ID: <067.6df3eaeab7b23de8ee27b0d8d6b85c74@trac.tools.ietf.org> References: <052.5c365cf66105601e0f7d3e6cd07b6de4@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <052.5c365cf66105601e0f7d3e6cd07b6de4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com Resent-Message-Id: <20121031165207.E2F4C21F87A2@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 09:52:04 -0700 (PDT) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Thu, 01 Nov 2012 02:18:32 -0700 Cc: ppsp@ietf.org Subject: Re: [ppsp] #28: Do we need extra support for graceful and unexpected peer crashes? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:52:09 -0000 #28: Do we need extra support for graceful and unexpected peer crashes? Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: In -03 we chose not to, peers are judged by their behaviour (responding with DATA is good, otherwise bad) and only good peers are used. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From zhangyunfei@chinamobile.com Fri Nov 2 01:29:56 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71ABC21F97F9 for ; Fri, 2 Nov 2012 01:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.623 X-Spam-Level: X-Spam-Status: No, score=-98.623 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAJlRfR95dWW for ; Fri, 2 Nov 2012 01:29:55 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7766921F9752 for ; Fri, 2 Nov 2012 01:29:55 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3CC64E53C; Fri, 2 Nov 2012 16:29:55 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 291ACE521; Fri, 2 Nov 2012 16:29:55 +0800 (CST) Received: from zyf-PC ([10.2.52.192]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012110216295151-21331 ; Fri, 2 Nov 2012 16:29:51 +0800 Date: Fri, 2 Nov 2012 16:29:43 +0800 From: zhangyunfei To: "arno@cs.vu.nl" References: <20121022054506.24206.72390.idtracker@ietfa.amsl.com> <201210221507482101757@chinamobile.com>, <5084F1F7.4020002@cs.vu.nl> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012110216294380861230@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-02 16:29:51, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-02 16:29:54, Serialize complete at 2012-11-02 16:29:54 Content-Type: multipart/alternative; boundary="----=_001_NextPart877808286708_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19332.001 X-TM-AS-Result: No--23.104-7.0-31-10 X-imss-scan-details: No--23.104-7.0-31-10;No--23.104-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: ppsp Subject: [ppsp] comments on draft-ietf-ppsp-peer-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 08:29:56 -0000 This is a multi-part message in MIME format. ------=_001_NextPart877808286708_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgQXJubyAoU3BlYWtpbmcgaW5kaXZpZHVhbGx5KSwNCiAgIEkndmUgcmVhZCB0aGUgZHJhZnQg YW5kIHRoZSBmb2xsb3dpbmcgaXMgbXkgY29tbWVudHM6DQoxKSBUaGUgZWZmZWN0IG9mICJjaG9r ZS91bmNob2tlIiBpcyBub3QgdmVyeSBjbGVhciBpbiB0aGUgZHJhZnQuIFdpbGwgdGhpcyBpbmNy ZWFzZSB0aGUgdHJhbnNmZXIgZWZmaWNpZW5jeT8NCjIpIEkgYW0gZmluZSB3aXRoIHRoZSB1cGRh dGUgb24gc2VjdGlvbiA0LiBJdCdzIGdvb2QgdG8gZGlzY3VzcyB0aGUgY29tcGF0aWJpbGl0eSBp c3N1ZSBpbiBjaHVuayBhZGRyZXNzaW5nLg0KMykgSXMgaXQgYmV0dGVyIHRvIGNvbWJpbmUgc2Vj dGlvbiA1LDYsIDcgaW50byBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24gYXMgYWxsIHRo ZXNlIDMgc2VjdGlvbnMgaW52b2x2ZSBpZGVudGlmeWluZyB0aGUgZGF0YSBpcyBmcm9tIHRoZSBy ZWxpYWJsZSBzb3VyY2UvcGVlcnMsIHdoaWNoIGlzIHJlbGF0ZWQgdG8gc2VjdXJpdHkgbW9yZSBv ciBsZXNzLiBXaGF0J3MgbW9yZSwgaXQgbWFrZXMgdGhlIGRyYWZ0IGJldHRlciBzdHJ1Y3R1cmVk Lg0KICAgIA0KDQpCUg0KeXVuZmVpDQoNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0KRnJvbTogQXJu byBCYWtrZXINCkRhdGU6IDIwMTItMTAtMjIgMTU6MTINClRvOiB6aGFuZ3l1bmZlaQ0KQ0M6IHBw c3A7IHN0ZWZhbm8gcHJldmlkaQ0KU3ViamVjdDogUmU6IFtwcHNwXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLXBwc3AtcGVlci1wcm90b2NvbC0wMy50eHQNCk9uIDIyLzEwLzIwMTIgMDk6MDcsIHpo YW5neXVuZmVpIHdyb3RlOg0KPiBIaSBBcm5vLA0KPiBXb3VsZCB5b3UgcGxlYXNlIHN1bW1hcml6 ZSB0aGUgbWFpbiBjaGFuZ2VzIG9mIHRoaXMgdmVyc2lvbiBvZiBkcmFmdD8NCj4gVGhhdCB3aWxs IGJlIGhlbHBmdWwgdG8gcmV2aWV3IHRoZSBkcmFmdC4gVGhhbmtzLg0KDQpIaSBZdW5mZWkgZXQg YWwNCg0KdGhlcmUgaXMgc3RpbGwgYSByZXZpc2lvbiBoaXN0b3J5IGF0IHRoZSBiYWNrIG9mIHRo ZSBkb2N1bWVudC4gSSB3aWxsIA0KdXBkYXRlIHRoZSB0aWNrZXRzIHNvb246DQoNCiAgICBBcm5v DQoNCiAgICAtMDMgMjAxMi0xMC0yMiBNYWpvciByZXZpc2lvbg0KDQogICAgICAgICogICBVcGRh dGVkIEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24sIHJlbW92aW5nIGRvd25sb2FkIGNhc2UuDQoN CiAgICAgICAgKiAgIFJlc29sdmVkIFRpY2tldCAjNDogQWRkZWQgZXhwbGljaXQgQ0hPS0UvVU5D SE9LRSBtZXNzYWdlcy4NCg0KICAgICAgICAqICAgUmVtb3ZlZCBkaXJlY3RvcnkgbGlzdHMgdW51 c2VkIGluIHN0cmVhbWluZy4NCg0KICAgICAgICAqICAgUmVzb2x2ZWQgVGlja2V0ICMyMiwgIzIz LCAjMjg6IEZhaWx1cmUgYmVoYXZpb3VyLCBlcnJvciBjb2Rlcw0KICAgICAgICAgICAgYW5kIGRl YWxpbmcgd2l0aCBwZWVyIGNyYXNoZXMuDQoNCiAgICAgICAgKiAgIFJlc29sdmVkIFRpY2tldCAj MTM6IENodW5rIHJhbmdlcyBhcmUgdGhlIGRlZmF1bHQgY2h1bmsNCiAgICAgICAgICAgIGFkZHJl c3Npbmcgc2NoZW1lIHRoYXQgYWxsIHBlZXJzIE1VU1Qgc3VwcG9ydC4NCg0KICAgICAgICAqICAg QWRkZWQgYSBzZWN0aW9uIG9uIGNvbXBhdGliaWxpdHkgYmV0d2VlbiBjaHVuayBhZGRyZXNzaW5n DQogICAgICAgICAgICBzY2hlbWVzLg0KDQogICAgICAgICogICBFeHBhbmRlZCB0aGUgZXhwbGFu YXRpb24gb2YgVW5pZmllZCBNZXJrbGUgVHJlZXMgYXMgYSBtZXRob2QNCiAgICAgICAgICAgIGZv ciBjb250ZW50IGludGVncml0eSBwcm90ZWN0aW9uIGZvciBsaXZlIHN0cmVhbXMuDQoNCiAgICAg ICAgKiAgIEFkZGVkIGEgc2VjdGlvbiBvbiBmb3JnZXR0aW5nIGNodW5rcyBpbiBsaXZlIHN0cmVh bWluZy4NCg0KICAgICAgICAqICAgQWRkZWQgIkVuZCIgb3B0aW9uIHRvIHByb3RvY29sIG9wdGlv bnMgYW5kIGNvcnJlY3RlZCBidWdzIGluDQogICAgICAgICAgICBVRFAgZW5jYXBzdWxhdGlvbiwg Zm9sbG93aW5nIEthcmwgS251dHNzb24ncyBjb21tZW50cy4NCg0KICAgICAgICAqICAgQWRkZWQg U0hBLTIgc3VwcG9ydCBmb3IgTWVya2xlIEhhc2ggZnVuY3Rpb25zLg0KDQogICAgICAgICogICBB ZGRlZCBjb250ZW50IGludGVncml0eSBwcm90ZWN0aW9uIG1ldGhvZHMgZm9yIGxpdmUgc3RyZWFt aW5nDQogICAgICAgICAgICB0byB0aGUgcmVsZXZhbnQgcHJvdG9jb2wgb3B0aW9uLg0KDQogICAg ICAgICogICBBZGRlZCBhIExpdmUgU2lnbmF0dXJlIEFsZ29yaXRobSBwcm90b2NvbCBvcHRpb24u DQoNCiAgICAgICAgKiAgIFJlc29sdmVkIFRpY2tldCAjMjQrMjc6IFRoZSBjaG9pY2UgZm9yIFVE UCArIExFREJBVCBhcw0KICAgICAgICAgICAgdHJhbnNwb3J0IGhhcyBub3cgYmVlbiByZWZsZWN0 ZWQgaW4gdGhlIGRyYWZ0LiAgVENQIGFuZCBSVFANCiAgICAgICAgICAgIGVuY2Fwc3VsYXRpb25z IGhhdmUgYmVlbiByZW1vdmVkLg0KDQogICAgICAgICogICBTdXBlcmZsdW91cyBwYXJ0cyBvZiBT ZWN0aW9uIDEwIG9uIGV4dGVuc2liaWxpdHkgaGF2ZSBiZWVuDQogICAgICAgICAgICByZW1vdmVk Lg0KDQogICAgICAgICogICBSZW1vdmVkIGFwcGVuZGl4IHdpdGggUmF0aW9uYWxlLg0KDQogICAg ICAgICogICBSZXNvbHZlZCBUaWNrZXQgIzIxKzI1OiBQUFNQUCBjdXJyZW50bHkgdXNlcyBMRURC QVQgYW5kIHRoZQ0KICAgICAgICAgICAgREFUQSBhbmQgQUNLIG1lc3NhZ2VzIG5vdyBjb250YWlu IHRoZSB0aW1lIGZpZWxkcyBpdA0KICAgICAgICAgICAgcmVxdWlyZXMuICBTaG91bGQgb3RoZXIg Y29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobXMgYmUNCiAgICAgICAgICAgIHN1cHBvcnRlZCBp biB0aGUgZnV0dXJlLCBhIHByb3RvY29sIG9wdGlvbiB3aWxsIGJlIGFkZGVkLg== ------=_001_NextPart877808286708_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Arno (Speaking individually),
   I've read the draft and the following is my comments:
1) The effect of "choke/unchoke" is not very clear in the draft. Will= this=20 increase the transfer efficiency?
2) I am fine with the update on section 4. It's good to discuss the=20 compatibility issue in chunk addressing.
3) Is it better to combine section 5,6, 7 into security consideration= =20 section as all these 3 sections involve identifying the data is from = the=20 reliable source/peers, which is related to security more or less. What's m= ore,=20 it makes the draft better structured.
   
 
BR
yunfei
 
 
zhangyunfei
 
From: Arno Bakker
Date: 2012-10-22 15:12
To: zhangyunfei
CC: ppsp; stefano previdi
Subject: Re: [ppsp] I-D Action:=20 draft-ietf-ppsp-peer-protocol-03.txt
On 22/10/2012 09:07, zhangyunfei wrote:
> Hi Arno,
> Would you please summarize the mai= n changes of this version of draft?
> That will be helpful to review&nbs= p;the draft. Thanks.
 
Hi Yunfei et al
 
there is still a revision history at&nb= sp;the back of the document. I will 
update the tickets soon:
 
    Arno
 
    -03 2012-10-22 Major revision
 
        *   Up= dated Abstract and Introduction, removing downloa= d case.
 
        *   Re= solved Ticket #4: Added explicit CHOKE/UNCHOKE&nb= sp;messages.
 
        *   Re= moved directory lists unused in streaming.
 
        *   Re= solved Ticket #22, #23, #28: Failure behavio= ur, error codes
           &nb= sp;and dealing with peer crashes.
 
        *   Re= solved Ticket #13: Chunk ranges are the = ;default chunk
           &nb= sp;addressing scheme that all peers MUST sup= port.
 
        *   Ad= ded a section on compatibility between chunk=  addressing
           &nb= sp;schemes.
 
        *   Ex= panded the explanation of Unified Merkle Tre= es as a method
           &nb= sp;for content integrity protection for live = ;streams.
 
        *   Ad= ded a section on forgetting chunks in l= ive streaming.
 
        *   Ad= ded "End" option to protocol options and&nbs= p;corrected bugs in
           &nb= sp;UDP encapsulation, following Karl Knutsson's c= omments.
 
        *   Ad= ded SHA-2 support for Merkle Hash functions.=
 
        *   Ad= ded content integrity protection methods for = ;live streaming
           &nb= sp;to the relevant protocol option.
 
        *   Ad= ded a Live Signature Algorithm protocol opti= on.
 
        *   Re= solved Ticket #24+27: The choice for UDP&nbs= p;+ LEDBAT as
           &nb= sp;transport has now been reflected in the&n= bsp;draft.  TCP and RTP
           &nb= sp;encapsulations have been removed.
 
        *   Su= perfluous parts of Section 10 on extensibili= ty have been
           &nb= sp;removed.
 
        *   Re= moved appendix with Rationale.
 
        *   Re= solved Ticket #21+25: PPSPP currently uses L= EDBAT and the
           &nb= sp;DATA and ACK messages now contain the&nbs= p;time fields it
           &nb= sp;requires.  Should other congestion control&nbs= p;algorithms be
           &nb= sp;supported in the future, a protocol optio= n will be added.
 
 
------=_001_NextPart877808286708_=------ From zhangyunfei@chinamobile.com Sun Nov 4 19:28:43 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6304821F8979 for ; Sun, 4 Nov 2012 19:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.023 X-Spam-Level: X-Spam-Status: No, score=-97.023 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUhlpXPkMAB6 for ; Sun, 4 Nov 2012 19:28:43 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8F68621F847D for ; Sun, 4 Nov 2012 19:28:42 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 98390E474; Mon, 5 Nov 2012 11:28:41 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 74B4EE3FF; Mon, 5 Nov 2012 11:28:41 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012110511283963-10601 ; Mon, 5 Nov 2012 11:28:39 +0800 Date: Mon, 5 Nov 2012 11:28:37 +0800 From: zhangyunfei To: "Yingjie Gu(yingjie)" , "'Rui Cruz'" X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012110511283736034341@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-05 11:28:39, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-05 11:28:40, Serialize complete at 2012-11-05 11:28:40 Content-Type: multipart/alternative; boundary="----=_001_NextPart425056685730_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19340.004 X-TM-AS-Result: No--9.278-7.0-31-10 X-imss-scan-details: No--9.278-7.0-31-10;No--9.278-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: ppsp Subject: [ppsp] tracker protocol review X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 03:28:43 -0000 This is a multi-part message in MIME format. ------=_001_NextPart425056685730_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGkgUnVpIGFuZCBZaW5namllIChTcGVha2luZyBpbmRpdmlkdWFsbHkpICwNCiAgICBJIGhhdmUg cmVhZCB0aGUgdXBkYXRlZCB0cmFja2VyIHByb3RvY29sIGRyYWZ0IGFuZCBoYXZlIHRoZSBmb2xs b3dpbmcgY29tbWVudHM6DQoxKSBFbmNvZGluZyBpc3N1ZTogSXQncyBnb29kIHRvIG1lbnRpb24g dGhhdCBQUFNQLVRQIGlzIGludGVuZGVkIHRvIHN1cHBvcnQgYmluYXJ5IGVuY29kaW5nIGluIHNl Y3Rpb24gNC4gSG93ZXZlciBpbiBzZWN0aW9uIDUsIDcgYW5kIDgsIGh0dHArWE1MIGlzIHN0aWxs IGluIHRoZSBtYWluIHBhZ2UuIElzIHRoaXMganVzdCBmb3IgZXhhbXBsZT8gT3IgYSBnZW5lcmFs IHNlbWFudGljcyBkZXNwZXJhdGlvbiBpcyBlbm91Z2g/IEkgdGhpbmsgbXVjaCBvZiBzZWN0aW9u IDcuMSBpbiBjdXJyZW50IHZlcnNpb24gY2FuIGJlIHBsYWNlZCBpbiBBcHBlbmRpeCBBLiBBcmUg eW91IGludGVuZGluZyB0byB1c2UgRVhJIGZvciB0aGUgYmluYXJ5IGVuY29kaW5nIGFuZCBkbyB5 b3Ugc3RpbGwgbmVlZCBodHRwIGZvciB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQ/DQoyKSAgQ2hl Y2sgdGhlIHNlY3Rpb24gMTAgZm9yIHRoZSBYTUwgZGVzY3JpcHRpb25zLiBEbyB3ZSBuZWVkIHRo ZSB1cGRhdGUgb2YgdGhpcyBwYXJ0Pw0KMylTZWN1cml0eSBwYXJ0LCBzZWN0aW9uIDkuMiwgaG93 IGRvZXMgdGhlIGNvbnRlbnQgaW50ZWdyaXR5IGNoZWNrIHJlbGF0ZWQgdG8gdGhlIHRyYWNrZXIg cHJvdG9jb2wgc2hvdWxkIGJlIGJldHRlciBleHBsYWluZWQuDQoNCkJSDQpZdW5mZWkNCg0KDQoN Cg0Kemhhbmd5dW5mZWk= ------=_001_NextPart425056685730_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Hi Rui and Yingjie (Speaking individually) ,
    I have read the updated tracker protocol draft and= have=20 the following comments:
1) Encoding issue: It's good to mention that PPSP-TP is intended to s= upport=20 binary encoding in section 4. However in section 5, 7 and 8, http+XML is s= till=20 in the main page. Is this just for example? Or a general semantics=20 desperation is enough? I think much of section 7.1 in current ve= rsion=20 can be placed in Appendix A. Are you intending to use EXI for the bin= ary=20 encoding and do you still need http for the underlying transport?
2)  Check the section 10 for the XML descriptions. Do we ne= ed the=20 update of this part?
3)Security part, section 9.2, how does the content integrity check re= lated=20 to the tracker protocol should be better explained.
 
BR
Yunfei
 
zhangyunfei
------=_001_NextPart425056685730_=------ From zhangyunfei@chinamobile.com Sun Nov 4 21:40:12 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE9E21F88D4 for ; Sun, 4 Nov 2012 21:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.842 X-Spam-Level: X-Spam-Status: No, score=-92.842 tagged_above=-999 required=5 tests=[AWL=-4.714, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRs8GtoWAoL8 for ; Sun, 4 Nov 2012 21:40:11 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D318721F88C1 for ; Sun, 4 Nov 2012 21:40:10 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id E8068E403; Mon, 5 Nov 2012 13:40:11 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id D9785E3E1; Mon, 5 Nov 2012 13:40:11 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012110513400822-13201 ; Mon, 5 Nov 2012 13:40:08 +0800 Date: Mon, 5 Nov 2012 13:40:06 +0800 From: zhangyunfei To: =?gb2312?B?J7XLwenA8ic=?= , "Yingjie Gu(yingjie)" , "'Rui Cruz'" References: <2012110511283736034341@chinamobile.com>, <002001cdbb0b$9e8ff000$dbafd000$@com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <201211051340060015086@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-05 13:40:08, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-05 13:40:10, Serialize complete at 2012-11-05 13:40:10 Content-Type: multipart/alternative; boundary="----=_001_NextPart656750100165_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19340.004 X-TM-AS-Result: No--33.874-7.0-31-10 X-imss-scan-details: No--33.874-7.0-31-10;No--33.874-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: ppsp Subject: [ppsp] =?gb2312?b?u9i4tDogtPC4tDogIHRyYWNrZXIgcHJvdG9jb2wgcmV2?= =?gb2312?b?aWV3?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 05:40:12 -0000 This is a multi-part message in MIME format. ------=_001_NextPart656750100165_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" WWVzLCBMaW5nbGkuIEkgbWVhbiBpdCB3b3VsZCBiZSBnb29kIHRvIHdyaXRlIGV4cGxpY2l0bHkg dG8gc2F5IGhvdyB0byBoYW5kbGUgdGhpcyBpbiB0cmFja2VyIHByb3RvY29sLg0KDQpCUg0KWXVu ZmVpDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQq3orz+yMujuiC1y8HpwPIvTGluZ2xpIERlbmcNCrei y83Ksbzko7ogMjAxMi0xMS0wNSAxMjoxMQ0KytW8/sjLo7ogJ3poYW5neXVuZmVpJzsgJ1lpbmdq aWUgR3VcKHlpbmdqaWVcKSc7ICdSdWkgQ3J1eicNCrOty82juiAncHBzcCcNCtb3zOKjuiC08Li0 OiBbcHBzcF0gdHJhY2tlciBwcm90b2NvbCByZXZpZXcNCll1bmZlaSwNCkFzIGZvciB5b3VyIGNv bW1lbnQgYXNraW5nIGZvciBjbGFyaWZpY2F0aW9uIGZvciBjb250ZW50IGludGVncml0eaGvcyBy ZWxhdGlvbiB0byB0cmFja2VyIHByb3RvY29sLCBJIHdvdWxkIGxpa2UgdG8gZXhwbGFpbiB0aGF0 IGFzIHBvaW50ZWQgb3V0IGF0IHRoZSBlbmQgb2YgU2VjdGlvbiA5LjIsICBjb250ZW50IHBvbGx1 dGlvbg0KY2FuIGJlIGRldGVjdGVkIGJ5IGluY29ycG9yYXRpbmcgaW50ZWdyaXR5IHZlcmlmaWNh dGlvbiBzY2hlbWVzIGZvciBwdWJsaXNoZWQgc2hhcmVkIGNvbnRlbnRzLiAgQXMgY29udGVudCBj aHVua3MgYXJlIHRyYW5zZmVycmVkIGluZGVwZW5kZW50bHkgYW5kIGNvbmN1cnJlbnRseSwgYSBj b3JyZXNwb25kZW50IGNodW5rLWxldmVsIGludGVncml0eSB2ZXJpZmljYXRpb24gTVVTVCBiZSB1 c2VkLCBjaGVja2VkIHdpdGggc2lnbmVkIGZpbmdlcnByaW50cyByZWNlaXZlZCBmcm9tIGF1dGhl bnRpYyBvcmlnaW4uDQpJbiBvdGhlciB3b3JkcywgdGhlc2UgZmluZ2VycHJpbnRzIE1VU1QgYmUg c2lnbmVkIGJ5IHRoZSBhdXRoZW50aWMgb3JpZ2luIG9mIHRoZSBjb250ZW50LCBhbmQgTVVTVCBi ZSBkaXN0cmlidXRlZCBpbiBhIHRydXN0d29ydGh5IG1hbm5lciBhZ2FpbnN0IG1hbmlwdWxhdGlv biBhbmQgZm9yZ2VyeS4NCkl0IHdvdWxkIGJlIHJlYXNvbmFibGUgdG8gZXhwZWN0IHN1Y2ggZGlz dHJpYnV0aW9uIGJlIGhhbmRsZWQgYnkgdGhlIHRyYWNrZXIgcHJvdG9jb2wgaW4gYSBzZWN1cml0 eS1lbmhhbmNlZCBzZW5zZS4NCkJSDQpMaW5nbGkNCreivP7IyzogcHBzcC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cHBzcC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIHpoYW5neXVuZmVpDQq3osvN yrG85DogMjAxMsTqMTHUwjTI1SAyMjoyOQ0KytW8/sjLOiBZaW5namllIEd1KHlpbmdqaWUpOyAn UnVpIENydXonDQqzrcvNOiBwcHNwDQrW98ziOiBbcHBzcF0gdHJhY2tlciBwcm90b2NvbCByZXZp ZXcNCiANCkhpIFJ1aSBhbmQgWWluZ2ppZSAoU3BlYWtpbmcgaW5kaXZpZHVhbGx5KSAsDQogICAg SSBoYXZlIHJlYWQgdGhlIHVwZGF0ZWQgdHJhY2tlciBwcm90b2NvbCBkcmFmdCBhbmQgaGF2ZSB0 aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KMSkgRW5jb2RpbmcgaXNzdWU6IEl0J3MgZ29vZCB0byBt ZW50aW9uIHRoYXQgUFBTUC1UUCBpcyBpbnRlbmRlZCB0byBzdXBwb3J0IGJpbmFyeSBlbmNvZGlu ZyBpbiBzZWN0aW9uIDQuIEhvd2V2ZXIgaW4gc2VjdGlvbiA1LCA3IGFuZCA4LCBodHRwK1hNTCBp cyBzdGlsbCBpbiB0aGUgbWFpbiBwYWdlLiBJcyB0aGlzIGp1c3QgZm9yIGV4YW1wbGU/IE9yIGEg Z2VuZXJhbCBzZW1hbnRpY3MgZGVzcGVyYXRpb24gaXMgZW5vdWdoPyBJIHRoaW5rIG11Y2ggb2Yg c2VjdGlvbiA3LjEgaW4gY3VycmVudCB2ZXJzaW9uIGNhbiBiZSBwbGFjZWQgaW4gQXBwZW5kaXgg QS4gQXJlIHlvdSBpbnRlbmRpbmcgdG8gdXNlIEVYSSBmb3IgdGhlIGJpbmFyeSBlbmNvZGluZyBh bmQgZG8geW91IHN0aWxsIG5lZWQgaHR0cCBmb3IgdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0Pw0K MikgIENoZWNrIHRoZSBzZWN0aW9uIDEwIGZvciB0aGUgWE1MIGRlc2NyaXB0aW9ucy4gRG8gd2Ug bmVlZCB0aGUgdXBkYXRlIG9mIHRoaXMgcGFydD8NCjMpU2VjdXJpdHkgcGFydCwgc2VjdGlvbiA5 LjIsIGhvdyBkb2VzIHRoZSBjb250ZW50IGludGVncml0eSBjaGVjayByZWxhdGVkIHRvIHRoZSB0 cmFja2VyIHByb3RvY29sIHNob3VsZCBiZSBiZXR0ZXIgZXhwbGFpbmVkLg0KIA0KQlINCll1bmZl aQ0KIA0KDQoNCg0Kemhhbmd5dW5mZWk= ------=_001_NextPart656750100165_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Yes, Lingli. I mean it would be good to write explicitly to say = how to=20 handle this in tracker protocol.
 
BR
Yunfei
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA =B5=CB=C1=E9=C0=F2/Lingli=20 Deng
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-11-05 12:11
=CA=D5=BC=FE=C8=CB=A3=BA 'zhangyunfei'; 'Yingjie Gu\(yingjie\)'; 'Rui Cruz'
=B3=AD=CB=CD=A3=BA 'ppsp= '
=D6=F7=CC=E2=A3=BA =B4=F0=B8=B4: [ppsp] tracker protocol = review

Yunfei,

As for your comment asking for clarification for content inte= grity=A1=AFs=20 relation to tracker protocol, I would like to explain that as pointed out = at the=20 end of Section 9.2,  content pollution

can be detected by incor= porating=20 integrity verification schemes for published shared contents.  As con= tent=20 chunks are transferred independently and concurrently, a correspondent=20 chunk-level integrity verification MUST be used, checked with signed=20 fingerprints received from authentic origin.

In other words, these fingerprints MUST be signed by the auth= entic=20 origin of the content, and MUST be distributed in a trustworthy manner aga= inst=20 manipulation and forgery.

It would be reasonable to expect such distribution be handled= by the=20 tracker protocol in a security-enhanced sense.

BR

Lingli

=B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED <= /B>zhangyunfei
=B7=A2=CB=CD=CA=B1=BC= =E4: 2012=C4=EA11=D4=C24=C8=D5=20 22:29
=CA=D5=BC=FE=C8=CB: Yingjie=20 Gu(yingjie); 'Rui Cruz'
=B3=AD=CB=CD: ppsp
=D6=F7=CC=E2:=20 [ppsp] tracker protocol review

 

Hi Rui and Yingjie (Speaking individually)=20 ,

    I have read the updated tracker protocol d= raft and=20 have the following comments:

1) Encoding issue: It's good to mention that PPSP-TP is inten= ded to=20 support binary encoding in section 4. However in section 5, 7 and 8, http+= XML is=20 still in the main page. Is this just for example? Or a general semant= ics=20 desperation is enough? I think much of section 7.1 in current ve= rsion=20 can be placed in Appendix A. Are you intending to use EXI for the bin= ary=20 encoding and do you still need http for the underlying=20 transport?

2)  Check the section 10 for the XML descriptions. = Do we=20 need the update of this part?

3)Security part, section 9.2, how does the content integrity = check=20 related to the tracker protocol should be better=20 explained.

 

BR

Yunfei

 

zhangyunfei

------=_001_NextPart656750100165_=------ From rui.cruz@ieee-pt.org Mon Nov 5 02:24:59 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C04A21F8674 for ; Mon, 5 Nov 2012 02:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftSUhn1de9Ut for ; Mon, 5 Nov 2012 02:24:58 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18E5321F85C3 for ; Mon, 5 Nov 2012 02:24:57 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jc3so1946267bkc.31 for ; Mon, 05 Nov 2012 02:24:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=+rVc9SlhLI0892VSNZ0nUR8pCshB8s+UyhlKBpU0xvU=; b=ekIZSuwFfBMii6J1jWhnoL5l9LqdQddlnojMARz4kNrCK8UlMS5F6XimbWDaAgXqX/ jzC5a3G682sIDe+BCSePuIwXhZ+zQ+09mfRr4/FJaclVuDueRJaYyawN4PyvYsiFda/9 5Ye8dJZIDpGfxqxDu1hf1oIbFrB8uGX3Q1CWRBVMnV5cvxXEl9fsDEzXgtHEjq6herae Gw2J6AQ/0HeRx+BCdlJ+2h0aysJE3I92Lnb6W3nEEEycby70GDsmuweLZBYHZ1aEjv8W 5KkDb2lY56rFoz9eZUso24dKRfcLgKprNxTcS4N23U3hK1dyWtSpsg6vDeOpcW09pRj3 PsSg== Received: by 10.204.9.4 with SMTP id j4mr2190826bkj.22.1352111096807; Mon, 05 Nov 2012 02:24:56 -0800 (PST) Received: from [192.168.1.218] (89-180-43-105.net.novis.pt. [89.180.43.105]) by mx.google.com with ESMTPS id s20sm9193674bkw.15.2012.11.05.02.24.52 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 02:24:55 -0800 (PST) References: <2012110511283736034341@chinamobile.com> In-Reply-To: <2012110511283736034341@chinamobile.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-A6E4DBCD-056C-43A4-9AB6-894B1D65FF95 Message-Id: <5F56F444-8B12-41F9-87C7-7043185321EB@ieee-pt.org> X-Mailer: iPad Mail (10A523) From: Rui Cruz Date: Mon, 5 Nov 2012 10:24:50 +0000 To: zhangyunfei X-Gm-Message-State: ALoCoQlPiiZuD1dmlYIOFS2vWs+DZXtm9yhhIIu7I6ecpG7rob7iDsc/9sl6HV3FnnXPOVAd6OZB Cc: ppsp , Rui Cruz Subject: Re: [ppsp] tracker protocol review X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 10:24:59 -0000 --Apple-Mail-A6E4DBCD-056C-43A4-9AB6-894B1D65FF95 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Yunfei, Thank you very much for the comments. About Encoding:=20 Binary encoding of the protocol (both at the Request/Response layer or the M= essaging layer) can be done without modifying the grammar of the protocol. E= XI represents the Structure and the Content of an XML document as an EXI bin= ary stream (header and body), therefore, it is just a matter of serializatio= n of the XML Infoset into an octet stream, suitable for HTTP transfer encodi= ng, enabling content negotiation to ensure that clients and servers understa= nd EXI. Similarly, HTTP messages transporting EXI can have a binary wire fo= rmat, as being prepared for HTTP/2.0. We have already an implementation of t= he Tracker Protocol over SPDY, where the HTTP messages are binary encoded, w= ith the advantages of multiplexing requests and header compression. Cumprimentos/Regards, Rui Cruz Sent from my iPad2 On 05/11/2012, at 03:28, zhangyunfei wrote: > Hi Rui and Yingjie (Speaking individually) , > I have read the updated tracker protocol draft and have the following c= omments: > 1) Encoding issue: It's good to mention that PPSP-TP is intended to suppor= t binary encoding in section 4. However in section 5, 7 and 8, http+XML is s= till in the main page. Is this just for example? Or a general semantics desp= eration is enough? I think much of section 7.1 in current version can be pla= ced in Appendix A. Are you intending to use EXI for the binary encoding and d= o you still need http for the underlying transport? > 2) Check the section 10 for the XML descriptions. Do we need the update o= f this part? > 3)Security part, section 9.2, how does the content integrity check related= to the tracker protocol should be better explained. > =20 > BR > Yunfei > =20 > zhangyunfei > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail-A6E4DBCD-056C-43A4-9AB6-894B1D65FF95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Yunfei,

Th= ank you very much for the comments.
About Encoding: 
Binary encoding of the protocol (both at the Request/Response layer or the= Messaging layer) can be done without modifying the grammar of the protocol.= EXI represents the Structure and the Content of an XML document as an EXI b= inary stream (header and body), therefore, it is just a matter of serializat= ion of the XML Infoset into an octet stream, suitable for HTTP transfer enco= ding, enabling content negotiation to ensure that clients and servers unders= tand EXI. Similarly, HTTP messages transporting EXI can  have a binary w= ire format, as being prepared for HTTP/2.0. We have already an implementatio= n of the Tracker Protocol over SPDY, where the HTTP messages are binary enco= ded, with the advantages of multiplexing requests and header compression.


Cumprimentos/Regards,
Rui Cruz

Sent from my iPad2

On 05/11/2012, at 03:28, z= hangyunfei <zhangyunfei@ch= inamobile.com> wrote:

=
Hi Rui and Yingjie (Speaking individually) ,
    I have read the updated tracker protocol draft and h= ave=20 the following comments:
1) Encoding issue: It's good to mention that PPSP-TP is intended to sup= port=20 binary encoding in section 4. However in section 5, 7 and 8, http+XML is sti= ll=20 in the main page. Is this just for example? Or a general semantics=20 desperation is enough? I think much of section 7.1 in current vers= ion=20 can be placed in Appendix A. Are you intending to use EXI for the binar= y=20 encoding and do you still need http for the underlying transport?
=
2)  Check the section 10 for the XML descriptions. Do we need= the=20 update of this part?
3)Security part, section 9.2, how does the content integrity check rela= ted=20 to the tracker protocol should be better explained.
 
BR
Yunfei
 
zhangyunfei
____________________= ___________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman= /listinfo/ppsp
= --Apple-Mail-A6E4DBCD-056C-43A4-9AB6-894B1D65FF95-- From rui.cruz@ieee-pt.org Mon Nov 5 05:24:14 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D6C21F84FE for ; Mon, 5 Nov 2012 05:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.7 X-Spam-Level: X-Spam-Status: No, score=-98.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYzVQZEZBvGD for ; Mon, 5 Nov 2012 05:24:13 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0C921F8532 for ; Mon, 5 Nov 2012 05:24:12 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jc3so2043948bkc.31 for ; Mon, 05 Nov 2012 05:24:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=uDWuT0DUjtyfEF+LMt1o9gZlS+6WzLJRmj76UtBfMAk=; b=SSkMVMcJGwOsLw6xvfozo1tLytjZyk+smyKIVoCGbQFitM+oGPow4zavdJpNvTxngN hkXiNL8eoIsMw7qC9TdhcPhVGHJAnFGpO0dnV/2M8eBS3L6yAMXIXVi0J1KOLvQlrjPf Uga+SWZBR0txaZlp/JNCBcTnghN+qukRUqjFlqJ7O9Uwu43NMdm79R9w1jWCKbl1uo2z dJDmO9ZqeskD4ulNLaBTrjkde2ozUjy9b8CDl1C/OXHF5c/WAC8AZjDkZBkRSdcEAWbt hBBozSBYKCL9j2mNp6WT02PvdSi8Bgdmls4TzRdgR1g0UcxT5Szz6E/t/yI/9BPAfCun UqJg== Received: by 10.204.7.213 with SMTP id e21mr2271963bke.32.1352121851321; Mon, 05 Nov 2012 05:24:11 -0800 (PST) Received: from [192.168.0.100] (62.169.111.241.rev.optimus.pt. [62.169.111.241]) by mx.google.com with ESMTPS id s20sm9711650bkw.15.2012.11.05.05.24.07 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 05:24:10 -0800 (PST) Sender: Rui Cruz Content-Type: multipart/alternative; boundary="Apple-Mail=_5640494C-4054-44ED-B220-AC360FF3D664" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Rui Cruz In-Reply-To: <004f01cdbb51$a8afc8d0$fa0f5a70$@com> Date: Mon, 5 Nov 2012 13:24:02 +0000 Message-Id: <0D8207BB-EA12-4ECC-84A8-FDE9611AF6D4@ieee.org> References: <2012110511283736034341@chinamobile.com>, <002001cdbb0b$9e8ff000$dbafd000$@com> <201211051340060015086@chinamobile.com> <004f01cdbb51$a8afc8d0$fa0f5a70$@com> To: =?utf-8?Q?=E9=82=93=E7=81=B5=E8=8E=89/Lingli_Deng?= X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnKLbN43wLrI/dmeBZFaSLk5z8bLBsqq4vjpu+XtgjQJlmmPlUOTvj2RvJntcRKgZkiudh7 Cc: Rui Cruz , 'ppsp' Subject: Re: [ppsp] =?utf-8?b?KioqU1BBTSoqKiA4LjI1OCAoNSkg562U5aSNOiDnrZTlpI06?= =?utf-8?q?__tracker_protocol_review?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:24:14 -0000 --Apple-Mail=_5640494C-4054-44ED-B220-AC360FF3D664 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Yunfei and Lingli, In section 1.2.3 "Content Information Metadata" and 1.2.4 = "Authentication, Confidentiality, Integrity", although informative in = nature, the aspect on content integrity is somewhat raised, but not = described. However, stating in the draft that "content information = metadata used in PPSP may align with MPD formats, such as ISO/IEC = 23009-1" means that content protection and integrity verification = schemes can be distributed by including root fingerprints for each each = video and audio groups described in the MPD of the content. In Appendix B. Media Presentation Description (MPD) of = draft-gu-ppsp-tracker-protocol-07, that situation was fairly described = with examples, but that section was not transferred to the Base-Protocol = draft, as suggested during discussions. In my opinion, I hardly see the distribution of the fingerprints as a = role of the tracker protocol as these schemes are related to the = content, but I would strongly support not just channel-oriented security = in the communication between peers and tracker but also authentication = and authorization mechanisms for the peers. Regards, Rui Cruz rui.cruz@ieee.org IST/INESC-ID/INOV - Lisbon, Portugal __________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp On 05/11/2012, at 12:32, =B5=CB=C1=E9=C0=F2/Lingli Deng = wrote: > All right. I will discuss it with Yingjie and Rui today. See what to = do about it. > Lingli > =B7=A2=BC=FE=C8=CB: zhangyunfei [mailto:zhangyunfei@chinamobile.com]=20= > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C25=C8=D5 0:40 > =CA=D5=BC=FE=C8=CB: '=B5=CB=C1=E9=C0=F2'; Yingjie Gu(yingjie); 'Rui = Cruz' > =B3=AD=CB=CD: ppsp > =D6=F7=CC=E2: =BB=D8=B8=B4: =B4=F0=B8=B4: [ppsp] tracker protocol = review > =20 > Yes, Lingli. I mean it would be good to write explicitly to say how to = handle this in tracker protocol. > =20 > BR > Yunfei > zhangyunfei > =20 > =B7=A2=BC=FE=C8=CB=A3=BA =B5=CB=C1=E9=C0=F2/Lingli Deng > =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-11-05 12:11 > =CA=D5=BC=FE=C8=CB=A3=BA 'zhangyunfei'; 'Yingjie Gu\(yingjie\)'; 'Rui = Cruz' > =B3=AD=CB=CD=A3=BA 'ppsp' > =D6=F7=CC=E2=A3=BA =B4=F0=B8=B4: [ppsp] tracker protocol review > Yunfei, > As for your comment asking for clarification for content integrity=A1=AF= s relation to tracker protocol, I would like to explain that as pointed = out at the end of Section 9.2, content pollution > can be detected by incorporating integrity verification schemes for = published shared contents. As content chunks are transferred = independently and concurrently, a correspondent chunk-level integrity = verification MUST be used, checked with signed fingerprints received = from authentic origin. > In other words, these fingerprints MUST be signed by the authentic = origin of the content, and MUST be distributed in a trustworthy manner = against manipulation and forgery. > It would be reasonable to expect such distribution be handled by the = tracker protocol in a security-enhanced sense. > BR > Lingli > =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED zhangyunfei > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C24=C8=D5 22:29 > =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie); 'Rui Cruz' > =B3=AD=CB=CD: ppsp > =D6=F7=CC=E2: [ppsp] tracker protocol review > =20 > Hi Rui and Yingjie (Speaking individually) , > I have read the updated tracker protocol draft and have the = following comments: > 1) Encoding issue: It's good to mention that PPSP-TP is intended to = support binary encoding in section 4. However in section 5, 7 and 8, = http+XML is still in the main page. Is this just for example? Or a = general semantics desperation is enough? I think much of section 7.1 in = current version can be placed in Appendix A. Are you intending to use = EXI for the binary encoding and do you still need http for the = underlying transport? > 2) Check the section 10 for the XML descriptions. Do we need the = update of this part? > 3)Security part, section 9.2, how does the content integrity check = related to the tracker protocol should be better explained. > =20 > BR > Yunfei > =20 > zhangyunfei > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_5640494C-4054-44ED-B220-AC360FF3D664 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi Yunfei and = Lingli,

In section 1.2.3 "Content Information = Metadata" and 1.2.4 "Authentication, Confidentiality, Integrity", = although informative in nature, the aspect on content integrity is = somewhat raised, but not described. However, stating in the draft that = "content information metadata used in PPSP may align with MPD = formats, such as ISO/IEC 23009-1" means that content protection and = integrity verification schemes can be distributed by including root = fingerprints for each each video and audio groups described = in the MPD of the = content.

In Appendix B. Media Presentation = Description (MPD) of draft-gu-ppsp-tracker-protocol-07, that = situation was fairly described with examples, but that section was not = transferred to the Base-Protocol draft, as suggested during = discussions.

In my opinion, I hardly = see the distribution of the fingerprints as a role of the = tracker protocol as these schemes are related to the content, but I = would strongly support not just channel-oriented security in the = communication between peers and tracker but also authentication and = authorization mechanisms for the peers.

Regards,

Rui = Cruz
<= font class=3D"Apple-style-span" = color=3D"#1555cb">
IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= div>ppsp mailing = list

On 05/11/2012, at 12:32, =B5=CB=C1=E9=C0=F2/Lingli Deng = <denglingli@chinamobile.com&= gt; wrote:

All right. I will discuss it with Yingjie and Rui = today. See what to do about it.
=B7=A2=BC=FE=C8=CB<= span lang=3D"EN-US">: zhangyunfei = [mailto:zhangyunfei@chinamobile.com] 
=B7=A2=CB=CD=CA=B1=BC= =E4: 2012=C4=EA11=D4=C25=C8=D5 0:40
=CA=D5=BC=FE= =C8=CB: '=B5=CB=C1=E9=C0=F2'; Yingjie Gu(yingjie); 'Rui = Cruz'
=B3=AD=CB=CD: ppsp
=D6=F7=CC=E2= : =BB=D8=B8=B4: =B4=F0=B8=B4: [ppsp] tracker protocol = review
 
Yes, Lingli. I mean it would be good to write explicitly to say = how to handle this in tracker = protocol.
 
BR
Yunfei
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA =B5=CB=C1=E9=C0=F2/Lingli = Deng
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-11-05 12:11
=CA=D5=BC=FE=C8=CB=A3=BA 'zhangyunfei'; 'Yingjie Gu\(yingjie\)'; 'Rui = Cruz'
As for your comment asking for = clarification for content integrity=A1=AFs relation to tracker protocol, = I would like to explain that as pointed out at the end of Section 9.2, =  content pollution

can be detected by incorporating integrity verification = schemes for published shared contents.  As content chunks are = transferred independently and concurrently, a correspondent chunk-level = integrity verification MUST be used, checked with signed fingerprints = received from authentic origin.
In = other words, these fingerprints MUST be signed by the authentic origin = of the content, and MUST be distributed in a trustworthy manner against = manipulation and forgery.
It would be reasonable = to expect such distribution be handled by the tracker protocol in a = security-enhanced sense.
=B7=A2=BC=FE=C8=CB<= span lang=3D"EN-US">: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED zhangyunfei
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C24=C8=D5 22:29
=CA=D5=BC=FE= =C8=CB: Yingjie Gu(yingjie); 'Rui = Cruz'
=B3=AD=CB=CD: ppsp
=D6=F7=CC=E2= : [ppsp] tracker protocol = review
 
    = I have read the updated tracker protocol draft and have the following = comments:
1) Encoding issue: = It's good to mention that PPSP-TP is intended to support binary encoding = in section 4. However in section 5, 7 and 8, http+XML is still in the = main page. Is this just for example? Or a general semantics = desperation is enough? I think much of section 7.1 in current = version can be placed in Appendix A. Are you intending to use EXI = for the binary encoding and do you still need http for the = underlying transport?
ppsp@ietf.org
In-Reply-To: <006a01cdbb7c$be5b84a0$3b128de0$@com> Date: Mon, 5 Nov 2012 17:48:58 +0000 Message-Id: References: <2012110511283736034341@chinamobile.com>, <002001cdbb0b$9e8ff000$dbafd000$@com> <201211051340060015086@chinamobile.com> <004f01cdbb51$a8afc8d0$fa0f5a70$@com> <0D8207BB-EA12-4ECC-84A8-FDE9611AF6D4@ieee.org> <006a01cdbb7c$be5b84a0$3b128de0$@com> To: =?utf-8?Q?=E9=82=93=E7=81=B5=E8=8E=89/Lingli_Deng?= X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnlol7dhdBC66jz9IW3gE+Ni9M1QNMyJFRCjI869myI3C+BjO9AE8KoouLeVcB1VNQmplHs Cc: Rui Cruz , 'ppsp' Subject: Re: [ppsp] =?utf-8?b?KioqU1BBTSoqKiA4LjE1OCAoNSkg562U5aSNOiAgKioqU1BB?= =?utf-8?b?TSoqKiA4LjI1OCAoNSkg562U5aSNOiDnrZTlpI06ICB0cmFja2VyIHByb3Rv?= =?utf-8?q?col_review?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:49:13 -0000 --Apple-Mail=_E61F20BF-625B-4382-A81F-DF892D622168 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Lingli, In fact, that was the basic idea, having the hashprints of content at = the MPD, not requiring involvement of the tracker protocol. A few words in security sections, as well as in sections 1.2.3 "Content = Information Metadata" and 1.2.4 "Authentication, Confidentiality, = Integrity", would make this clearer. Regards, Rui Cruz rui.cruz@ieee.org IST/INESC-ID/INOV - Lisbon, Portugal __________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp On 05/11/2012, at 17:41, =B5=CB=C1=E9=C0=F2/Lingli Deng = wrote: > Hi Rui, > =20 > MPD seems fine to me. Shall we add a few words in the security section = to clarify that the integrity problem can be solved by including the = hashprints of the content (be it chunk-level or content-level) into = content information metadata. For instance, as in MPD format. However, = this can also be done through maybe a web portal without tracker=A1=AFs = involvement. > =20 > What do you think? > =20 > BR > Lingli > =20 > =B7=A2=BC=FE=C8=CB: Rui Cruz [mailto:rui.cruz@ieee-pt.org] =B4=FA=B1=ED = Rui Cruz > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C25=C8=D5 8:24 > =CA=D5=BC=FE=C8=CB: =B5=CB=C1=E9=C0=F2/Lingli Deng > =B3=AD=CB=CD: Rui Cruz; 'zhangyunfei'; 'Yingjie Gu(yingjie)'; 'ppsp' > =20 >=20 > =D6=F7=CC=E2: Re: [ppsp] ***SPAM*** 8.258 (5) =B4=F0=B8=B4: =B4=F0=B8=B4= : tracker protocol review > =20 > Hi Yunfei and Lingli, > =20 > In section 1.2.3 "Content Information Metadata" and 1.2.4 = "Authentication, Confidentiality, Integrity", although informative in = nature, the aspect on content integrity is somewhat raised, but not = described. However, stating in the draft that "content information = metadata used in PPSP may align with MPD formats, such as ISO/IEC = 23009-1" means that content protection and integrity verification = schemes can be distributed by including root fingerprints for each each = video and audio groups described in the MPD of the content. > =20 > In Appendix B. Media Presentation Description (MPD) of = draft-gu-ppsp-tracker-protocol-07, that situation was fairly described = with examples, but that section was not transferred to the Base-Protocol = draft, as suggested during discussions. > =20 > In my opinion, I hardly see the distribution of the fingerprints as a = role of the tracker protocol as these schemes are related to the = content, but I would strongly support not just channel-oriented security = in the communication between peers and tracker but also authentication = and authorization mechanisms for the peers. >=20 > Regards, > =20 > Rui Cruz > rui.cruz@ieee.org > =20 > IST/INESC-ID/INOV - Lisbon, Portugal > __________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > =20 > On 05/11/2012, at 12:32, =B5=CB=C1=E9=C0=F2/Lingli Deng = wrote: >=20 >=20 > All right. I will discuss it with Yingjie and Rui today. See what to = do about it. > Lingli > =B7=A2=BC=FE=C8=CB: zhangyunfei [mailto:zhangyunfei@chinamobile.com]=20= > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C25=C8=D5 0:40 > =CA=D5=BC=FE=C8=CB: '=B5=CB=C1=E9=C0=F2'; Yingjie Gu(yingjie); 'Rui = Cruz' > =B3=AD=CB=CD: ppsp > =D6=F7=CC=E2: =BB=D8=B8=B4: =B4=F0=B8=B4: [ppsp] tracker protocol = review > =20 > Yes, Lingli. I mean it would be good to write explicitly to say how to = handle this in tracker protocol. > =20 > BR > Yunfei > zhangyunfei > =20 > =B7=A2=BC=FE=C8=CB=A3=BA =B5=CB=C1=E9=C0=F2/Lingli Deng > =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-11-05 12:11 > =CA=D5=BC=FE=C8=CB=A3=BA 'zhangyunfei'; 'Yingjie Gu\(yingjie\)'; 'Rui = Cruz' > =B3=AD=CB=CD=A3=BA 'ppsp' > =D6=F7=CC=E2=A3=BA =B4=F0=B8=B4: [ppsp] tracker protocol review > Yunfei, > As for your comment asking for clarification for content integrity=A1=AF= s relation to tracker protocol, I would like to explain that as pointed = out at the end of Section 9.2, content pollution > can be detected by incorporating integrity verification schemes for = published shared contents. As content chunks are transferred = independently and concurrently, a correspondent chunk-level integrity = verification MUST be used, checked with signed fingerprints received = from authentic origin. > In other words, these fingerprints MUST be signed by the authentic = origin of the content, and MUST be distributed in a trustworthy manner = against manipulation and forgery. > It would be reasonable to expect such distribution be handled by the = tracker protocol in a security-enhanced sense. > BR > Lingli > =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED zhangyunfei > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C24=C8=D5 22:29 > =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie); 'Rui Cruz' > =B3=AD=CB=CD: ppsp > =D6=F7=CC=E2: [ppsp] tracker protocol review > =20 > Hi Rui and Yingjie (Speaking individually) , > I have read the updated tracker protocol draft and have the = following comments: > 1) Encoding issue: It's good to mention that PPSP-TP is intended to = support binary encoding in section 4. However in section 5, 7 and 8, = http+XML is still in the main page. Is this just for example? Or a = general semantics desperation is enough? I think much of section 7.1 in = current version can be placed in Appendix A. Are you intending to use = EXI for the binary encoding and do you still need http for the = underlying transport? > 2) Check the section 10 for the XML descriptions. Do we need the = update of this part? > 3)Security part, section 9.2, how does the content integrity check = related to the tracker protocol should be better explained. > =20 > BR > Yunfei > =20 > zhangyunfei > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > =20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_E61F20BF-625B-4382-A81F-DF892D622168 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi = Lingli,

In fact, that was the basic idea, having the = hashprints of content at the MPD, not requiring involvement of the = tracker protocol.
A few words in security sections, as well as = in sections 1.2.3 = "Content Information Metadata" and 1.2.4 "Authentication, = Confidentiality, Integrity", would make this clearer.

Regards,

Rui = Cruz
<= font class=3D"Apple-style-span" = color=3D"#1555cb">
IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= div>ppsp mailing = list

On 05/11/2012, at 17:41, =B5=CB=C1=E9=C0=F2/Lingli Deng = <denglingli@chinamobile.com&= gt; wrote:

Hi = Rui,
 
MPD seems fine to me. Shall we = add a few words in the security section to clarify that the integrity = problem can be solved by including the hashprints of the content (be it = chunk-level or content-level) into  content information metadata. = For instance, as in MPD format. However, this can also be done through = maybe a web portal without tracker=A1=AFs = involvement.
 
What do you = think?
 
BR
 
=B7=A2=BC=FE=C8=CB: Rui Cruz = [mailto:rui.cruz@ieee-pt.org] =B4=FA=B1=ED Rui Cruz
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C25=C8=D5 8:24
=CA=D5=BC=FE= =C8=CB: =B5=CB=C1=E9=C0=F2/Lingli Deng
=B3=AD=CB=CD: Rui Cruz; 'zhangyunfei'; = 'Yingjie Gu(yingjie)'; 'ppsp'

=D6=F7=CC=E2: Re: [ppsp] ***SPAM*** 8.258 = (5) =B4=F0=B8=B4: =B4=F0=B8=B4: tracker protocol = review
 
Hi Yunfei and Lingli,
 
In section 1.2.3 "Content Information = Metadata" and 1.2.4 "Authentication, Confidentiality, Integrity", = although informative in nature, the aspect on content integrity is = somewhat raised, but not described. However, stating in the draft that = "content information metadata used in PPSP may align with MPD = formats, such as ISO/IEC 23009-1" means that content protection and = integrity verification schemes can be distributed by including root = fingerprints for each each video and audio groups described = in the MPD of the content.
 
In Appendix B. Media Presentation = Description (MPD) of draft-gu-ppsp-tracker-protocol-07, that = situation was fairly described with examples, but that section was not = transferred to the Base-Protocol draft, as suggested during = discussions.
 
In my opinion, I hardly see the distribution of the = fingerprints as a role of the tracker protocol as these schemes are = related to the content, but I would strongly support not just = channel-oriented security in the communication between peers and tracker = but also authentication and authorization mechanisms for the = peers.
 
Rui Cruz
 
IST/INESC-ID/INOV - = Lisbon, Portugal
ppsp mailing = list


All right. I will = discuss it with Yingjie and Rui today. See what to do about = it.
=B7=A2=BC=FE=C8=CB: zhangyunfei [mailto:zhangyunfei@chinamobile.com] 
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C25=C8=D5 0:40
=CA=D5=BC=FE=C8=CB: '=B5=CB=C1=E9=C0=F2'; Yingjie = Gu(yingjie); 'Rui Cruz'
=B3=AD=CB=CD: ppsp
=D6=F7=CC=E2: =BB=D8=B8=B4: =B4=F0=B8=B4: [ppsp] tracker protocol review 
Yes, Lingli. I mean it would be good = to write explicitly to say how to handle this in tracker = protocol.
 
BRYunfei
zhangyunfei 
=B7=A2=BC=FE=C8=CB=A3=BA =B5=CB=C1=E9=C0=F2/Lingli = Deng
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-11-05 12:11  'Yingjie = Gu\(yingjie\)'; 'Rui = Cruz'
=B3=AD=CB=CD=A3=BA 'ppsp' =B4=F0=B8=B4: [ppsp] tracker protocol review

As for your comment = asking for clarification for content integrity=A1=AFs relation to = tracker protocol, I would like to explain that as pointed out at the end = of Section 9.2,  content pollutioncan be detected by = incorporating integrity verification schemes for published shared = contents.  As content chunks are transferred independently and = concurrently, a correspondent chunk-level integrity verification MUST be = used, checked with signed fingerprints received from authentic = origin.

In = other words, these fingerprints MUST be signed by the authentic origin = of the content, and MUST be distributed in a trustworthy manner against = manipulation and forgery.
It would be reasonable to expect such distribution = be handled by the tracker protocol in a security-enhanced = sense.
____________________________= ___________________
ppsp mailing list
ppsp@ietf.org
, "arno@cs.vu.nl" References: <2012110511283736034341@chinamobile.com>, <002001cdbb0b$9e8ff000$dbafd000$@com> <201211051340060015086@chinamobile.com> <004f01cdbb51$a8afc8d0$fa0f5a70$@com> <0D8207BB-EA12-4ECC-84A8-FDE9611AF6D4@ieee.org>, <007501cdbb7c$c07feb40$417fc1c0$@com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012110609532773548615@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-06 09:53:33, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-06 09:53:34, Serialize complete at 2012-11-06 09:53:34 Content-Type: multipart/alternative; boundary="----=_001_NextPart433483730410_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19344.000 X-TM-AS-Result: No--36.344-7.0-31-10 X-imss-scan-details: No--36.344-7.0-31-10;No--36.344-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: ppsp Subject: [ppsp] =?gb2312?b?u9i4tDogtPC4tDogICoqKlNQQU0qKiogOC4yNTggKDUp?= =?gb2312?b?ILTwuLQ6ILTwuLQ6ICB0cmFja2VyIHByb3RvY29sIHJldmlldw==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 01:53:40 -0000 This is a multi-part message in MIME format. ------=_001_NextPart433483730410_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgTGluZ2xpLA0KICAgVG8gdGhlIGJlc3Qgb2YgbXkgdW5kZXJzdGFuZGluZywgUFBTUCBhc3N1 bWVzIGEgdHJ1c3RmdWwgY29udGVudCBwdWJsaXNoZXIgYW5kIHNob3VsZCBpZGVudGlmaWVzIG9u bHkgdGhlIG1hbGljaW91cyBQRUVScy4gSW4gb3RoZXIgd29yZHMsIFBQU1AgaXMgbm90IGEgY29t cGxldGUgc3lzdGVtIHRvIHNhdGlzZnkgdGhlIHN1ZXIgZXhwZXJpZW5jZSBpbiBwMnAgc3RyZWFt aW5nLiBSYXRoZXIgaXQganVzdCBhZGRyZXNzZXMgaG93IHRvIGRvIHRoZSBjb21tdW5pY2F0aW9u cyBhbW9uZyBwZWVycyBhbmQgdHJhY2tlcnMgYW5kIGluIHRoZSBwcm9jZXNzIGF2b2lkaW5nIG1h bGljaW91cyBwZWVycyB0byBkbyB0aGUgYXR0YWNrL3BvbGx1dGlvbnMuIFRoZSBpc3N1ZSB0byBl bnN1cmUgdGhlIGNvbnRlbnQgcHVibGlzaGVyIHRydXN0ZnVsIGlzIGEgbmVjZXNzYXJ5IHByb2Js ZW0gdG8gY29uc2lkZXIgd2hlbiBydW5uaW5nIGEgcHJhY3RpY2FsIHAycCBzdHJlYW1pbmcgc3lz dGVtIGVzcC4gd2hlbiBVR0MgY29udGVudHMgYXJlIGludm9sdmVkLiBXZSB3ZWxjb21lIGNvbnRy aWJ1dGlvbnMgaW4gQkNQIGRyYWZ0cyBvbiB0aGlzIGlzc3VlLiANCg0KQlINCnl1bmZlaQ0KDQoN Cg0KDQp6aGFuZ3l1bmZlaQ0KDQq3orz+yMujuiC1y8HpwPIvTGluZ2xpIERlbmcNCreiy83Ksbzk o7ogMjAxMi0xMS0wNiAwMTo0MQ0KytW8/sjLo7ogJ1J1aSBDcnV6JzsgYXJub0Bjcy52dS5ubA0K s63LzaO6ICd6aGFuZ3l1bmZlaSc7ICdZaW5namllIEd1XCh5aW5namllXCknOyAncHBzcCcNCtb3 zOKjuiC08Li0OiBbcHBzcF0gKioqU1BBTSoqKiA4LjI1OCAoNSkgtPC4tDogtPC4tDogdHJhY2tl ciBwcm90b2NvbCByZXZpZXcNCkhpIGFsbCwNCiANCkFzIEFybm8gcHJlc2VudGVkIHRoZSBzZWN1 cml0eSBwcm9wb3NhbHMgaW4gcGVlciBwcm90b2NvbCwgYW5kIHN0YXRlZCB0aGF0IHRoZXkgbWVl dCB0aGUgc2VjdXJpdHkgcGFydCBpbiB0aGUgcmVxdWlyZW1lbnQgZG9jdW1lbnQsIEkgZmVsdCBh IGNvbmNlcm4gd2l0aCB0aGUgc3RhdHVzIGluIFBQU1Agc2NvcGUgaW4gdGVybXMgb2Ygc2VjdXJp dHkgaXNzdWVzLg0KU2luY2UgdGhlIGNvbnRlbnQgcHVibGlzaGluZyBpcyBub3cgb3V0IG9mIHNj b3BlIG9mIHRoZSBkaXNjdXNzaW9uLCB0aGUgdmVyeSByb290IG9mIHRydXN0IGZvciB0aGUgY29u dGVudCBwcm92aWRlZCBieSBhIHBlZXJpbmcgcGFydHkgdG8gc2F0aXNmeSB0aGUgdXNlcqGvcyBl eHBlY3RhdGlvbiBpcyBtaXNzaW5nLiANCiANClRoaXMgY2Fubm90IGJlIGNvbXBlbnNhdGVkIGJ5 IHBlZXIgYXV0aGVudGljYXRpb24gb3IgYXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIGRpcmVjdGx5 LCBJIGFtIGFmcmFpZC4gDQogDQpCUg0KTGluZ2xpDQogDQq3orz+yMs6IFJ1aSBDcnV6IFttYWls dG86cnVpLmNydXpAaWVlZS1wdC5vcmddILT6se0gUnVpIENydXoNCreiy83KsbzkOiAyMDEyxOox MdTCNcjVIDg6MjQNCsrVvP7IyzogtcvB6cDyL0xpbmdsaSBEZW5nDQqzrcvNOiBSdWkgQ3J1ejsg J3poYW5neXVuZmVpJzsgJ1lpbmdqaWUgR3UoeWluZ2ppZSknOyAncHBzcCcNCtb3zOI6IFJlOiBb cHBzcF0gKioqU1BBTSoqKiA4LjI1OCAoNSkgtPC4tDogtPC4tDogdHJhY2tlciBwcm90b2NvbCBy ZXZpZXcNCiANCkhpIFl1bmZlaSBhbmQgTGluZ2xpLA0KIA0KSW4gc2VjdGlvbiAxLjIuMyAiQ29u dGVudCBJbmZvcm1hdGlvbiBNZXRhZGF0YSIgYW5kIDEuMi40ICJBdXRoZW50aWNhdGlvbiwgQ29u ZmlkZW50aWFsaXR5LCBJbnRlZ3JpdHkiLCBhbHRob3VnaCBpbmZvcm1hdGl2ZSBpbiBuYXR1cmUs IHRoZSBhc3BlY3Qgb24gY29udGVudCBpbnRlZ3JpdHkgaXMgc29tZXdoYXQgcmFpc2VkLCBidXQg bm90IGRlc2NyaWJlZC4gSG93ZXZlciwgc3RhdGluZyBpbiB0aGUgZHJhZnQgdGhhdCAiY29udGVu dCBpbmZvcm1hdGlvbiBtZXRhZGF0YSB1c2VkIGluIFBQU1AgbWF5IGFsaWduIHdpdGggTVBEIGZv cm1hdHMsIHN1Y2ggYXMgSVNPL0lFQyAyMzAwOS0xIiBtZWFucyB0aGF0IGNvbnRlbnQgcHJvdGVj dGlvbiBhbmQgaW50ZWdyaXR5IHZlcmlmaWNhdGlvbiBzY2hlbWVzIGNhbiBiZSBkaXN0cmlidXRl ZCBieSBpbmNsdWRpbmcgcm9vdCBmaW5nZXJwcmludHMgZm9yIGVhY2ggZWFjaCB2aWRlbyBhbmQg YXVkaW8gZ3JvdXBzIGRlc2NyaWJlZCBpbiB0aGUgTVBEIG9mIHRoZSBjb250ZW50Lg0KIA0KSW4g QXBwZW5kaXggQi4gTWVkaWEgUHJlc2VudGF0aW9uIERlc2NyaXB0aW9uIChNUEQpIG9mIGRyYWZ0 LWd1LXBwc3AtdHJhY2tlci1wcm90b2NvbC0wNywgdGhhdCBzaXR1YXRpb24gd2FzIGZhaXJseSBk ZXNjcmliZWQgd2l0aCBleGFtcGxlcywgYnV0IHRoYXQgc2VjdGlvbiB3YXMgbm90IHRyYW5zZmVy cmVkIHRvIHRoZSBCYXNlLVByb3RvY29sIGRyYWZ0LCBhcyBzdWdnZXN0ZWQgZHVyaW5nIGRpc2N1 c3Npb25zLg0KIA0KSW4gbXkgb3BpbmlvbiwgSSBoYXJkbHkgc2VlIHRoZSBkaXN0cmlidXRpb24g b2YgdGhlIGZpbmdlcnByaW50cyBhcyBhIHJvbGUgb2YgdGhlIHRyYWNrZXIgcHJvdG9jb2wgYXMg dGhlc2Ugc2NoZW1lcyBhcmUgcmVsYXRlZCB0byB0aGUgY29udGVudCwgYnV0IEkgd291bGQgc3Ry b25nbHkgc3VwcG9ydCBub3QganVzdCBjaGFubmVsLW9yaWVudGVkIHNlY3VyaXR5IGluIHRoZSBj b21tdW5pY2F0aW9uIGJldHdlZW4gcGVlcnMgYW5kIHRyYWNrZXIgYnV0IGFsc28gYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtcyBmb3IgdGhlIHBlZXJzLg0KDQpSZWdh cmRzLA0KIA0KUnVpIENydXoNCnJ1aS5jcnV6QGllZWUub3JnDQogDQpJU1QvSU5FU0MtSUQvSU5P ViAtIExpc2JvbiwgUG9ydHVnYWwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA0KIA0KT24gMDUvMTEvMjAxMiwgYXQgMTI6MzIs ILXLwenA8i9MaW5nbGkgRGVuZyA8ZGVuZ2xpbmdsaUBjaGluYW1vYmlsZS5jb20+IHdyb3RlOg0K DQoNCg0KQWxsIHJpZ2h0LiBJIHdpbGwgZGlzY3VzcyBpdCB3aXRoIFlpbmdqaWUgYW5kIFJ1aSB0 b2RheS4gU2VlIHdoYXQgdG8gZG8gYWJvdXQgaXQuDQpMaW5nbGkNCreivP7Iyzogemhhbmd5dW5m ZWkgW21haWx0bzp6aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb21dIA0Kt6LLzcqxvOQ6IDIwMTLE 6jEx1MI1yNUgMDo0MA0KytW8/sjLOiAntcvB6cDyJzsgWWluZ2ppZSBHdSh5aW5namllKTsgJ1J1 aSBDcnV6Jw0Ks63LzTogcHBzcA0K1vfM4jogu9i4tDogtPC4tDogW3Bwc3BdIHRyYWNrZXIgcHJv dG9jb2wgcmV2aWV3DQogDQpZZXMsIExpbmdsaS4gSSBtZWFuIGl0IHdvdWxkIGJlIGdvb2QgdG8g d3JpdGUgZXhwbGljaXRseSB0byBzYXkgaG93IHRvIGhhbmRsZSB0aGlzIGluIHRyYWNrZXIgcHJv dG9jb2wuDQogDQpCUg0KWXVuZmVpDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KIA0Kt6K8/sjLo7ogtcvB 6cDyL0xpbmdsaSBEZW5nDQq3osvNyrG85KO6IDIwMTItMTEtMDUgMTI6MTENCsrVvP7Iy6O6ICd6 aGFuZ3l1bmZlaSc7ICdZaW5namllIEd1XCh5aW5namllXCknOyAnUnVpIENydXonDQqzrcvNo7og J3Bwc3AnDQrW98zio7ogtPC4tDogW3Bwc3BdIHRyYWNrZXIgcHJvdG9jb2wgcmV2aWV3DQpZdW5m ZWksDQpBcyBmb3IgeW91ciBjb21tZW50IGFza2luZyBmb3IgY2xhcmlmaWNhdGlvbiBmb3IgY29u dGVudCBpbnRlZ3JpdHmhr3MgcmVsYXRpb24gdG8gdHJhY2tlciBwcm90b2NvbCwgSSB3b3VsZCBs aWtlIHRvIGV4cGxhaW4gdGhhdCBhcyBwb2ludGVkIG91dCBhdCB0aGUgZW5kIG9mIFNlY3Rpb24g OS4yLCAgY29udGVudCBwb2xsdXRpb24NCmNhbiBiZSBkZXRlY3RlZCBieSBpbmNvcnBvcmF0aW5n IGludGVncml0eSB2ZXJpZmljYXRpb24gc2NoZW1lcyBmb3IgcHVibGlzaGVkIHNoYXJlZCBjb250 ZW50cy4gIEFzIGNvbnRlbnQgY2h1bmtzIGFyZSB0cmFuc2ZlcnJlZCBpbmRlcGVuZGVudGx5IGFu ZCBjb25jdXJyZW50bHksIGEgY29ycmVzcG9uZGVudCBjaHVuay1sZXZlbCBpbnRlZ3JpdHkgdmVy aWZpY2F0aW9uIE1VU1QgYmUgdXNlZCwgY2hlY2tlZCB3aXRoIHNpZ25lZCBmaW5nZXJwcmludHMg cmVjZWl2ZWQgZnJvbSBhdXRoZW50aWMgb3JpZ2luLg0KSW4gb3RoZXIgd29yZHMsIHRoZXNlIGZp bmdlcnByaW50cyBNVVNUIGJlIHNpZ25lZCBieSB0aGUgYXV0aGVudGljIG9yaWdpbiBvZiB0aGUg Y29udGVudCwgYW5kIE1VU1QgYmUgZGlzdHJpYnV0ZWQgaW4gYSB0cnVzdHdvcnRoeSBtYW5uZXIg YWdhaW5zdCBtYW5pcHVsYXRpb24gYW5kIGZvcmdlcnkuDQpJdCB3b3VsZCBiZSByZWFzb25hYmxl IHRvIGV4cGVjdCBzdWNoIGRpc3RyaWJ1dGlvbiBiZSBoYW5kbGVkIGJ5IHRoZSB0cmFja2VyIHBy b3RvY29sIGluIGEgc2VjdXJpdHktZW5oYW5jZWQgc2Vuc2UuDQpCUg0KTGluZ2xpDQq3orz+yMs6 IHBwc3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBwc3AtYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SB6aGFuZ3l1bmZlaQ0Kt6LLzcqxvOQ6IDIwMTLE6jEx1MI0yNUgMjI6MjkNCsrVvP7IyzogWWlu Z2ppZSBHdSh5aW5namllKTsgJ1J1aSBDcnV6Jw0Ks63LzTogcHBzcA0K1vfM4jogW3Bwc3BdIHRy YWNrZXIgcHJvdG9jb2wgcmV2aWV3DQogDQpIaSBSdWkgYW5kIFlpbmdqaWUgKFNwZWFraW5nIGlu ZGl2aWR1YWxseSkgLA0KICAgIEkgaGF2ZSByZWFkIHRoZSB1cGRhdGVkIHRyYWNrZXIgcHJvdG9j b2wgZHJhZnQgYW5kIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50czoNCjEpIEVuY29kaW5nIGlz c3VlOiBJdCdzIGdvb2QgdG8gbWVudGlvbiB0aGF0IFBQU1AtVFAgaXMgaW50ZW5kZWQgdG8gc3Vw cG9ydCBiaW5hcnkgZW5jb2RpbmcgaW4gc2VjdGlvbiA0LiBIb3dldmVyIGluIHNlY3Rpb24gNSwg NyBhbmQgOCwgaHR0cCtYTUwgaXMgc3RpbGwgaW4gdGhlIG1haW4gcGFnZS4gSXMgdGhpcyBqdXN0 IGZvciBleGFtcGxlPyBPciBhIGdlbmVyYWwgc2VtYW50aWNzIGRlc3BlcmF0aW9uIGlzIGVub3Vn aD8gSSB0aGluayBtdWNoIG9mIHNlY3Rpb24gNy4xIGluIGN1cnJlbnQgdmVyc2lvbiBjYW4gYmUg cGxhY2VkIGluIEFwcGVuZGl4IEEuIEFyZSB5b3UgaW50ZW5kaW5nIHRvIHVzZSBFWEkgZm9yIHRo ZSBiaW5hcnkgZW5jb2RpbmcgYW5kIGRvIHlvdSBzdGlsbCBuZWVkIGh0dHAgZm9yIHRoZSB1bmRl cmx5aW5nIHRyYW5zcG9ydD8NCjIpICBDaGVjayB0aGUgc2VjdGlvbiAxMCBmb3IgdGhlIFhNTCBk ZXNjcmlwdGlvbnMuIERvIHdlIG5lZWQgdGhlIHVwZGF0ZSBvZiB0aGlzIHBhcnQ/DQozKVNlY3Vy aXR5IHBhcnQsIHNlY3Rpb24gOS4yLCBob3cgZG9lcyB0aGUgY29udGVudCBpbnRlZ3JpdHkgY2hl Y2sgcmVsYXRlZCB0byB0aGUgdHJhY2tlciBwcm90b2NvbCBzaG91bGQgYmUgYmV0dGVyIGV4cGxh aW5lZC4NCiANCkJSDQpZdW5mZWkNCiANCg0KDQoNCnpoYW5neXVuZmVpDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBw c3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA0K IA== ------=_001_NextPart433483730410_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Lingli,
   To the best of my understanding, PPSP assumes a tru= stful=20 content publisher and should identifies only the malicious PEERs. In other= =20 words, PPSP is not a complete system to satisfy the suer experience in p2p= =20 streaming. Rather it just addresses how to do the communications=20 among peers and trackers and in the process avoiding malicious peers = to do=20 the attack/pollutions. The issue to ensure the content publisher trus= tful=20 is a necessary problem to consider when running a practical p2p strea= ming=20 system esp. when UGC contents are involved. We welcome contributions in BC= P=20 drafts on this issue.
 
BR
yunfei
 
zhangyunfei
 
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-11-06 01:41
=CA=D5=BC=FE=C8=CB=A3=BA 'Rui Cruz'; arno@cs.vu.nl
=B3=AD=CB=CD=A3=BA 'zhangyunfei'; 'Yingjie Gu\(yingjie\)'; 'ppsp'
=D6=F7=CC=E2=A3=BA =B4=F0=B8=B4: [ppsp] ***SPAM*** 8.258 = (5) =B4=F0=B8=B4: =B4=F0=B8=B4: tracker protocol=20 review

Hi all,

 

As Arno presented the security proposals in peer protocol, an= d stated=20 that they meet the security part in the requirement document, I felt a con= cern=20 with the status in PPSP scope in terms of security issues.

Since the content publishing is now out of scope of the discu= ssion,=20 the very root of trust for the content provided by a peering party to sati= sfy=20 the user=A1=AFs expectation is missing.

 

This cannot be compensated by peer authentication or authoriz= ation=20 mechanisms directly, I am afraid.

 

BR

Lingli

 

=B7=A2=BC=FE=C8=CB= : Rui Cruz=20 [mailto:rui.cruz@ieee-pt.org] = =B4=FA=B1=ED=20 Rui Cruz
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C25=C8=D5 8:24
=CA=D5=BC= =FE=C8=CB: =B5=CB=C1=E9=C0=F2/Lingli=20 Deng
=B3=AD=CB=CD: Rui Cruz;=20 'zhangyunfei'; 'Yingjie Gu(yingjie)'; 'ppsp'
=D6=F7=CC=E2: Re: [ppsp] ***SPAM*** 8.258 (= 5)=20 =B4=F0=B8=B4: =B4=F0=B8=B4: tracker protocol=20 review

 

Hi Yunfei and Lingli,

 

In section 1.2.3 "Content Informat= ion=20 Metadata" and 1.2.4 "Authentication, Confidentiality, Integrity", although= =20 informative in nature, the aspect on content integrity is somewhat raised,= but=20 not described. However, stating in the draft that "content=20 information metadata used in PPSP may align with MPD formats, such as= =20 ISO/IEC 23009-1" means that content protection and integrity verifica= tion=20 schemes can be distributed by including root fingerprints for=20 each each video and audio groups described in the MPD of the=20 content.

 

In Appendix B. Media Presenta= tion=20 Description (MPD) of draft-gu-ppsp-tracker-protocol-07, that situatio= n was=20 fairly described with examples, but that section was not transferred to th= e=20 Base-Protocol draft, as suggested during=20 discussions.

 

In my opinion, I hardly see t= he=20 distribution of the fingerprints as a role of the tracker protocol as= these=20 schemes are related to the content, but I would strongly support not just=20 channel-oriented security in the communication between peers and tracker b= ut=20 also authentication and authorization mechanisms for the=20 peers.


Regards,

<= /DIV>

 

Rui Cruz<= /SPAN>

rui.cruz@ieee.org

 

IST/INESC= -ID/INOV -=20 Lisbon, Portugal

__________________________________________

ppsp mail= ing=20 list

ppsp@ietf.org

https://www.ietf.org/m= ailman/listinfo/ppsp

 

On 05/11/2012, at 12:32, = =B5=CB=C1=E9=C0=F2/Lingli Deng <denglingli@chinamobile.com&= gt;=20 wrote:



All right. I will discuss it with Yingjie and Rui today. See = what to=20 do about it.

Lingli

=B7=A2=BC=FE=C8=CB= : zhangyunfei [mailto:zhangyunfei@chinamobile.com] 
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C25=C8=D5 0:40
=CA=D5=BC=FE=C8=CB: '=B5=CB=C1=E9=C0=F2'; Yingjie Gu(yi= ngjie); 'Rui=20 Cruz'
=B3=AD=CB=CD: ppsp
=D6=F7=CC=E2:=  =BB= =D8=B8=B4: =B4= =F0=B8=B4: [ppsp] tracker protocol review

 

BR

Yunfei

zhangyunfei

 

=B7=A2=BC=FE=C8=CB=A3=BA =B5=CB=C1=E9=C0=F2= /Lingli=20 Deng

=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-11-05 12:11

=CA=D5=BC=FE=C8=CB=A3=BA 'zhangyunfei'; 'Yingji= e=20 Gu\(yingjie\)'; 'Rui=20 Cruz'

=B3=AD=CB=CD=A3=BA 'ppsp'

=D6=F7=CC=E2=A3=BA =B4=F0=B8=B4: [ppsp]=20 tracker protocol review

Yunfei,

As for your comment asking for clarification for content inte= grity=A1=AFs=20 relation to tracker protocol, I would like to explain that as pointed out = at the=20 end of Section 9.2,  content pollution<= /SPAN>

can be detected by incor= porating=20 integrity verification schemes for published shared contents.  As con= tent=20 chunks are transferred independently and concurrently, a correspondent=20 chunk-level integrity verification MUST be used, checked with signed=20 fingerprints received from authentic origin.

In other words, these fingerprints MUST be signed by the auth= entic=20 origin of the content, and MUST be distributed in a trustworthy manner aga= inst=20 manipulation and forgery.

It would be reasonable to expect such distribution be handled= by the=20 tracker protocol in a security-enhanced sense.

BRLingli

=B7=A2=BC=FE=C8=CB= : ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED=  =B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C24=C8=D5 22:29
=CA= =D5=BC=FE=C8=CB: Yingjie Gu(yingjie); '= Rui=20 Cruz'
=B3=AD=CB=CD: ppsp
=D6=F7=CC=E2:=  [ppsp] tracker protocol review

Hi=20 Rui and Yingjie (Speaking individually) ,

    I have read the updated tracker protocol d= raft and=20 have the following comments:

1)=20 Encoding issue: It's good to mention that PPSP-TP is intended to support b= inary=20 encoding in section 4. However in section 5, 7 and 8, http+XML is still in= the=20 main page. Is this just for example? Or a general semantics desperati= on is=20 enough? I think much of section 7.1 in current version can be pl= aced=20 in Appendix A. Are you intending to use EXI for the binary encoding a= nd do=20 you still need http for the underlying transport?

2)  Check the section 10 for the XML descriptions. = Do we=20 need the update of this part?

3)Security part, section 9.2, how does the content integrity = check=20 related to the tracker protocol should be better explained.

 

BRYunfei

 

zhangyunfei

_______________________________________________
ppsp maili= ng=20 list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp<= /A>

 

------=_001_NextPart433483730410_=------ From a.bakker@vu.nl Mon Nov 5 23:17:35 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04021F8687 for ; Mon, 5 Nov 2012 23:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zdd6BQ3muXk3 for ; Mon, 5 Nov 2012 23:17:34 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 59EB621F8685 for ; Mon, 5 Nov 2012 23:17:33 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 6 Nov 2012 08:17:31 +0100 Received: from [109.37.48.207] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 6 Nov 2012 08:17:31 +0100 Message-ID: <5098B998.5080704@cs.vu.nl> Date: Tue, 6 Nov 2012 08:17:44 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= References: <005f01cdbb7c$bcfe8cb0$36fba610$@com> In-Reply-To: <005f01cdbb7c$bcfe8cb0$36fba610$@com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [130.37.238.20] Cc: 'ppsp' Subject: Re: [ppsp] questions about merkle hash tree mechanism for integrity protection of content between peers X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 07:17:35 -0000 On 05/11/2012 18:41, 邓灵莉/Lingli Deng wrote: > Hi Arno, > > Thank you for the impressive speech and demos this morning. > Hi thanks, but that was my boss, Johan. I was virtually present in the meeting. > I have a few questions about the security proposals in current peer > protocol draft: > > 1)Swarm ID, be it the roothash of a merkle-tree in video-on-demand cases > or a public key of the initiator in live cases, is not straightforwardly > inferred to a joining peer, which means there has to be some way to > securely and uniquely derived from the common knowledge of a joining > peer (for instance, a few vague key words to search what the user > wants). I understand that, the pollution issue concerns not only serving > as you asked, but also serving as you expected. What do you do in your > implementation? Or the user just know what to check in the first place? > I'm not sure I get what you mean. The swarm ID is the identifier of the swarm, so if a peer wants to join a swarm it must know the swarm ID. As the PPSPP swarm IDs are self-certifying, a peer is always guaranteed to get what he asked for. The assumption is that the peer gets the swarm ID from a trusted source, e.g. a webportal that says "This BBC Top Gear episode that you want to watch has roothash X". > 2)For ECS proposal, I doubt the one-to-one encryption negotiation is > scalable for a peer serving more than one peers at a time. Since you are > not targeting DRM requirements, revocable group keys may suite your > needs, while the data can be encrypted once and for all given the group > membership remains unchanged. > Dusan? CU, Arno From a.bakker@vu.nl Tue Nov 6 04:42:55 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A483E21F8846 for ; Tue, 6 Nov 2012 04:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXeG5QoiOudG for ; Tue, 6 Nov 2012 04:42:55 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id DC5EF21F891A for ; Tue, 6 Nov 2012 04:42:54 -0800 (PST) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 6 Nov 2012 13:42:49 +0100 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 6 Nov 2012 13:42:49 +0100 Message-ID: <509905D6.2050901@cs.vu.nl> Date: Tue, 6 Nov 2012 13:43:02 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: zhangyunfei References: <20121022054506.24206.72390.idtracker@ietfa.amsl.com> <201210221507482101757@chinamobile.com>, <5084F1F7.4020002@cs.vu.nl> <2012110216294380861230@chinamobile.com> In-Reply-To: <2012110216294380861230@chinamobile.com> Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp Subject: Re: [ppsp] comments on draft-ietf-ppsp-peer-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 12:42:55 -0000 Hi Yunfei et al. On 02/11/2012 09:29, zhangyunfei wrote: > Hi Arno (Speaking individually), > I've read the draft and the following is my comments: > 1) The effect of "choke/unchoke" is not very clear in the draft. Will > this increase the transfer efficiency? The CHOKE/UNCHOKE is a mechanism that deployments/policies on top of the base protocol may choose to use. It will make an implementation simpler. Imagine you are connected to a good peer (i.e., one that sends DATA back). If the good peer sends you a CHOKE, you immediately know that he is not going to respond anymore and you should look for a different peer to download from. No need to retry REQUESTs. > 3) Is it better to combine section 5,6, 7 into security consideration > section as all these 3 sections involve identifying the data is from the > reliable source/peers, which is related to security more or less. What's > more, it makes the draft better structured. I personally see two issues. First, it means content integrity isn't discussed before we present the protocol options and UDP encapsulation. Second, the Security Considerations section will become roughly 20 pages out of a 47 total which sounds a bit unbalanced to me. But you have more experience in this than I, so please let me know what is common. CU, Arno From dusan.gabrijelcic@gmail.com Wed Nov 7 09:44:30 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4DE21F8B4E for ; Wed, 7 Nov 2012 09:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGDoyCg8RRQd for ; Wed, 7 Nov 2012 09:44:29 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 341C821F8957 for ; Wed, 7 Nov 2012 09:44:16 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1433293pbb.31 for ; Wed, 07 Nov 2012 09:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=gWNG45BL0SZrU9bOz5vaznVsvqMKA81uf/ybeCmN+kg=; b=lZcK3HRv6XolHCpzjj/xmMsI8bfbiZ4kc6uXfG5sHafSvQrEpHdY+VLyCyXXsH6Edd YHrVZHBpWpR1fCgKPHcmUo1OgIZ4fLjvcZqjKHmSkK7Y1VK4yF2VC7PG/yoW+jMKHwrU h0RW+dQ9qN+te/Git6/lq3eStib1uT3t5mC+mIKXNaQ0W0Rmwu0oDIVJrSjYH+6GH5jn yTbZ4Gtlxf8tia+7X9+gqyc93vqcxj6+5ldPeJNQ31wkNUzPKKyl+3KbdNCQ99gg5Ld/ /Wtqf3wv6IaKRBj5waMXqJ2dTyrtmIgfnHxq8I44XF6jRF+fJ9r1D/lRXMpiV1lmVLjQ RqEw== Received: by 10.66.77.201 with SMTP id u9mr14541023paw.6.1352310256024; Wed, 07 Nov 2012 09:44:16 -0800 (PST) MIME-Version: 1.0 Sender: dusan.gabrijelcic@gmail.com Received: by 10.68.137.37 with HTTP; Wed, 7 Nov 2012 09:43:55 -0800 (PST) In-Reply-To: <5098B998.5080704@cs.vu.nl> References: <005f01cdbb7c$bcfe8cb0$36fba610$@com> <5098B998.5080704@cs.vu.nl> From: Dusan Gabrijelcic Date: Wed, 7 Nov 2012 18:43:55 +0100 X-Google-Sender-Auth: SwHb72gISxTW5IGHuCoDg9peHCI Message-ID: To: arno@cs.vu.nl Content-Type: multipart/alternative; boundary=f46d042f948a6fbc7604cdeb445b Cc: ppsp Subject: Re: [ppsp] questions about merkle hash tree mechanism for integrity protection of content between peers X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:44:30 -0000 --f46d042f948a6fbc7604cdeb445b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Deng, On Tue, Nov 6, 2012 at 8:17 AM, Arno Bakker wrote: > On 05/11/2012 18:41, =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng wrote: > >> Hi Arno, >> >> Thank you for the impressive speech and demos this morning. >> >> > 2)For ECS proposal, I doubt the one-to-one encryption negotiation is >> scalable for a peer serving more than one peers at a time. Since you are >> not targeting DRM requirements, revocable group keys may suite your >> needs, while the data can be encrypted once and for all given the group >> membership remains unchanged. >> >> > Dusan? > I hope I had understood your questions correctly. According to our tests and evaluations the ECS cryptographic handshake using plain digital signature (one-to-one encryption negotiation) should scale reasonably well for expected peers load (number of peers in swam(s), in connection, regarding churn and taking in account normal peer settings). Ordinary host should easily handle few hundreds of ECS handshakes per second (measured through OpenSSL) which should be sufficient even for large number of concurrently open connections and, lets say, 1% churn per second. The group key and encrypting the content (not exchanged data in connection since it is not always the same) once for all would really decrease the load on peer but it is regarded as highly insecure, except in very restricted settings. As you mention static group membership, the ECS protocol doesn't assume any limitations on group membership; peers can join and leave at will (but according the credentials they posses). And, the protocol provides in application data communication protection other security services besides confidentially (encryption) as well. Nowadays they are standard in most network protocols, for example in IPSec or TLS/DTLS. Things can get harsher on heavily loaded ingest points, but here a swarm initiator has other mechanisms that can be used to mitigate the load, like auxiliary peers, cryptographic accelerators (quite common in VPN/SSL settings), cloud seeding, etc. Hope this answers your questions. Kind regards, Dusan. --=20 ~~~~~~~~~~ Dusan Gabrijelcic e-mail: dusan@e5.ijs.si --f46d042f948a6fbc7604cdeb445b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Deng,

On Tue, Nov 6, 2012 at 8:17 AM, = Arno Bakker <arno@cs.vu.nl> wrote:
On 05/11/2012 18:41, =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng wrote:
Hi Arno,

Thank you for the impressive speech and demos this morning.


2)For ECS proposal, I doubt the one-to-one encryption negotiation is
scalable for a peer serving more than one peers at a time. Since you are not targeting DRM requirements, revocable group keys may suite your
needs, while the data can be encrypted once and for all given the group
membership remains unchanged.


Dusan?

I hope I had understood your questions corr= ectly. According to our tests and evaluations the ECS cryptographic handsha= ke using plain digital signature (one-to-one encryption negotiation) should= scale reasonably well for expected peers load (number of peers in swam(s),= in connection, regarding churn and taking in account normal peer settings)= . Ordinary host should easily handle few hundreds of ECS handshakes per sec= ond (measured through OpenSSL) which should be sufficient even for large nu= mber of concurrently open connections and, lets say, 1% churn per second.= =C2=A0

The group key and encrypting the content (not exchanged data in connect= ion since it is not always the same) once for all would really decrease the= load on peer but it is regarded as highly insecure, except in very restric= ted settings. As you mention static group membership, the ECS protocol does= n't assume any limitations on group membership; peers can join and leav= e at will (but according the credentials they posses). And, the protocol pr= ovides in application data communication protection other security services= besides confidentially (encryption) as well. Nowadays they are standard in= most network protocols, for example in IPSec or TLS/DTLS.

Things can get harsher on heavily loaded ingest points, but here a swar= m initiator has other mechanisms that can be used to mitigate the load, lik= e auxiliary peers, cryptographic accelerators (quite common in VPN/SSL sett= ings), cloud seeding, etc.=C2=A0=C2=A0

Hope this answers your questions.

Kind regards, Dusan.
--
~~~~~~~~~~
Dusan Gabrijelcic
e-mail: dusan@e5.ijs.si
--f46d042f948a6fbc7604cdeb445b-- From zhangyunfei@chinamobile.com Thu Nov 8 22:07:09 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E1121F8A89 for ; Thu, 8 Nov 2012 22:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.817 X-Spam-Level: X-Spam-Status: No, score=-92.817 tagged_above=-999 required=5 tests=[AWL=-1.489, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxdt-TAc1ido for ; Thu, 8 Nov 2012 22:07:08 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4221F8A7E for ; Thu, 8 Nov 2012 22:07:06 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 1E5E8E4F5; Fri, 9 Nov 2012 14:06:58 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 116E4E46A; Fri, 9 Nov 2012 14:06:58 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012110914065554-13355 ; Fri, 9 Nov 2012 14:06:55 +0800 Date: Fri, 9 Nov 2012 14:06:47 +0800 From: zhangyunfei To: "arno@cs.vu.nl" References: <20121022054506.24206.72390.idtracker@ietfa.amsl.com> <201210221507482101757@chinamobile.com>, <5084F1F7.4020002@cs.vu.nl> <2012110216294380861230@chinamobile.com>, <509905D6.2050901@cs.vu.nl> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012110914064759431029@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-09 14:06:55, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-09 14:06:57, Serialize complete at 2012-11-09 14:06:57 Content-Type: multipart/alternative; boundary="----=_001_NextPart705472750025_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19350.004 X-TM-AS-Result: No--24.737-7.0-31-10 X-imss-scan-details: No--24.737-7.0-31-10;No--24.737-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: ppsp Subject: [ppsp] =?gb2312?b?u9i4tDogUmU6IGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYt?= =?gb2312?b?cHBzcC1wZWVyLXByb3RvY29sLTAzLnR4dA==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 06:07:09 -0000 This is a multi-part message in MIME format. ------=_001_NextPart705472750025_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgQXJubywNCiAgICBQbHMgc2VlIGlubGluZS4NCg0KQlINCnl1bmZlaQ0KDQoNCg0KDQp6aGFu Z3l1bmZlaQ0KDQpGcm9tOiBBcm5vIEJha2tlcg0KRGF0ZTogMjAxMi0xMS0wNiAyMDo0Mw0KVG86 IHpoYW5neXVuZmVpDQpDQzogcHBzcDsgc3RlZmFubyBwcmV2aWRpDQpTdWJqZWN0OiBSZTogY29t bWVudHMgb24gZHJhZnQtaWV0Zi1wcHNwLXBlZXItcHJvdG9jb2wtMDMudHh0DQpIaSBZdW5mZWkg ZXQgYWwuDQoNCk9uIDAyLzExLzIwMTIgMDk6MjksIHpoYW5neXVuZmVpIHdyb3RlOg0KPiBIaSBB cm5vIChTcGVha2luZyBpbmRpdmlkdWFsbHkpLA0KPiBJJ3ZlIHJlYWQgdGhlIGRyYWZ0IGFuZCB0 aGUgZm9sbG93aW5nIGlzIG15IGNvbW1lbnRzOg0KPiAxKSBUaGUgZWZmZWN0IG9mICJjaG9rZS91 bmNob2tlIiBpcyBub3QgdmVyeSBjbGVhciBpbiB0aGUgZHJhZnQuIFdpbGwNCj4gdGhpcyBpbmNy ZWFzZSB0aGUgdHJhbnNmZXIgZWZmaWNpZW5jeT8NCg0KVGhlIENIT0tFL1VOQ0hPS0UgaXMgYSBt ZWNoYW5pc20gdGhhdCBkZXBsb3ltZW50cy9wb2xpY2llcyBvbiB0b3Agb2YgdGhlIA0KYmFzZSBw cm90b2NvbCBtYXkgY2hvb3NlIHRvIHVzZS4gSXQgd2lsbCBtYWtlIGFuIGltcGxlbWVudGF0aW9u IHNpbXBsZXIuIA0KSW1hZ2luZSB5b3UgYXJlIGNvbm5lY3RlZCB0byBhIGdvb2QgcGVlciAoaS5l Liwgb25lIHRoYXQgc2VuZHMgREFUQSANCmJhY2spLiBJZiB0aGUgZ29vZCBwZWVyIHNlbmRzIHlv dSBhIENIT0tFLCB5b3UgaW1tZWRpYXRlbHkga25vdyB0aGF0IGhlIA0KaXMgbm90IGdvaW5nIHRv IHJlc3BvbmQgYW55bW9yZSBhbmQgeW91IHNob3VsZCBsb29rIGZvciBhIGRpZmZlcmVudCBwZWVy IA0KdG8gZG93bmxvYWQgZnJvbS4gTm8gbmVlZCB0byByZXRyeSBSRVFVRVNUcy4NCqG+WXVuZmVp ob9JIHVuZGVyc3RhbmQgdGhpcyBwb2ludC4gTXkgcXVlc3Rpb24gaXMgYmFzZWQgb24gdGhlIGZh Y3QgdGhhdCBwZWVycyBpbiBwMnAgc3RyZWFtaW5nIA0KaXMgb2YgbGVzcyBpbmNlbnRpdmUgdG8g YmUgZnJlZS1yaWRpbmcgdGhhbiBmaWxlIHNoYXJpbmcgcGVlcnMuIFNvIHRoZSBlZmZlY3Qgb2Yg Q0hPS0UvVU5DSE9LRSBpcyBub3QgDQpub3QgY2xlYXIuIA0KDQo+IDMpIElzIGl0IGJldHRlciB0 byBjb21iaW5lIHNlY3Rpb24gNSw2LCA3IGludG8gc2VjdXJpdHkgY29uc2lkZXJhdGlvbg0KPiBz ZWN0aW9uIGFzIGFsbCB0aGVzZSAzIHNlY3Rpb25zIGludm9sdmUgaWRlbnRpZnlpbmcgdGhlIGRh dGEgaXMgZnJvbSB0aGUNCj4gcmVsaWFibGUgc291cmNlL3BlZXJzLCB3aGljaCBpcyByZWxhdGVk IHRvIHNlY3VyaXR5IG1vcmUgb3IgbGVzcy4gV2hhdCdzDQo+IG1vcmUsIGl0IG1ha2VzIHRoZSBk cmFmdCBiZXR0ZXIgc3RydWN0dXJlZC4NCg0KSSBwZXJzb25hbGx5IHNlZSB0d28gaXNzdWVzLiBG aXJzdCwgaXQgbWVhbnMgY29udGVudCBpbnRlZ3JpdHkgaXNuJ3QgDQpkaXNjdXNzZWQgYmVmb3Jl IHdlIHByZXNlbnQgdGhlIHByb3RvY29sIG9wdGlvbnMgYW5kIFVEUCBlbmNhcHN1bGF0aW9uLiAN ClNlY29uZCwgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gd2lsbCBiZWNvbWUg cm91Z2hseSAyMCBwYWdlcyANCm91dCBvZiBhIDQ3IHRvdGFsIHdoaWNoIHNvdW5kcyBhIGJpdCB1 bmJhbGFuY2VkIHRvIG1lLiBCdXQgeW91IGhhdmUgbW9yZSANCmV4cGVyaWVuY2UgaW4gdGhpcyB0 aGFuIEksIHNvIHBsZWFzZSBsZXQgbWUga25vdyB3aGF0IGlzIGNvbW1vbi4NCltZdW5mZWldIEhv dyBhYm91dCBjb21iaW5lIHNlY3Rpb24gNS42LDcgaW50byBhIHNlY3Rpb24gYmVmb3JlIGN1cnJl bnRseSBzZWN0aW9uIDg/IFRvIG15IHVuZGVyc3RhbmRpbmcsDQogYWxsIHRoZSB0aHJlZSBzZWN0 aW9ucyB0YWxrIGFib3V0IHRoZSBzYW1lIHByb2JsZW0uIElzIHRoYXQgY29ycmVjdD8NCg0KQ1Us DQogICAgICBBcm5v ------=_001_NextPart705472750025_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Arno,
    Pls see inline.
 
BR
yunfei
 
zhangyunfei
 
From: Arno Bakker
Date: 2012-11-06 20:43
To: zhangyunfei
CC: ppsp; stefano previdi
Subject: Re: comments on=20 draft-ietf-ppsp-peer-protocol-03.txt
Hi Yunfei et al.
 
On 02/11/2012 09:29, zhangyunfei wrote:
> Hi Arno (Speaking individually),
> I've read the draft and the f= ollowing is my comments:
> 1) The effect of "choke/unchoke" i= s not very clear in the draft. Will
> this increase the transfer efficiency?<= /DIV>
 
The CHOKE/UNCHOKE is a mechanism that d= eployments/policies on top of the 
base protocol may choose to use. It&nbs= p;will make an implementation simpler. 
Imagine you are connected to a good&nbs= p;peer (i.e., one that sends DATA 
back). If the good peer sends you = a CHOKE, you immediately know that he <= /DIV>
is not going to respond anymore and&nbs= p;you should look for a different peer =
to download from. No need to retry = ;REQUESTs.
=A1=BEYunfei=A1=BFI understand this poi= nt. My question is=20 based on the fact that peers in p2p streaming
is of less incentive to be free-riding than = file=20 sharing peers. So the effect of CHOKE/UNCHOKE is not
not clear.
 
> 3) Is it better to combine se= ction 5,6, 7 into security consideration
> section as all these 3 sections&nb= sp;involve identifying the data is from the<= /DIV>
> reliable source/peers, which is related=  to security more or less. What's
> more, it makes the draft better&nb= sp;structured.
 
I personally see two issues. First, it&= nbsp;means content integrity isn't 
discussed before we present the protocol&nbs= p;options and UDP encapsulation. 
Second, the Security Considerations section = will become roughly 20 pages 
out of a 47 total which sounds a&n= bsp;bit unbalanced to me. But you have = more 
experience in this than I, so please&nb= sp;let me know what is common.
[Yunfei] How about combine section 5.6,7 int= o a=20 section before currently section 8? To my understanding,
 all the three sections talk about the = same=20 problem. Is that correct?
 
CU,
      Arno
------=_001_NextPart705472750025_=------ From sprevidi@cisco.com Mon Nov 12 06:43:26 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5962421F858F for ; Mon, 12 Nov 2012 06:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usVua8NPXcDx for ; Mon, 12 Nov 2012 06:43:25 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 22D5021F85A2 for ; Mon, 12 Nov 2012 06:43:24 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qACEhOHo002364 for ; Mon, 12 Nov 2012 15:43:24 +0100 (CET) Received: from dhcp-rom2-bb-gw-vla250-10-147-74-64.cisco.com (dhcp-rom2-bb-gw-vla250-10-147-74-64.cisco.com [10.147.74.64]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qACEfnBj014980; Mon, 12 Nov 2012 15:43:23 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: stefano previdi Date: Mon, 12 Nov 2012 15:43:23 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> To: ppsp , zhangyunfei Zhang X-Mailer: Apple Mail (2.1283) Subject: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 14:43:26 -0000 All, during our our IETF85 PPSP WG meeting, the authors of draft-cruz-ppsp-base-tracker-protocol-01 requested the adoption of the document as WG item. Please, send your comments (support, non-support, concerns, ...) to the mailing list not later than November 30, 2012. Thanks. s. From sprevidi@cisco.com Mon Nov 12 06:50:09 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAFA21F8539 for ; Mon, 12 Nov 2012 06:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHD5mv8OejOE for ; Mon, 12 Nov 2012 06:50:08 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E7D8121F8419 for ; Mon, 12 Nov 2012 06:50:07 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qACEggA7002261 for ; Mon, 12 Nov 2012 15:42:42 +0100 (CET) Received: from dhcp-rom2-bb-gw-vla250-10-147-74-64.cisco.com (dhcp-rom2-bb-gw-vla250-10-147-74-64.cisco.com [10.147.74.64]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qACEfnBh014980; Mon, 12 Nov 2012 15:42:41 +0100 (CET) From: stefano previdi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 12 Nov 2012 15:42:40 +0100 References: To: ppsp , zhangyunfei Zhang Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [ppsp] peer protocol in WG last call X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 14:50:09 -0000 All, during our our IETF85 PPSP WG meeting, we agreed to move draft-ietf-ppsp-peer-protocol-03 to WG last call. Please send your comments, concerns, support/non-support, others to the list not later than November 30, 2012. Thanks. s. From guyingjie@huawei.com Mon Nov 12 07:37:02 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD14C21F8568 for ; Mon, 12 Nov 2012 07:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.212 X-Spam-Level: X-Spam-Status: No, score=-97.212 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdA3sLWscOjm for ; Mon, 12 Nov 2012 07:37:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA7DD21F854B for ; Mon, 12 Nov 2012 07:36:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR47262; Mon, 12 Nov 2012 15:36:58 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 15:36:51 +0000 Received: from SZXEML461-HUB.china.huawei.com (10.82.67.204) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 15:36:57 +0000 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.192]) by szxeml461-hub.china.huawei.com ([10.82.67.204]) with mapi id 14.01.0323.003; Mon, 12 Nov 2012 23:36:45 +0800 From: "Guyingjie (Yingjie)" To: stefano previdi , ppsp , zhangyunfei Zhang Thread-Topic: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item Thread-Index: AQHNwOQYSUymKWqOdEa3RxQkJqHDSZfmVLDQ Date: Mon, 12 Nov 2012 15:36:44 +0000 Message-ID: References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.143] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] =?gb2312?b?tPC4tDogIFJlcXVlc3Q6IGRyYWZ0LWNydXotcHBzcC1i?= =?gb2312?b?YXNlLXRyYWNrZXItcHJvdG9jb2wgIGFzIFdHIGl0ZW0=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:37:02 -0000 SSBzdXBwb3J0IHRvIGFkb3B0IGRyYWZ0LWNydXotcHBzcC1iYXNlLXRyYWNrZXItcHJvdG9jb2wt MDEgYXMgYSBXRyBpdGVtLiANCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHBwc3AtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBwc3AtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBzdGVmYW5v IHByZXZpZGkNCreiy83KsbzkOiAyMDEyxOoxMdTCMTLI1SA4OjQzDQrK1bz+yMs6IHBwc3A7IHpo YW5neXVuZmVpIFpoYW5nDQrW98ziOiBbcHBzcF0gUmVxdWVzdDogZHJhZnQtY3J1ei1wcHNwLWJh c2UtdHJhY2tlci1wcm90b2NvbCBhcyBXRyBpdGVtDQoNCg0KQWxsLA0KDQpkdXJpbmcgb3VyIG91 ciBJRVRGODUgUFBTUCBXRyBtZWV0aW5nLCB0aGUgYXV0aG9ycyBvZg0KZHJhZnQtY3J1ei1wcHNw LWJhc2UtdHJhY2tlci1wcm90b2NvbC0wMSByZXF1ZXN0ZWQgdGhlIGFkb3B0aW9uIG9mIHRoZSBk b2N1bWVudCBhcyBXRyBpdGVtLg0KDQpQbGVhc2UsIHNlbmQgeW91ciBjb21tZW50cyAoc3VwcG9y dCwgbm9uLXN1cHBvcnQsIGNvbmNlcm5zLCAuLi4pIHRvIHRoZSBtYWlsaW5nIGxpc3Qgbm90IGxh dGVyIHRoYW4gTm92ZW1iZXIgMzAsIDIwMTIuDQoNClRoYW5rcy4NCnMuDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0 DQpwcHNwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bw c3ANCg== From rui.cruz@ieee-pt.org Mon Nov 12 07:49:17 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F355F21F859D for ; Mon, 12 Nov 2012 07:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.357 X-Spam-Level: X-Spam-Status: No, score=-100.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcx59wiDYSPe for ; Mon, 12 Nov 2012 07:49:15 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5AC921F85C4 for ; Mon, 12 Nov 2012 07:49:14 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u46so3175167wey.31 for ; Mon, 12 Nov 2012 07:49:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=6Kqh1yrnOTjQeKgkAYdujhEZN4fcUoVIREHP5YhIHBQ=; b=jlCn5JRpGd9CrvGkZoiKDsrdu/DkFqmb0LnUEhm6Y7/0QQ/YeYqG1EYsxf5cgCajcQ T00U80tUYmt+HxkWaZUcSoQ/1u/QN1zZhtSQ15x+bTZTeg7JLGNFIfZWiFlLGpkDz2xN 4smGqmox2PXEFCj9MsupzfNVBwEkJ6ui2tkDb0plI9W12/5iK/GeA6cJia/cFSZoupso whwADpnIp7Rt2Fy4rWxyM3ezhTWoZh9nqvvpLSol+8EtFms80g7ot0BBDMTzQ+sVJyEu dtYqdgjDRQRWrmwcYVluMNfI/UAQ3XVNIpcZH2HuW4qvk4cbxyOy+jBukjSfo4qxgsVC LNDw== Received: by 10.180.19.73 with SMTP id c9mr15649281wie.8.1352735353728; Mon, 12 Nov 2012 07:49:13 -0800 (PST) Received: from [192.168.1.220] (89-180-138-223.net.novis.pt. [89.180.138.223]) by mx.google.com with ESMTPS id q10sm12214927wie.2.2012.11.12.07.49.11 (version=SSLv3 cipher=OTHER); Mon, 12 Nov 2012 07:49:12 -0800 (PST) Sender: Rui Cruz Content-Type: multipart/alternative; boundary="Apple-Mail=_D6ACF063-F1D6-40EB-8937-1E6AA79734D2" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Rui Cruz In-Reply-To: Date: Mon, 12 Nov 2012 15:49:05 +0000 Message-Id: References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> To: "Guyingjie (Yingjie)" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnKRBbYVEVKXRyvsK3qowNlhfvxEjCwSs0Am+QqkxjYUqQtsiDLGIpZjGF3b/FsOn4s5ivK Cc: Rui Cruz , ppsp Subject: Re: [ppsp] =?utf-8?b?562U5aSNOiAgUmVxdWVzdDogZHJhZnQtY3J1ei1wcHNwLWJh?= =?utf-8?q?se-tracker-protocol__as_WG_item?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:49:17 -0000 --Apple-Mail=_D6ACF063-F1D6-40EB-8937-1E6AA79734D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 I also support adopting draft-cruz-ppsp-base-tracker-protocol-01 as a WG = item. Regards, Rui Cruz rui.cruz@ieee.org IST/INESC-ID/INOV - Lisbon, Portugal __________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp On 12/11/2012, at 15:36, "Guyingjie (Yingjie)" = wrote: > I support to adopt draft-cruz-ppsp-base-tracker-protocol-01 as a WG = item.=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED stefano previdi > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C212=C8=D5 8:43 > =CA=D5=BC=FE=C8=CB: ppsp; zhangyunfei Zhang > =D6=F7=CC=E2: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as = WG item >=20 >=20 > All, >=20 > during our our IETF85 PPSP WG meeting, the authors of > draft-cruz-ppsp-base-tracker-protocol-01 requested the adoption of the = document as WG item. >=20 > Please, send your comments (support, non-support, concerns, ...) to = the mailing list not later than November 30, 2012. >=20 > Thanks. > s. >=20 >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_D6ACF063-F1D6-40EB-8937-1E6AA79734D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 I = also support adopting draft-cruz-ppsp-base-tracker-protocol-01 as a = WG item.

Regards,

Rui = Cruz
<= font class=3D"Apple-style-span" = color=3D"#1555cb">
IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= div>ppsp mailing = list

On 12/11/2012, at 15:36, "Guyingjie (Yingjie)" <guyingjie@huawei.com> = wrote:

I support to adopt = draft-cruz-ppsp-base-tracker-protocol-01 as a WG item. =

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] =B4=FA=B1= =ED stefano previdi
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C212=C8=D5= 8:43
=CA=D5=BC=FE=C8=CB: ppsp; zhangyunfei Zhang
=D6=F7=CC=E2: = [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG = item


All,

during our our IETF85 PPSP WG meeting, the = authors of
draft-cruz-ppsp-base-tracker-protocol-01 requested the = adoption of the document as WG item.

Please, send your comments = (support, non-support, concerns, ...) to the mailing list not later than = November 30, = 2012.

Thanks.
s.


____________________________________= ___________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp
_______________________________________________
= ppsp mailing = list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

= --Apple-Mail=_D6ACF063-F1D6-40EB-8937-1E6AA79734D2-- From iesg-secretary@ietf.org Mon Nov 12 08:12:01 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E2821F8686; Mon, 12 Nov 2012 08:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyCBcCdL2QSR; Mon, 12 Nov 2012 08:12:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC4D21F8419; Mon, 12 Nov 2012 08:12:00 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121112161200.16581.32864.idtracker@ietfa.amsl.com> Date: Mon, 12 Nov 2012 08:12:00 -0800 Cc: ppsp@ietf.org Subject: [ppsp] Last Call: (Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)) to Informational RFC X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 16:12:01 -0000 The IESG has received a request from the Peer to Peer Streaming Protocol WG (ppsp) to consider the following document: - 'Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Peer-to-Peer (P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes the development of Peer to Peer Streaming Protocol (PPSP) including the tracker and peer protocol, and discusses the scope, requirements and use cases of PPSP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement/ballot/ No IPR declarations have been submitted directly on this I-D. From xiajinwei@huawei.com Mon Nov 12 17:03:38 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642DB21F857C for ; Mon, 12 Nov 2012 17:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=-4.219, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU4uYbN-wBkN for ; Mon, 12 Nov 2012 17:03:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2464621F856B for ; Mon, 12 Nov 2012 17:03:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALL79437; Tue, 13 Nov 2012 01:03:36 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 01:03:26 +0000 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 01:03:33 +0000 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.192]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Tue, 13 Nov 2012 09:03:29 +0800 From: Xiajinwei To: stefano previdi , ppsp , zhangyunfei Zhang Thread-Topic: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item Thread-Index: AQHNwOQXzP6vBLAqf0aRrPLJySOHUpfm81ag Date: Tue, 13 Nov 2012 01:03:28 +0000 Message-ID: References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.87] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] =?gb2312?b?tPC4tDogIFJlcXVlc3Q6IGRyYWZ0LWNydXotcHBzcC1i?= =?gb2312?b?YXNlLXRyYWNrZXItcHJvdG9jb2wgIGFzIFdHIGl0ZW0=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 01:03:38 -0000 SSBzdXBwb3J0IHRoaXMgd29yayB0byBiZSBhZG9wdGVkIGJ5IFBQU1AgV0cuDQoNCkJSDQpKaW53 ZWkNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBwcHNwLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpwcHNwLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gc3RlZmFubw0KPiBwcmV2aWRp DQo+ILeiy83KsbzkOiAyMDEyxOoxMdTCMTLI1SAyMjo0Mw0KPiDK1bz+yMs6IHBwc3A7IHpoYW5n eXVuZmVpIFpoYW5nDQo+INb3zOI6IFtwcHNwXSBSZXF1ZXN0OiBkcmFmdC1jcnV6LXBwc3AtYmFz ZS10cmFja2VyLXByb3RvY29sIGFzIFdHIGl0ZW0NCj4gDQo+IA0KPiBBbGwsDQo+IA0KPiBkdXJp bmcgb3VyIG91ciBJRVRGODUgUFBTUCBXRyBtZWV0aW5nLCB0aGUgYXV0aG9ycyBvZg0KPiBkcmFm dC1jcnV6LXBwc3AtYmFzZS10cmFja2VyLXByb3RvY29sLTAxIHJlcXVlc3RlZCB0aGUgYWRvcHRp b24NCj4gb2YgdGhlIGRvY3VtZW50IGFzIFdHIGl0ZW0uDQo+IA0KPiBQbGVhc2UsIHNlbmQgeW91 ciBjb21tZW50cyAoc3VwcG9ydCwgbm9uLXN1cHBvcnQsIGNvbmNlcm5zLCAuLi4pDQo+IHRvIHRo ZSBtYWlsaW5nIGxpc3Qgbm90IGxhdGVyIHRoYW4gTm92ZW1iZXIgMzAsIDIwMTIuDQo+IA0KPiBU aGFua3MuDQo+IHMuDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gcHBzcCBtYWlsaW5nIGxpc3QNCj4gcHBzcEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3ANCg== From joao.silva@inov.pt Mon Nov 12 07:53:19 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C990021F8618 for ; Mon, 12 Nov 2012 07:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_RECV_IP_082154=1.666, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se9GTURFIFO7 for ; Mon, 12 Nov 2012 07:53:16 -0800 (PST) Received: from lmv.inov.pt (lmv.inov.pt [146.193.64.2]) by ietfa.amsl.com (Postfix) with ESMTP id A05E421F85C2 for ; Mon, 12 Nov 2012 07:53:15 -0800 (PST) Received: from vinorelbina.local (bl5-42-62.dsl.telepac.pt [82.154.42.62]) (authenticated bits=0) by lmv.inov.pt (8.13.1/8.13.1) with ESMTP id qACFqLRU031242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 15:52:24 GMT Message-ID: <50A11B35.6000109@inov.pt> Date: Mon, 12 Nov 2012 15:52:21 +0000 From: =?UTF-8?B?Sm/Do28gUGVkcm8gVGF2ZWlyYQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: Rui Cruz References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (lmv.inov.pt [146.193.64.2]); Mon, 12 Nov 2012 15:52:25 +0000 (WET) X-INOV-EmailServer-Information: Please contact the Email service provider for more information X-INOV-EmailServer: Found to be clean X-INOV-EmailServer-From: joao.silva@inov.pt X-Mailman-Approved-At: Mon, 12 Nov 2012 17:42:35 -0800 Cc: ppsp Subject: Re: [ppsp] =?utf-8?b?562U5aSNOiAgUmVxdWVzdDogZHJhZnQtY3J1ei1wcHNwLWJh?= =?utf-8?q?se-tracker-protocol__as_WG_item?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 16:07:58 -0000 I also support adopting draft-cruz-ppsp-base-tracker-protocol-01 as a WG item. Best Regards -- João Pedro Taveira Pinto Silva - joao.silva@INOV.pt - +351 96 69 13 777 - +351 213 100 413 Development Engineer - Information Systems Unit INOV - Inesc Inovação - http://www.inov.pt - +351-213100444 On 12/11/12 15:49, Rui Cruz wrote: > I also support adopting draft-cruz-ppsp-base-tracker-protocol-01 as a WG item. > > Regards, > > Rui Cruz > rui.cruz@ieee.org > > IST/INESC-ID/INOV - Lisbon, Portugal > __________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > On 12/11/2012, at 15:36, "Guyingjie (Yingjie)" > wrote: > >> I support to adopt draft-cruz-ppsp-base-tracker-protocol-01 as a WG item. >> >> -----邮件原件----- >> 发件人: ppsp-bounces@ietf.org >> [mailto:ppsp-bounces@ietf.org ] 代表 stefano previdi >> 发送时间: 2012年11月12日 8:43 >> 收件人: ppsp; zhangyunfei Zhang >> 主题: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item >> >> >> All, >> >> during our our IETF85 PPSP WG meeting, the authors of >> draft-cruz-ppsp-base-tracker-protocol-01 requested the adoption of the >> document as WG item. >> >> Please, send your comments (support, non-support, concerns, ...) to the >> mailing list not later than November 30, 2012. >> >> Thanks. >> s. >> >> >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp > > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > From zhangyunfei@chinamobile.com Mon Nov 12 17:47:20 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC1A21F8802 for ; Mon, 12 Nov 2012 17:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.286 X-Spam-Level: X-Spam-Status: No, score=-95.286 tagged_above=-999 required=5 tests=[AWL=1.478, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKyoVwApCYGA for ; Mon, 12 Nov 2012 17:47:19 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5310521F880A for ; Mon, 12 Nov 2012 17:47:19 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 2B925E6B2; Tue, 13 Nov 2012 09:47:20 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 097C5E3B4; Tue, 13 Nov 2012 09:47:20 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012111309471904-2964 ; Tue, 13 Nov 2012 09:47:19 +0800 Date: Tue, 13 Nov 2012 09:47:13 +0800 From: zhangyunfei To: "stefano previdi" , ppsp References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com>, X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <201211130947132658808@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-13 09:47:19, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-13 09:47:19, Serialize complete at 2012-11-13 09:47:19 Content-Type: multipart/alternative; boundary="----=_001_NextPart434238016075_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19360.000 X-TM-AS-Result: No--16.406-7.0-31-10 X-imss-scan-details: No--16.406-7.0-31-10;No--16.406-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 01:47:20 -0000 This is a multi-part message in MIME format. ------=_001_NextPart434238016075_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdCBhbmQgc2VudCBjb21tZW50cyB0byB0aGUgZW1haWwg bGlzdC4gU3BlYWtpbmcgaW5kaXZpZHVhbGx5LCBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRo ZSBkb2N1bWVudCBhcyB0aGUgV0cgaXRlbS4NCg0KDQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5m ZWkNCg0KRnJvbTogc3RlZmFubyBwcmV2aWRpDQpEYXRlOiAyMDEyLTExLTEyIDIyOjQzDQpUbzog cHBzcDsgemhhbmd5dW5mZWkgWmhhbmcNClN1YmplY3Q6IFJlcXVlc3Q6IGRyYWZ0LWNydXotcHBz cC1iYXNlLXRyYWNrZXItcHJvdG9jb2wgYXMgV0cgaXRlbQ0KDQpBbGwsDQoNCmR1cmluZyBvdXIg b3VyIElFVEY4NSBQUFNQIFdHIG1lZXRpbmcsIHRoZSBhdXRob3JzIG9mIA0KZHJhZnQtY3J1ei1w cHNwLWJhc2UtdHJhY2tlci1wcm90b2NvbC0wMSByZXF1ZXN0ZWQgdGhlIGFkb3B0aW9uIA0Kb2Yg dGhlIGRvY3VtZW50IGFzIFdHIGl0ZW0uDQoNClBsZWFzZSwgc2VuZCB5b3VyIGNvbW1lbnRzIChz dXBwb3J0LCBub24tc3VwcG9ydCwgY29uY2VybnMsIC4uLikgDQp0byB0aGUgbWFpbGluZyBsaXN0 IG5vdCBsYXRlciB0aGFuIE5vdmVtYmVyIDMwLCAyMDEyLg0KDQpUaGFua3MuDQpzLg== ------=_001_NextPart434238016075_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
I have reviewed the draft and sent comments to the email list. Speaki= ng=20 individually, I support the adoption of the document as the WG item.<= /DIV>
 
 
Yunfei
 
zhangyunfei
 
Date: 2012-11-12 22:43
To: ppsp; zhangyunfei Zhang
Subject: Request: draft-cruz-ppsp-base-tracker-protocol a= s WG=20 item
 
All,
 
during our our IETF85 PPSP WG meeting,&= nbsp;the authors of 
draft-cruz-ppsp-base-tracker-protocol-01 requested the = ;adoption 
of the document as WG item.
 
Please, send your comments (support, non-sup= port, concerns, ...) 
to the mailing list not later than = ;November 30, 2012.
 
Thanks.
s.
 
 
------=_001_NextPart434238016075_=------ From a.bakker@vu.nl Tue Nov 13 02:07:33 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B87A21F861E for ; Tue, 13 Nov 2012 02:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnKjeSu-iRxW for ; Tue, 13 Nov 2012 02:07:32 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id 34CE821F861B for ; Tue, 13 Nov 2012 02:07:31 -0800 (PST) Received: from PEXHB012A.vu.local (130.37.236.66) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 13 Nov 2012 11:07:27 +0100 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.66) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 13 Nov 2012 11:07:26 +0100 Message-ID: <50A21BF4.9010102@cs.vu.nl> Date: Tue, 13 Nov 2012 11:07:48 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 10:07:33 -0000 On 12/11/2012 15:43, stefano previdi wrote: > > All, > > during our our IETF85 PPSP WG meeting, the authors of > draft-cruz-ppsp-base-tracker-protocol-01 requested the adoption > of the document as WG item. > > Please, send your comments (support, non-support, concerns, ...) > to the mailing list not later than November 30, 2012. > Hi all the basics are generally ok, but I do have the following comments and concerns: p. 13. Why doesn't a peer in SEED mode connect to other peers? Especially in a world with NAT boxes it may be necessary for seeders to initiate the connection themselves. p. 14. IMHO STAT_REPORT should be optional to have a tracker protocol that provides just the basics, which is returning a list of peers for a given swarm. See also below. p. 15. IMHO the transient states TERMINATED and START should be removed from the tracker and peer state machines, respectively. They are transitions, not states. p. 16. A Table 6 defining STAT_REPORT properties is missing, Table 6 currently defines Response values. My major concern is security, in particular, when the tracker supports returning peers based on criteria specified by the client. At present a client can specify the preferred capabilities of a returned peer in terms of its NAT ability, load (in terms of number of peers), online time and upload bandwidth level (see p. 20). For a tracker to be able to reply to such queries it must receive this information somehow. Currently this is done by self-reporting of registering peers. It is unclear how this feature can work reliably in an environment with malicious peers which will lie about their capabilities in order to attract peers. The draft suggests a global trust mechanism, but that is currently not available. I therefore propose to remove this capability-based peer selection until that time. Instead, the tracker should always return a random sample from the peer population (a feature required by the current peer protocol (-03, Sec.13.2.3) and not yet addressed in the draft.) So I support the transition to Working Group Document, provided that the above concerns are resolved to the working group's satisfaction ASAP. CU, Arno P.S. Typos / nits: p. 10. "since it joins" -> "since it joined" p. 13. "HTTT/1.1" -> "HTTP/1.1" p. 29. "If the length of the message does not matches the Content-Length" How will you know, given HTTP is run over TCP which is a byte stream? From rui.cruz@ieee-pt.org Tue Nov 13 04:19:04 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2038121F869F for ; Tue, 13 Nov 2012 04:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=1.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWZn3zuMXSXu for ; Tue, 13 Nov 2012 04:19:02 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD7F321F86A2 for ; Tue, 13 Nov 2012 04:19:00 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1307355eek.31 for ; Tue, 13 Nov 2012 04:18:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=m7Fuoz/u7+R2eJlZik82ka61CHTt0OYIvCUavxaM+d4=; b=c0V+X5JT3PsfsPtd+jDGY3+kyAn2DHrQQbJ+zHw3fNrs5I5+AhBE0BY2Iu0C82hzMs 2AaNh4voqp5hwo247sizj+/h+uTu98bLIXZn1LMEo+CjhZ5oZhD9RfXdt2/AwcCFftfH Ypf6Kopnp4NUe+EJ5sdegyjt8AQc97LeUw47Wtlj0hSM8StS1vxv9XW0ghAR9TC6quci nKCSJNJvJ/lLe/xotmShcHGlHaOeRsSzZkCc5kzYCSe0yufEcXxVJ/rVjcHtFstsyvnn sujWmq1m+NA82KTICC3pUMfAPlvECwTrHOeYYM87+kbka+KHUkW6zgbPoqrfVC1ayAyX UTyA== Received: by 10.14.216.193 with SMTP id g41mr74518942eep.37.1352809138537; Tue, 13 Nov 2012 04:18:58 -0800 (PST) Received: from [192.168.1.211] ([89.180.167.198]) by mx.google.com with ESMTPS id b44sm22290127eep.12.2012.11.13.04.18.56 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 04:18:57 -0800 (PST) Sender: Rui Cruz Content-Type: multipart/alternative; boundary="Apple-Mail=_E0AF8924-BD4F-414C-A31B-D85B9875E3FC" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Rui Cruz In-Reply-To: <50A21BF4.9010102@cs.vu.nl> Date: Tue, 13 Nov 2012 12:18:47 +0000 Message-Id: <52529918-0790-47C2-84D0-A1D11FE14129@ieee.org> References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> <50A21BF4.9010102@cs.vu.nl> To: arno@cs.vu.nl X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkH7Cz90l1u1C++XuQp+quWL20iabcDTNyzK6WGxUjgPnY4gLe1IBEgSdw4Le5q/lDBr0+/ Cc: Rui Cruz , ppsp@ietf.org Subject: Re: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 12:19:04 -0000 --Apple-Mail=_E0AF8924-BD4F-414C-A31B-D85B9875E3FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Arno, All, First of all, thanks for spotting those typos in the text. About Content-Lenght information mismatch, this is an issue of HTTP = message formatting, not of the Tracker Protocol Requests/Responses. Answering Arno's concerns: > p. 13. Why doesn't a peer in SEED mode connect to other peers? = Especially in a world with NAT boxes it may be necessary for seeders to = initiate the connection themselves. Nothing prevents a peer with all content (seed) to connect to other = peers. But that is an implementation of the Peer, and the Peer Protocol, = not of the Tracker, or the Tracker Protocol. > p. 14. IMHO STAT_REPORT should be optional to have a tracker protocol = that provides just the basics, which is returning a list of peers for a = given swarm. See also below. The STAT_REPORT has two purposes: 1) a status heart-beat (mandatory) for = the tracker to keep the peer Registered (facilitating cleaning up of = inactive/vanished peers in the swarm); 2) reporting statistic data = (optional) > p. 15. IMHO the transient states TERMINATED and START should be = removed from the tracker and peer state machines, respectively. They are = transitions, not states. The Tracker has a State Machine (Figure 4), and each Peer-ID Transaction = State Machine. While there is at least one Registered and active peer in = a swarm the Tracker is in State STARTED. Each TSM of a Peer-ID, when = TERMINATEs is removed, but if it is the LAST one, then, when TERMINATEs, = the Tracker SM transitions from the STARTED state to the TERMINATED = State, which is transient, returning the Tracker to INIT State (started = but no activity, no peers, no swarms). > p. 16. A Table 6 defining STAT_REPORT properties is missing, Table 6 = currently defines Response values. In fact, an extra line in Table 4 erroneously refers to Table 6 on = @property values. That extra line needs to be either removed (as the = only @property defined for the base-protocol is "StreamStatistics") and = replaced by a sentence in section 8.2 or point to a new table, not Table = 6, with that information. > My major concern is security, in particular, when the tracker supports > returning peers based on criteria specified by the client. ..... > For a tracker to be able to reply to such queries it must receive this = information somehow. That information can be received by the Tracker in STAT_REPORTs. > The draft suggests a global trust mechanism, but that is currently not = available. I therefore propose to remove this capability-based peer = selection until that time. Instead, the tracker should always return a = random sample from the peer population. This is an implementation issue of the Tracker service. The tracker protocol itself supports the transfer of the associated = information, if desired. The most basic information is just the number = of peers to be returned in a list, without reference to any "special" = capabilities. The PeerNUM element and attributes are not even mandatory. > the tracker should always return a random sample from the peer = population (a feature required by the current peer protocol (-03, = Sec.13.2.3) and not yet addressed in the draft.) Again, this is just an implementation issue of the Tracker service. The tracker protocol itself is able to transport that information, but = is not involved in the selection process, be it random or based on = specified criteria. Regards, Rui Cruz rui.cruz@ieee.org IST/INESC-ID/INOV - Lisbon, Portugal __________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp On 13/11/2012, at 10:07, Arno Bakker wrote: > On 12/11/2012 15:43, stefano previdi wrote: >>=20 >> All, >>=20 >> during our our IETF85 PPSP WG meeting, the authors of >> draft-cruz-ppsp-base-tracker-protocol-01 requested the adoption >> of the document as WG item. >>=20 >> Please, send your comments (support, non-support, concerns, ...) >> to the mailing list not later than November 30, 2012. >>=20 >=20 > Hi all >=20 > the basics are generally ok, but I do have the following comments and = concerns: >=20 > p. 13. Why doesn't a peer in SEED mode connect to other peers? = Especially in a world with NAT boxes it may be necessary for seeders to = initiate the connection themselves. >=20 > p. 14. IMHO STAT_REPORT should be optional to have a tracker protocol = that provides just the basics, which is returning a list of peers for a = given swarm. See also below. >=20 > p. 15. IMHO the transient states TERMINATED and START should be = removed from the tracker and peer state machines, respectively. They are = transitions, not states. >=20 > p. 16. A Table 6 defining STAT_REPORT properties is missing, Table 6 = currently defines Response values. >=20 > My major concern is security, in particular, when the tracker supports > returning peers based on criteria specified by the client. At present > a client can specify the preferred capabilities of a returned peer > in terms of its NAT ability, load (in terms of number of peers), = online time and upload bandwidth level (see p. 20). For a tracker to be = able to reply to such queries it must receive this information somehow. = Currently this is done by self-reporting of registering peers. >=20 > It is unclear how this feature can work reliably in an environment = with malicious peers which will lie about their capabilities in order to = attract peers. The draft suggests a global trust mechanism, but that is = currently not available. I therefore propose to remove this = capability-based peer selection until that time. Instead, the tracker = should always return a random sample from the peer population (a feature = required by the current peer protocol (-03, Sec.13.2.3) and not yet = addressed in the draft.) >=20 > So I support the transition to Working Group Document, provided that = the above concerns are resolved to the working group's satisfaction = ASAP. >=20 > CU, > Arno >=20 > P.S. Typos / nits: >=20 > p. 10. "since it joins" -> "since it joined" >=20 > p. 13. "HTTT/1.1" -> "HTTP/1.1" >=20 > p. 29. "If the length of the message does not matches the = Content-Length" How will you know, given HTTP is run over TCP which is a = byte stream? >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_E0AF8924-BD4F-414C-A31B-D85B9875E3FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Arno, All,

First of all, thanks for spotting those = typos in the text.
About Content-Lenght information mismatch, = this is an issue of HTTP message formatting, not of the Tracker Protocol = Requests/Responses.

Answering Arno's = concerns:

p. 13. Why = doesn't a peer in SEED mode connect to other peers? Especially in a = world with NAT boxes it may be necessary for seeders to initiate the = connection themselves.
Nothing prevents a peer with all = content (seed) to connect to other peers. But that is an implementation = of the Peer, and the Peer Protocol, not of the Tracker, or the Tracker = Protocol.

p. 14. IMHO = STAT_REPORT should be optional to have a tracker protocol that provides = just the basics, which is returning a list of peers for a given swarm. = See also below.
The STAT_REPORT has two purposes: 1) a = status heart-beat (mandatory) for the tracker to keep the peer = Registered (facilitating cleaning up of inactive/vanished peers in the = swarm);  2) reporting statistic data = (optional)

p. 15. = IMHO the transient states TERMINATED and START should be removed from = the tracker and peer state machines, respectively. They are transitions, = not states.
The Tracker has a State Machine (Figure 4), and = each Peer-ID Transaction State Machine. While there is at least one = Registered and active peer in a swarm the Tracker is in State STARTED. = Each TSM of a Peer-ID, when TERMINATEs is removed, but if it is the LAST = one, then, when TERMINATEs, the Tracker SM transitions from the STARTED = state to the TERMINATED State, which is transient, returning the Tracker = to INIT State (started but no activity, no peers, no = swarms).

p. 16. A = Table 6 defining STAT_REPORT properties is missing, Table 6 currently = defines Response values.
In fact, an extra line in Table = 4 erroneously refers to Table 6 on @property values. That = extra line needs to be either removed (as the only @property defined for = the base-protocol is "StreamStatistics") and replaced by a sentence in = section 8.2 or point to a new table, not Table 6, with that = information.

My major = concern is security, in particular, when the tracker = supports
returning peers based on criteria specified by the = client.
.....
For a tracker to = be able to reply to such queries it must receive this information = somehow.
That information can be received by the Tracker in = STAT_REPORTs.

The = draft suggests a global trust mechanism, but that is currently not = available. I therefore propose to remove this capability-based peer = selection until that time. Instead, the tracker should always return a = random sample from the peer population.
This is an = implementation issue of the Tracker service.
The tracker = protocol itself supports the transfer of the associated information, if = desired. The most basic information is just the number of peers to be = returned in a list, without reference to any "special" capabilities. The = PeerNUM element and attributes are not even = mandatory.

the = tracker should always return a random sample from the peer population (a = feature required by the current peer protocol (-03, Sec.13.2.3) and not = yet addressed in the draft.)
Again, this is just an = implementation issue of the Tracker service.
The tracker = protocol itself is able to transport that information, but is not = involved in the selection process, be it random or based on specified = criteria.


Regards,

Rui = Cruz
<= font class=3D"Apple-style-span" = color=3D"#1555cb">
IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= div>ppsp mailing = list

On 13/11/2012, at 10:07, Arno Bakker <arno@cs.vu.nl> wrote:

On = 12/11/2012 15:43, stefano previdi wrote:

All,

during our our IETF85 PPSP WG meeting, the = authors of
draft-cruz-ppsp-base-tracker-protocol-01 requested the = adoption
of the document as WG item.

Please, send your = comments (support, non-support, concerns, ...)
to the mailing list = not later than November 30, 2012.


Hi = all

the basics are generally ok, but I do have the following = comments and concerns:

p. 13. Why doesn't a peer in SEED mode = connect to other peers? Especially in a world with NAT boxes it may be = necessary for seeders to initiate the connection themselves.

p. = 14. IMHO STAT_REPORT should be optional to have a tracker protocol that = provides just the basics, which is returning a list of peers for a given = swarm. See also below.

p. 15. IMHO the transient states = TERMINATED and START should be removed from the tracker and peer state = machines, respectively. They are transitions, not states.

p. 16. = A Table 6 defining STAT_REPORT properties is missing, Table 6 currently = defines Response values.

My major concern is security, in = particular, when the tracker supports
returning peers based on = criteria specified by the client. At present
a client can specify the = preferred capabilities of a returned peer
in terms of its NAT = ability, load (in terms of number of peers), online time and upload = bandwidth level (see p. 20). For a tracker to be able to reply to such = queries it must receive this information somehow. Currently this is done = by self-reporting of registering peers.

It is unclear how this = feature can work reliably in an environment with malicious peers which = will lie about their capabilities in order to attract peers. The draft = suggests a global trust mechanism, but that is currently not available. = I therefore propose to remove this capability-based peer selection until = that time. Instead, the tracker should always return a random sample = from the peer population (a feature required by the current peer = protocol (-03, Sec.13.2.3) and not yet addressed in the = draft.)

So I support the transition to Working Group Document, = provided that the above concerns are resolved to the working group's = satisfaction ASAP.

CU,
  Arno

P.S. Typos / = nits:

p. 10. "since it joins" -> "since it joined"

p. = 13. "HTTT/1.1" -> "HTTP/1.1"

p. 29. "If the length of the = message does not matches the Content-Length" How will you know, given = HTTP is run over TCP which is a byte = stream?

_______________________________________________
ppsp = mailing list
ppsp@ietf.org
https://www.ietf.org/m= ailman/listinfo/ppsp

= --Apple-Mail=_E0AF8924-BD4F-414C-A31B-D85B9875E3FC-- From a.bakker@vu.nl Tue Nov 13 23:14:03 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3517D21F8546 for ; Tue, 13 Nov 2012 23:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi3xI+oLYNmI for ; Tue, 13 Nov 2012 23:14:02 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id 54DBD21F853A for ; Tue, 13 Nov 2012 23:14:01 -0800 (PST) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 14 Nov 2012 08:13:59 +0100 Received: from [192.168.0.102] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 14 Nov 2012 08:13:58 +0100 Message-ID: <50A344CA.6060307@cs.vu.nl> Date: Wed, 14 Nov 2012 08:14:18 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Rui Cruz References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> <50A21BF4.9010102@cs.vu.nl> <52529918-0790-47C2-84D0-A1D11FE14129@ieee.org> In-Reply-To: <52529918-0790-47C2-84D0-A1D11FE14129@ieee.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp@ietf.org Subject: Re: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 07:14:03 -0000 Hi Rui et al. please see inline: On 13/11/2012 13:18, Rui Cruz wrote: > >> p. 13. Why doesn't a peer in SEED mode connect to other peers? >> Especially in a world with NAT boxes it may be necessary for seeders >> to initiate the connection themselves. > Nothing prevents a peer with all content (seed) to connect to other > peers. But that is an implementation of the Peer, and the Peer Protocol, > not of the Tracker, or the Tracker Protocol. > At the moment when peerMode is SEED the tracker appears not to send a peer list (p. 27 at bottom). Please clarify how a seed obtains a peer list, e.g. does PeerNum take priority over peerMode? > The STAT_REPORT has two purposes: 1) a status heart-beat (mandatory) for > the tracker to keep the peer Registered (facilitating cleaning up of > inactive/vanished peers in the swarm); 2) reporting statistic data > (optional) > For function 1, CONNECT suffices, see p. 17 2nd item. This means that STAT_REPORT can be made truly optional. At the moment STAT_REPORT is mandatory ("This request message MUST be sent periodically to the tracker", p. 14.) >> My major concern is security, in particular, when the tracker supports >> returning peers based on criteria specified by the client. > ..... >> For a tracker to be able to reply to such queries it must receive this >> information somehow. > That information can be received by the Tracker in STAT_REPORTs. > >> The draft suggests a global trust mechanism, but that is currently not >> available. I therefore propose to remove this capability-based peer >> selection until that time. Instead, the tracker should always return a >> random sample from the peer population. > This is an implementation issue of the Tracker service. > The tracker protocol itself supports the transfer of the associated > information, if desired. The most basic information is just the number > of peers to be returned in a list, without reference to any "special" > capabilities. The PeerNUM element and attributes are not even mandatory. > But if it is currently not possible to implement a tracker service that offers this functionality and is secure in a malicious environment, the support for it should not be in the tracker protocol, IMHO. CU, Arno P.S. Typo: There are also references to a Section 8.6 in the draft, which no longer exist. From rui.cruz@ieee-pt.org Wed Nov 14 04:36:39 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A72D21F85ED for ; Wed, 14 Nov 2012 04:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgsOXB-eNlAL for ; Wed, 14 Nov 2012 04:36:38 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF5B21F85D1 for ; Wed, 14 Nov 2012 04:36:37 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id hj6so402829wib.13 for ; Wed, 14 Nov 2012 04:36:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=VciSS6QLGu7+iX5z8tekC/xLh/EII2wnyTsjHzrMeb4=; b=jRE4NVhAiCyDqObr6LoJToDfgFs7GLa38sJkx+/Ik6Glq2wFNsq7Gm4XK5CfNReH2k 1hTAj55IBI+/NsXakUNaM8MzbrLro8It6hFxiUUtLGJcq81PraAyddtumxmVxn7maNfX fLbtGA85BLdJpvCR0xXncRYHP94g4ZNa+bo7Il2HQsuvwZMihDSRrAsiUbXufoQ0Xbct ZYh5mgsMfqlXKcenuon1/OAARVeS+NLb6m+mak1Tmc+4JpSc09w5pmyfXuf30oNbZGOi /k8r/JcZuuDMtOW6bYbkOmU5clgwjKljpzGClUd33bgW2jOcV8ELNj+eMOgzCGQOKWVk ybXw== Received: by 10.216.195.159 with SMTP id p31mr1615354wen.139.1352896596461; Wed, 14 Nov 2012 04:36:36 -0800 (PST) Received: from [192.168.1.211] (89-180-167-198.net.novis.pt. [89.180.167.198]) by mx.google.com with ESMTPS id d16sm6373714wiw.8.2012.11.14.04.36.33 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 04:36:35 -0800 (PST) Sender: Rui Cruz Content-Type: multipart/alternative; boundary="Apple-Mail=_2837975F-7F99-43EB-89BF-86A6BC8CEE88" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Rui Cruz In-Reply-To: <50A344CA.6060307@cs.vu.nl> Date: Wed, 14 Nov 2012 12:36:15 +0000 Message-Id: <35D4DB2A-7468-490C-8147-FA9E5FF69B50@ieee.org> References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> <50A21BF4.9010102@cs.vu.nl> <52529918-0790-47C2-84D0-A1D11FE14129@ieee.org> <50A344CA.6060307@cs.vu.nl> To: X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkVqXtS54GiHVrdvXSA5+NJ+lqLJmc2e539ZfDhHsiE6VshcXeTaagjpUgCKa3AsOG008da Cc: Rui Cruz , ppsp@ietf.org Subject: Re: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 12:36:39 -0000 --Apple-Mail=_2837975F-7F99-43EB-89BF-86A6BC8CEE88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Arno, Please see inline. Regards, Rui Cruz rui.cruz@ieee.org IST/INESC-ID/INOV - Lisbon, Portugal __________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp On 14/11/2012, at 07:14, Arno Bakker wrote: > Hi Rui et al. >=20 > please see inline: >=20 > On 13/11/2012 13:18, Rui Cruz wrote: >>=20 >>> p. 13. Why doesn't a peer in SEED mode connect to other peers? >>> Especially in a world with NAT boxes it may be necessary for seeders >>> to initiate the connection themselves. >> Nothing prevents a peer with all content (seed) to connect to other >> peers. But that is an implementation of the Peer, and the Peer = Protocol, >> not of the Tracker, or the Tracker Protocol. >>=20 >=20 > At the moment when peerMode is SEED the tracker appears not to send a = peer list (p. 27 at bottom). Please clarify how a seed obtains a peer = list, e.g. does PeerNum take priority over peerMode? Using only the base protocol (the extended protocol provides extra = control in this area) the condition you mention might be turned implicit = if peerNum is supplied when peerMode is SEED. I personally have no objection with that condition. If WG agrees a paragraph can be added to describe it. >=20 >=20 >> The STAT_REPORT has two purposes: 1) a status heart-beat (mandatory) = for >> the tracker to keep the peer Registered (facilitating cleaning up of >> inactive/vanished peers in the swarm); 2) reporting statistic data >> (optional) >>=20 >=20 > For function 1, CONNECT suffices, see p. 17 2nd item. This means that > STAT_REPORT can be made truly optional. At the moment STAT_REPORT is = mandatory ("This request message MUST be sent periodically to the = tracker", p. 14.) The control mechanism on active peers in a swarm,and therefore the = capability to provide useful peer lists, needs a periodic status = reported from the peers, otherwise the tracker would be just a simple = and useless log.=20 As such, the STAT_REPORT for periodic status cannot be turned optional. = It is the simple mechanism that allows the tracker to provide useful = information. The CONNECT message in the base protocol is restricted to certain = conditions. The second item you mention refers to an active peer = (already joined in one or in N swarms) requesting to LEAVE the one or = the N swarms, or to switch (LEAVE[x] + JOIN[y]) between two swarms. = Those conditions either turn the peer inactive (the tracker would delete = the peer records) or keep the peer as active but in a different swarm. = These actions do not completely replace a periodic status report, in = special when the duration of the streaming is high (hours).=20 >=20 >=20 >>> My major concern is security, in particular, when the tracker = supports >>> returning peers based on criteria specified by the client. >> ..... >>> For a tracker to be able to reply to such queries it must receive = this >>> information somehow. >> That information can be received by the Tracker in STAT_REPORTs. >>=20 >>> The draft suggests a global trust mechanism, but that is currently = not >>> available. I therefore propose to remove this capability-based peer >>> selection until that time. Instead, the tracker should always return = a >>> random sample from the peer population. >> This is an implementation issue of the Tracker service. >> The tracker protocol itself supports the transfer of the associated >> information, if desired. The most basic information is just the = number >> of peers to be returned in a list, without reference to any "special" >> capabilities. The PeerNUM element and attributes are not even = mandatory. >>=20 >=20 > But if it is currently not possible to implement a tracker service = that offers this functionality and is secure in a malicious environment, = the support for it should not be in the tracker protocol, IMHO. I do not agree with your position stating that a (global) trust = functionality is "not possible" to be offered. An implementation of a tracker service can perfectly offer a trust = functionality. It might not be "global" but can be offered. In EU Project SARACEN we have an implementation of a trust/reputation = functionality. Additionally, peer selection criteria (from the tracker) is not = restricted to "peer capabilities" (real or fake) but also to network = location (the tracker service may use that criterion, independently of = the information provided by the peer). >=20 > CU, > Arno >=20 > P.S. Typo: There are also references to a Section 8.6 in the draft, = which no longer exist. Thanks, again. We already had noticed that typo, it should be 8.3. --Apple-Mail=_2837975F-7F99-43EB-89BF-86A6BC8CEE88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Arno,

Please see inline.
Regards,

Rui = Cruz
<= font class=3D"Apple-style-span" = color=3D"#1555cb">
IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= div>ppsp mailing = list

On 14/11/2012, at 07:14, Arno Bakker <arno@cs.vu.nl> wrote:

Hi Rui et = al.

please see inline:

On 13/11/2012 13:18, Rui Cruz = wrote:

p. 13. = Why doesn't a peer in SEED mode connect to other peers?
Especially in = a world with NAT boxes it may be necessary for seeders
to initiate = the connection themselves.
Nothing prevents a peer with = all content (seed) to connect to other
peers. But that is an = implementation of the Peer, and the Peer Protocol,
not of the = Tracker, or the Tracker Protocol.


At the moment = when peerMode is SEED the tracker appears not to send a peer list (p. 27 = at bottom). Please clarify how a seed obtains a peer list, e.g. does = PeerNum take priority over peerMode?
Using only the = base protocol (the extended protocol provides extra control in this = area) the condition you mention might be turned implicit if peerNum is = supplied when peerMode is SEED.
I personally have no objection = with that condition.
If WG agrees a paragraph can be added to = describe it.



The STAT_REPORT has two purposes: 1) a status heart-beat = (mandatory) for
the tracker to keep the peer Registered (facilitating = cleaning up of
inactive/vanished peers in the swarm); 2) reporting = statistic data
(optional)


For function 1, = CONNECT suffices, see p. 17 2nd item. This means that
STAT_REPORT can = be made truly optional. At the moment STAT_REPORT is mandatory ("This = request message MUST be sent periodically to the tracker", p. = 14.)
The control mechanism on active peers in a = swarm,and therefore the capability to provide useful peer lists, needs a = periodic status reported from the peers, otherwise the tracker would be = just a simple and useless log. 
As such, the STAT_REPORT = for periodic status cannot be turned optional. It is the simple = mechanism that allows the tracker to provide useful = information.

The CONNECT message in the base = protocol is restricted to certain conditions. The second item you = mention refers to an active peer (already joined in one or in N swarms) = requesting to LEAVE the one or the N swarms, or to switch (LEAVE[x] + = JOIN[y]) between two swarms. Those conditions either turn the peer = inactive (the tracker would delete the peer records) or keep the peer as = active but in a different swarm. These actions do not completely replace = a periodic status report, in special when the duration of the streaming = is high (hours). 



My major concern is security, in particular, when the = tracker supports
returning peers based on criteria specified by the = client.
.....
For a tracker = to be able to reply to such queries it must receive this
information = somehow.
That information can be received by the Tracker = in STAT_REPORTs.

The draft suggests a = global trust mechanism, but that is currently not
available. I = therefore propose to remove this capability-based peer
selection = until that time. Instead, the tracker should always return a
random = sample from the peer population.
This is an = implementation issue of the Tracker service.
The tracker protocol = itself supports the transfer of the associated
information, if = desired. The most basic information is just the number
of peers to be = returned in a list, without reference to any "special"
capabilities. = The PeerNUM element and attributes are not even = mandatory.


But if it is currently not possible = to implement a tracker service that offers this functionality and is = secure in a malicious environment, the support for it should not be in = the tracker protocol, IMHO.
I do not agree with = your position stating that a (global) trust functionality is "not = possible" to be offered.
An implementation of a tracker = service can perfectly offer a trust functionality. It might not be = "global" but can be offered.
In EU Project SARACEN we have an = implementation of a trust/reputation = functionality.
Additionally, peer selection criteria (from the = tracker) is not restricted to "peer capabilities" (real or fake) but = also to network location (the tracker service may use that criterion, = independently of the information provided by the = peer).


CU,
=    Arno

P.S. Typo: There are also references to a = Section 8.6 in the draft, which no longer exist.
Thanks, = again. We already had noticed that typo, it should be = 8.3.

= --Apple-Mail=_2837975F-7F99-43EB-89BF-86A6BC8CEE88-- From riccardo.bernardini@uniud.it Mon Nov 19 02:45:52 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5822F21F8593 for ; Mon, 19 Nov 2012 02:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbbrmu1GlNqV for ; Mon, 19 Nov 2012 02:45:51 -0800 (PST) Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9F58821F858B for ; Mon, 19 Nov 2012 02:45:49 -0800 (PST) Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id A4EBCB7297C for ; Mon, 19 Nov 2012 11:45:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at talitha1 Received: from smtp.uniud.it ([158.110.1.136]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10028) with ESMTP id 9UbGYWmaYSBR for ; Mon, 19 Nov 2012 11:45:47 +0100 (CET) Received: from webmail.uniud.it (webmail2.cc.uniud.it [158.110.1.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uniud.it (Postfix) with ESMTPSA id 8F4A3B0038 for ; Mon, 19 Nov 2012 11:45:47 +0100 (CET) Received: from 158.110.27.77 ([158.110.27.77]) by webmail.uniud.it (Horde Framework) with HTTP; Mon, 19 Nov 2012 11:45:47 +0100 Message-ID: <20121119114547.60502iibxkcnt0bf@webmail.uniud.it> Date: Mon, 19 Nov 2012 11:45:47 +0100 From: Riccardo Bernardini To: ppsp@ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) Subject: Re: [ppsp] peer protocol in WG last call X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 10:45:52 -0000 Dear all, please find some comments of mine about the I-D First, the easy stuff. Some typos: == Page 35, First line of 9.5 HAVE == Add an 's' to "consist" == Page 37, second line of 9.10 REQUEST == Add an 's' to "want" Now to the "consistent" stuff: == Page 9, Section 2.3 == "If A crashes ungracefully, peers should remove A from their peer list when they detect it no longer send messages." How long should a peer wait before declaring A crashed? The case is easy if I send REQUEST to A and A does not responds, but what if A sent me a CHOKE? In that case I do not send REQUEST to A, but (according to the example in the third paragraph of 2.2) I still expect to receive HAVE from A. In this case, I detect that A no longer sends messages when the last message from A was received too much time ago. How much is "too much"? Should we leave the peer free to decide or should we give at least some guidelines? Also, there is the problem that when A crashes it remains registered with the tracker, although maybe this is not a problem directly related with PPSPP. == Page 10, Section 3 == It is said that "absence of any response indicates and error" and that "Invalid messages are discarded, and further communication with the peer SHOULD be stopped." Isn't this criterion a bit too strong? If a request is lost (e.g., because of congestion), the sender will interpret the absence of response as an error or a bad peer. Also, how long should a peer wait for declaring absence of response? Should we give guidelines? == Page 12, Section 3.9. == It is said "The CHOKE and UNCHOKE messages are informational as a peer is not required to respond to REQUESTs." However, if I understand correctly, if a peer does not respond to REQUESTs, the peer will be banned, according to the criterion in Section 3. Am I missing something? == Page 13, Section 3.10.2 == The describe Hole Punching technique requests that "When peer A introduces peer B to peer C by sending a PEX_RES message to C, it SHOULD also send a PEX_RES message to B introducing C" I have a couple of doubts about this * This supposes that A can send messages to B. If B is behind a NAT, this requires that A already has a hole opened toward B. Therefore, A can forward only the addresses of peers it is communicating with. Actually, this is required by 3.10.1 "The addresses MUST be of peers it has exchanged messages with in the last 60 seconds..." so this should not be a problem. Would it be worth adding a sentence to emphasize this point? (e.g. "Note that A can send a message to B since by 3.10.1 A must have exchanged messages with C..." This is only an example, if the suggestion is accepted, feel free to suit it to your taste) * With this model of hole punching, the peer can only connect initially to peers with public IP; in particular, the addresses provided by the tracker must be public IPs. Am I right? == Page 16, last paragraph of Section 4.3.1 == "To record which chunks ... discussed in detail in [BINMAP]" This is maybe a stylistic detail of tiny order, so feel free to skip over. This paragraph describes an implementation suggestion that can be helpful for someone who wants to write some software, but it is not necessary for interoperability. Maybe it could be worth to emphasize this. I remember I saw in some RFC (do not ask which) something like Implementation note: To record which chunks ... discussed in detail in [BINMAP] As I said, this is just a minor stylistic detail. == Page 16, Section 4.3.2 == Another stylistic detail. It is said that "...an implementation MAY choose to use ACK messages..." than later "When a receiving peer has successfully checked ... it MUST send an ACK message...". The two verbs MAY and MUST seems to be in contrast; actually, I understand that the MUST is conditioned to the first MAY. Maybe it could be worth to emphasize this by adding "If ACK messages are used, " in front of "a receiving peer" so that the final text could look like "If ACK messages are used, a receiving peer that has successfully checked ... MUST send an ACK message ... " Again, this is just an example, so, if my suggestion is accepted, feel free to adapt the form to your taste. == Top of Page 17, Section 4.4 == "When a range translates to multiple bins, the byte-range peer the byte-range peer should send multiple e.g. HAVE message." This sentence looks a bit garbled, at the very least "the byte-range peer" is repeated twice. == Page 20, Section 5.3 == "The hashes necessary to verify a chunk are in principle its sibling's hash and all its uncle hashes ... can be optimized " If I understand correctly, this optimization requires that a peer MUST save and preserve all the received hashes. Although reasonable, this is not necessarly true (unless the protocol mandates so). With reference to the example of 5.3, suppose that when I received chunk C1 I received also the hash 5, I can use it to verify the correctness of C1 and then throw that hash away to save memory (if, for example, I am a small device). If the peer that sends me chunk C7 wants to do this optimization, I MUST conserve the uncle hashes I received so far. Note that this is not an implementation detail, but it could hurt interoperability. I see two solutions for this: (a) let's write somewhere that a node MUST conserve the uncle hashes, or (b) if a node does not conserve uncle hashes it can say that during the HANDSHAKING by using a suitable option. == Page 29, Section 8.2. "Version option" == Maybe this is thinking a bit in advance, but what should a peer set as version value when the peer is able to "speak" more than one protocol version? Is the protocol version "global" for the whole swarm? If it is, could the "negotiation" about the version done at join time, making this option redundant? (For example, the peer could receive the required version with the swarm ID from the tracker). If the protocol let every pair of peers choose the protocol version, maybe this option could be modified to accept a list of versions. When peer A sends its HANDSHAKE to peer B, it could include in the Version option all the versions it understands. If one of those versions is understood by B too, B would reply with the chosen version as payload of the Version option. Any thought? == Page 34, Section 9.3. Channels == It is said that "... PPSPP-over-UDP uses a multiplexing scheme, called "channels"..." Later it is said that "When channels are used..." My doubt is: is the use of channels mandatory with UDP? If yes, the hypothesis "when channels are used..." is redundant; if not, how does a peer know that channels are going to be used? Also, if channels are not used, is the KEEPALIVE message just an empty packet? Moreover, the payload of HANDSHAKE message should change if channels are not used. == Page 42, Section 13.2.2. == This section is about using the tracker as certification authority. It is said "Upon receipt, the tracker creates a membership certificate from the request with swarm ID S, a timestamp T and the external IP and port it received the message from..." Am I wrong, or this scheme could fail if the peer is behind a symmetric NAT? Would it be worth to add at least a note about this? -- Riccardo stefano previdi ha scritto: > All, > > during our our IETF85 PPSP WG meeting, we agreed to move > draft-ietf-ppsp-peer-protocol-03 to WG last call. > > Please send your comments, concerns, support/non-support, others > to the list not later than November 30, 2012. > > Thanks. > s. > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > -- Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine From zhangyunfei@chinamobile.com Tue Nov 20 23:34:20 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C6621F8605 for ; Tue, 20 Nov 2012 23:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.074 X-Spam-Level: X-Spam-Status: No, score=-96.074 tagged_above=-999 required=5 tests=[AWL=1.843, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0zybfYFOZJV for ; Tue, 20 Nov 2012 23:34:19 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 79EDC21F85F0 for ; Tue, 20 Nov 2012 23:34:19 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 94CC3E634; Wed, 21 Nov 2012 15:34:18 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 89911E62E; Wed, 21 Nov 2012 15:34:18 +0800 (CST) Received: from zyf-PC ([10.2.55.113]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012112115341711-15016 ; Wed, 21 Nov 2012 15:34:17 +0800 Date: Wed, 21 Nov 2012 15:34:13 +0800 From: zhangyunfei To: "arno@cs.vu.nl" References: <20121022054506.24206.72390.idtracker@ietfa.amsl.com> <201210221507482101757@chinamobile.com>, <5084F1F7.4020002@cs.vu.nl> <2012110216294380861230@chinamobile.com>, <509905D6.2050901@cs.vu.nl> <2012110914064759431029@chinamobile.com>, <50A0B4A0.5070604@cs.vu.nl> <2012111617251329042383@chinamobile.com>, <50AC805B.2010104@cs.vu.nl> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012112115341377168410@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-21 15:34:17, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-21 15:34:18, Serialize complete at 2012-11-21 15:34:18 Content-Type: multipart/alternative; boundary="----=_001_NextPart725571241372_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19382.005 X-TM-AS-Result: No--22.453-7.0-31-10 X-imss-scan-details: No--22.453-7.0-31-10;No--22.453-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: ppsp Subject: Re: [ppsp] comments on draft-ietf-ppsp-peer-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 07:34:20 -0000 This is a multi-part message in MIME format. ------=_001_NextPart725571241372_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SGkgQXJubywNCiAgICAgU29ycnkgdGhhdCBJIG1hZGUgYSBtaXN0YWtlIG5vdCAgY2MtaW5nICB0 byBwcHNwIG1haWxpbmcgbGlzdC4gUGxlYXNlIHNlZSBpbmxpbmUgZm9yIHRoZSByZXBseS4NCg0K QlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBBcm5vIEJha2tlcg0KRGF0 ZTogMjAxMi0xMS0yMSAxNToxOA0KVG86IHpoYW5neXVuZmVpDQpTdWJqZWN0OiBSZTogY29tbWVu dHMgb24gZHJhZnQtaWV0Zi1wcHNwLXBlZXItcHJvdG9jb2wtMDMudHh0DQpPbiAxNi8xMS8yMDEy IDEwOjI1LCB6aGFuZ3l1bmZlaSB3cm90ZToNCj4gSGkgQXJubywNCj4gU2VlIGlubGluZS4NCg0K SGkgWXVuZmVpDQoNCkknbSBzdXJlIHlvdSBub3RpY2VkIHRoYXQgdGhpcyBtYWlsIGRpZG4ndCBn byB0byB0aGUgbWFpbGluZyBsaXN0Pw0KDQo+IFtZdW5mZWldIE15IGZlZWxpbmcgaXMgYXMgZm9s bG93czogUDJQIHN0cmVtYWluZywgaW4gY29udHJhc3QgdG8gcDJwDQo+IGZpbGUgZG93bmxvYWRp bmcsDQo+IG5lZWQgbW9yZSBzdGFibGUgYW5kIGxvbmdlciBjb25uZWN0aW9ucyB3aXRoIHNvbWUg KG1heSBmZXcpIHBlZXJzIGZvcg0KPiB2aWRlbyBxdWFsaXR5IGFzc3VyYW5jZS4NCj4gVGhhdCBp cyB0byBzYXksIGEgc3RyZWFtaW5nIHBlZXIgaGFzIGxlc3MgY2hhbmNlIHRvIGJlIHNlbGZsaXNo IChub3QNCj4gY29udHJpYnV0ZSkgaW4gb3JkZXIgdG8NCj4gZ2V0IGRhdGEgZnJvbSBvdGhlciBw ZWVycyggb3IgZWxzZSwgb3RoZXIgcGVlcnMgY2FuIGVhc2lseSBkZXRlY3QgdGhlDQo+IGJlaGF2 aW9yIGFuZCBjYW4ga2ljayBpdCBvdXQgb2YNCj4gdGhlIHN3YXJtKS4gSXMgdGhhdCByaWdodD8N Cg0KWW91IGFyZSByaWdodCB0aGF0IGZvciBsaXZlIHN0cmVhbWluZyB0aGVyZSBpcyBtb3JlIHJp c2sgaW4gY2hlYXRpbmcuDQpGb3IgdmlkZW8tb24tZGVtYW5kIGl0IGlzIG1vcmUgY29tcGxleC4g V2hldGhlciBwZW9wbGUgd2lsbCBjaGVhdCBvciBub3QgDQpkZXBlbmRzIHJhdGlvbmFsbHkgb24g d2hldGhlciB0aGVyZSBpcyBzdWZmaWNpZW50IGNhcGFjaXR5LCBJTUhPLiBJZiB5b3UgDQpnZXQg Y3V0IG9mZiBieSBvbmUgcGVlciB0aGF0IGlzIG5vdCBhIHByb2JsZW0gaWYgdGhlcmUgaXMgYW5v dGhlciBvbmUgDQp0aGF0IHlvdSBjYW4gbGVlY2ggZnJvbS4gVGhlcmUgaXMgbm8gc2VjdXJlIG9y IGVmZmljaWVudCB3YXkgb2YgDQpkaXN0cmlidXRpbmcgaW5mbyBhYm91dCBiYWQgcGVlcnMgdG8g b3RoZXJzLCBzbyBhcyBsb25nIGFzIHRoZXJlIGFyZSANCnZpY3RpbXMsIHlvdSBjYW4gY29udGlu dWUgZnJlZXJpZGluZy4NCg0KW1l1bmZlaV0gSSBhbSBva2F5IHRvIGFkZCBDSE9LRS9VTkNIT0tF IGluIHBlZXIgcHJvdG9jb2wuDQoNCj4gSSB0aGluayA2IChNZXJrbGUgdHJlZSArIGF1dG8gc2l6 ZSkgY2FuIGJlIG1hZGUgYSBzdWJzZWN0aW9uIG9mIDUNCj4gKGNvbnRlbnQgaW50ZWdyaXR5KS4g SSdkIGxpa2UgdG8ga2VlcCA3IChMaXZlIFN0cmVhbWluZykgYXMgYSBzZXBhcmF0ZQ0KPiBzZWN0 aW9uIGFzIGl0IGRpc2N1c3NlcyBtb3JlIHRoYW4gaW50ZWdyaXR5IHByb3RlY3Rpb24sIGluIHBh cnRpY3VsYXIsDQo+IGZvcmdldHRpbmcgY2h1bmtzIHRvIGFjaGlldmUgZWZmaWNpZW50IGluZmlu aXRlIHN0cmVhbXMuDQo+IFtZdW5mZWldIFNvcnJ5IGJ1dCBjYW4geW91IHNheSBtb3JlIG9uIHRo ZSBsYXN0IHNlbnRlbmNlP0kgYW0gbm90IHN1cmUgSQ0KPiBnZXQgeW91ciBwb2ludC4NCg0KU2Vj dGlvbiA3IGlzIGFib3V0IGxpdmUgc3RyZWFtaW5nIGluIGdlbmVyYWwsIG5vdCBqdXN0IGNvbnRl bnQgDQpwcm90ZWN0aW9uLiBIZW5jZSBJIGRvbid0IHdhbnQgdG8gbWVyZ2UgaXQgaW50byB0aGUg Y29udGVudCBpbnRlZ3JpdHkgDQpzZWN0aW9uLiBJbiBwYXJ0aWN1bGFyLCBTZWN0aW9uIDcgdGFs a3MgYWJvdXQgaG93IHBlZXJzIGNvbW11bmljYXRlIHRoYXQgDQp0aGV5IGFyZSBkaXNjYXJkaW5n IGNodW5rcyBmcm9tIHRoZSBwYXN0IHN1Y2ggdGhhdCB0aGVpciBkaXNrIGRvZXNuJ3QgDQpmaWxs IHVwIG9uIGxvbmcgYnJvYWRjYXN0cy4NCg0KW1l1bmZlaV0gSSB3b3VsZCBzdWdnZXN0IHRoZW4g bWVyZ2UgdGhlIGNvbnRlbnQgaW50ZWdyaXR5IGNoZWNrIHBhcnQgaW4gbGl2ZSBzdHJlYW1pbmcN CmludG8gImNvbnRlbnQgaW50ZWdyaXR5IiBzZWN0aW9uIGFuZCBsZWF2ZSBvdGhlciBwYXJ0IGlu IGxpdmUgc3RyZWFtaW5nIGFub3RoZXIgc2VjdGlvbi4NCg0KDQpIb3BlIHRoaXMgaGVscHMuIEZl ZWwgZnJlZSB0byBjcm9zc3Bvc3QgdGhpcyB0byB0aGUgbWFpbGluZyBsaXN0Lg0KDQpDVSwNCiAg ICAgQXJubw== ------=_001_NextPart725571241372_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" =EF=BB=BF
Hi Arno,
     Sorry that I made a mistake not  cc-ing= =20  to ppsp mailing list. Please see inline for the reply.
 
BR
Yunfei
 
zhangyunfei
 
From: Arno Bakker
Date: 2012-11-21 15:18
To: zhangyunfei
Subject: Re: comments on=20 draft-ietf-ppsp-peer-protocol-03.txt
On 16/11/2012 10:25, zhangyunfei wrote:
> Hi Arno,
> See inline.
 
Hi Yunfei
 
I'm sure you noticed that this mail&nbs= p;didn't go to the mailing list?
 
> [Yunfei] My feeling is as follows:=  P2P stremaing, in contrast to p2p
> file downloading,
> need more stable and longer connec= tions with some (may few) peers for
> video quality assurance.
> That is to say, a streaming p= eer has less chance to be selflish (not=
> contribute) in order to
> get data from other peers( or = ;else, other peers can easily detect the
> behavior and can kick it out = of
> the swarm). Is that right?
 
You are right that for live streaming&n= bsp;there is more risk in cheating.
For video-on-demand it is more complex. = ;Whether people will cheat or not 
depends rationally on whether there is = sufficient capacity, IMHO. If you 
get cut off by one peer that is&nb= sp;not a problem if there is another on= e 
that you can leech from. There is = no secure or efficient way of 
distributing info about bad peers to ot= hers, so as long as there are 
victims, you can continue freeriding.
 
[Yunfei] I am okay to add CHOKE/UNCHOKE in p= eer=20 protocol.
 
> I think 6 (Merkle tree + auto=  size) can be made a subsection of = ;5
> (content integrity). I'd like to k= eep 7 (Live Streaming) as a separate
> section as it discusses more than&= nbsp;integrity protection, in particular,
> forgetting chunks to achieve efficient&= nbsp;infinite streams.
> [Yunfei] Sorry but can you say&nbs= p;more on the last sentence?I am not su= re I
> get your point.
 
Section 7 is about live streaming in&nb= sp;general, not just content 
protection. Hence I don't want to merge=  it into the content integrity 
section. In particular, Section 7 talks = ;about how peers communicate that 
they are discarding chunks from the pas= t such that their disk doesn't 
fill up on long broadcasts.
 
[Yunfei] I would suggest then merge the cont= ent=20 integrity check part in live streaming
into "content integrity" section and leave o= ther=20 part in live streaming another section.
 
 
Hope this helps. Feel free to crosspost=  this to the mailing list.
 
CU,
     Arno
 
 
------=_001_NextPart725571241372_=------ From a.bakker@vu.nl Wed Nov 21 04:49:28 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A49921F85C9 for ; Wed, 21 Nov 2012 04:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[AWL=1.487, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aILwmWYLEG3D for ; Wed, 21 Nov 2012 04:49:27 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 670A121F85F3 for ; Wed, 21 Nov 2012 04:49:26 -0800 (PST) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 21 Nov 2012 13:49:24 +0100 Received: from [192.168.0.102] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 21 Nov 2012 13:49:24 +0100 Message-ID: <50ACCDF2.9070402@cs.vu.nl> Date: Wed, 21 Nov 2012 13:49:54 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: References: <20121119114547.60502iibxkcnt0bf@webmail.uniud.it> In-Reply-To: <20121119114547.60502iibxkcnt0bf@webmail.uniud.it> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] peer protocol in WG last call X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 12:49:28 -0000 Hi Riccardo thanks for the in-depth review! Please see inline. On 19/11/2012 11:45, Riccardo Bernardini wrote: > > First, the easy stuff. Some typos: > Will be corrected. > Now to the "consistent" stuff: > > == Page 9, Section 2.3 == > "If A crashes ungracefully, peers should remove A from their peer > list when they detect it no longer send messages." > > How much is "too much"? Should we leave the peer free > to decide or should we give at least some guidelines? > Your proposal makes sense, I'm just not sure what is customary in RFCs. Should this go in this draft or in the planned usage guide? Chairs? > Also, there is the problem that when A crashes it remains registered > with the tracker, although maybe this is not a problem directly > related with PPSPP. > This is addressed in the current base tracker proposal. A peer needs to periodically refresh its registration to stay tracked. > == Page 10, Section 3 == > > It is said that "absence of any response indicates and error" and > that "Invalid messages are discarded, and further communication with > the peer SHOULD be stopped." > > Isn't this criterion a bit too strong? If a request is lost (e.g., > because of congestion), the sender will interpret the absence of > response as an error or a bad peer. Also, how long should a peer wait > for declaring absence of response? Should we give guidelines? > We could give guidelines, but again, I'm not sure that is customary. I assume implementers apply common sense and, for example, not declare a peer dead after 1 packet loss over an unreliable transport. Invalid messages mean that there is really something wrong and that sender and receiver don't understand eachother, so then the receiver really should stop the interaction. > == Page 12, Section 3.9. == > > It is said "The CHOKE and UNCHOKE messages are informational as a peer > is not required to respond to REQUESTs." However, if I understand > correctly, if a peer does not respond to REQUESTs, the peer will be > banned, according to the criterion in Section 3. Am I missing > something? > No, I don't think you are missing something. The idea is that a peer P requesting chunks from peer Q will look for another peer R when Q doesn't send chunks, and Q didn't send a CHOKE to announce the fact it wouldn't be responding. P should take into account packet loss and swarm size (if there is just 1 other peer in the swarm, don't disconnect), of course. If P is not getting chunks from Q it moves on. > == Page 13, Section 3.10.2 == > > I have a couple of doubts about this > > * This supposes that A can send messages to B. > > so this should not be a problem. Would it be worth adding a > sentence to emphasize this point? (e.g. "Note that A can send a > message to B since by 3.10.1 A must have exchanged messages with C..." Sure. > * With this model of hole punching, the peer can only connect > initially to peers with public IP; in particular, the addresses > provided by the tracker must be public IPs. Am I right? > Yes. > == Page 16, last paragraph of Section 4.3.1 == > > Implementation note: > To record which chunks ... discussed in detail in [BINMAP] > You are right. > == Page 16, Section 4.3.2 == > > Another stylistic detail. It is said that "...an implementation MAY > choose to use ACK messages..." than later "When a receiving peer has > successfully checked ... it MUST send an ACK message...". Will be corrected. > == Top of Page 17, Section 4.4 == > > "When a range translates to multiple bins, the byte-range peer the > byte-range peer should send multiple e.g. HAVE message." > > This sentence looks a bit garbled, at the very least "the byte-range > peer" is repeated twice. > Will be corrected. > == Page 20, Section 5.3 == > > "The hashes necessary to verify a chunk are in principle its > sibling's hash and all its uncle hashes ... can be optimized " > > If I understand correctly, this optimization requires that a peer MUST > save and preserve all the received hashes. Yes. The requirement that a sender must be able to provide these hashes implies that you should record them. I'll explicitly add the conclusion that this means you MUST record them, *if* you plan to announce you have them to others. In other words, limited devices can circument this requirement by not sending HAVEs to others after they received a chunk. Hence they are not announcing the availability and are not required to provide them. Not sending HAVEs is allowed by the protocol. Note, however, that this does require that the implementation uses a reciprocity policy that allows this behaviour, as the limited devices are actually freeriding. > == Page 29, Section 8.2. "Version option" == > > Maybe this is thinking a bit in advance, but what should a peer set as > version value when the peer is able to "speak" more than one protocol > version? Do you have pointers to protocols where this mechanism is used? This could save a few roundtrips of HANDSHAKE messages, so good for time-till-playback if there are indeed several incompatible versions, which I hope there will not be ;o) > == Page 34, Section 9.3. Channels == > > It is said that > > "... PPSPP-over-UDP uses a multiplexing scheme, called "channels"..." > > Later it is said that > > "When channels are used..." > > My doubt is: is the use of channels mandatory with UDP? If yes, the > hypothesis "when channels are used..." is redundant; Yes it is mandatory. Pardon me if I'm wrong, but your point may just be grammatical, "When X" in English implies that X will be the case at some point. So you say "When I die" not "If I die", but I'm not a native speaker myself. I'll make it clearer. > == Page 42, Section 13.2.2. == > > This section is about using the tracker as certification authority. > It is said > > "Upon receipt, the tracker creates a membership certificate from > the request with swarm ID S, a timestamp T and the external IP and > port it received the message from..." > > Am I wrong, or this scheme could fail if the peer is behind a > symmetric NAT? Would it be worth to add at least a note about this? > You are right, but that problem applies for any tracker registration. I'll add a note. CU, Arno From a.bakker@vu.nl Wed Nov 21 04:56:20 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54121F8695 for ; Wed, 21 Nov 2012 04:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFu3RiujLH5Z for ; Wed, 21 Nov 2012 04:56:20 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8396A21F866F for ; Wed, 21 Nov 2012 04:56:19 -0800 (PST) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 21 Nov 2012 13:56:17 +0100 Received: from [192.168.0.102] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 21 Nov 2012 13:56:18 +0100 Message-ID: <50ACCF90.6080308@cs.vu.nl> Date: Wed, 21 Nov 2012 13:56:48 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Rui Cruz References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> <50A21BF4.9010102@cs.vu.nl> <52529918-0790-47C2-84D0-A1D11FE14129@ieee.org> <50A344CA.6060307@cs.vu.nl> <35D4DB2A-7468-490C-8147-FA9E5FF69B50@ieee.org> In-Reply-To: <35D4DB2A-7468-490C-8147-FA9E5FF69B50@ieee.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp@ietf.org Subject: Re: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 12:56:20 -0000 Hi Rui et al, please see inline. On 14/11/2012 13:36, Rui Cruz wrote: >> >> At the moment when peerMode is SEED the tracker appears not to send a >> peer list (p. 27 at bottom). Please clarify how a seed obtains a peer >> list, e.g. does PeerNum take priority over peerMode? > Using only the base protocol (the extended protocol provides extra > control in this area) the condition you mention might be turned implicit > if peerNum is supplied when peerMode is SEED. > I personally have no objection with that condition. > If WG agrees a paragraph can be added to describe it. > Please do. > The CONNECT message in the base protocol is restricted to certain > conditions. IMHO, these restrictions on CONNECT could be lifted to allow it to be used for refreshing registrations, yielding a very simple 1 message protocol. >> But if it is currently not possible to implement a tracker service >> that offers this functionality and is secure in a malicious >> environment, the support for it should not be in the tracker protocol, >> IMHO. > I do not agree with your position stating that a (global) trust > functionality is "not possible" to be offered. > An implementation of a tracker service can perfectly offer a trust > functionality. It might not be "global" but can be offered. > In EU Project SARACEN we have an implementation of a trust/reputation > functionality. Let me phrase it differently: Can you build a PPSP-based YouTube that securely uses this property-based peer selection? If not, the draft should make it clear that property-based selections can only be safely used under specific conditions. CU, Arno From zhangyunfei@chinamobile.com Wed Nov 21 17:49:35 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3981321E8034 for ; Wed, 21 Nov 2012 17:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.657 X-Spam-Level: X-Spam-Status: No, score=-96.657 tagged_above=-999 required=5 tests=[AWL=1.966, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV1DRxRATew6 for ; Wed, 21 Nov 2012 17:49:32 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0E21F0C5F for ; Wed, 21 Nov 2012 17:49:32 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 1C6DEE4FC; Thu, 22 Nov 2012 09:49:33 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id E79D3E3C4; Thu, 22 Nov 2012 09:49:32 +0800 (CST) Received: from zyf-PC ([10.2.53.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012112209493108-2737 ; Thu, 22 Nov 2012 09:49:31 +0800 Date: Thu, 22 Nov 2012 09:49:26 +0800 From: zhangyunfei To: "arno@cs.vu.nl" , ppsp , "Riccardo Bernardini" References: <20121119114547.60502iibxkcnt0bf@webmail.uniud.it>, <50ACCDF2.9070402@cs.vu.nl> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012112209492619916710@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-22 09:49:31, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-22 09:49:32, Serialize complete at 2012-11-22 09:49:32 Content-Type: multipart/alternative; boundary="----=_001_NextPart132753443508_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19384.003 X-TM-AS-Result: No--32.937-7.0-31-10 X-imss-scan-details: No--32.937-7.0-31-10;No--32.937-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] peer protocol in WG last call X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 01:49:35 -0000 This is a multi-part message in MIME format. ------=_001_NextPart132753443508_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgQXJubywgUmljY2FyZG8sDQogICAgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkJSDQpZdW5mZWkN Cg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0KRnJvbTogQXJubyBCYWtrZXINCkRhdGU6IDIwMTItMTEt MjEgMjA6NDkNClRvOiBwcHNwQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Bwc3BdIHBlZXIgcHJv dG9jb2wgaW4gV0cgbGFzdCBjYWxsDQpIaSBSaWNjYXJkbw0KDQp0aGFua3MgZm9yIHRoZSBpbi1k ZXB0aCByZXZpZXchIFBsZWFzZSBzZWUgaW5saW5lLg0KDQpPbiAxOS8xMS8yMDEyIDExOjQ1LCBS aWNjYXJkbyBCZXJuYXJkaW5pIHdyb3RlOg0KPg0KPiBGaXJzdCwgdGhlIGVhc3kgc3R1ZmYuICBT b21lIHR5cG9zOg0KPg0KDQpXaWxsIGJlIGNvcnJlY3RlZC4NCg0KDQo+IE5vdyB0byB0aGUgImNv bnNpc3RlbnQiIHN0dWZmOg0KPg0KPiA9PSBQYWdlIDksIFNlY3Rpb24gMi4zID09DQo+ICAgICAg IklmIEEgY3Jhc2hlcyB1bmdyYWNlZnVsbHksIHBlZXJzIHNob3VsZCByZW1vdmUgQSBmcm9tIHRo ZWlyIHBlZXINCj4gbGlzdCB3aGVuIHRoZXkgZGV0ZWN0IGl0IG5vIGxvbmdlciBzZW5kIG1lc3Nh Z2VzLiINCj4NCj4gSG93IG11Y2ggaXMgInRvbyBtdWNoIj8gIFNob3VsZCB3ZSBsZWF2ZSB0aGUg cGVlciBmcmVlDQo+IHRvIGRlY2lkZSBvciBzaG91bGQgd2UgZ2l2ZSBhdCBsZWFzdCBzb21lIGd1 aWRlbGluZXM/DQo+DQoNCllvdXIgcHJvcG9zYWwgbWFrZXMgc2Vuc2UsIEknbSBqdXN0IG5vdCBz dXJlIHdoYXQgaXMgY3VzdG9tYXJ5IGluIFJGQ3MuDQpTaG91bGQgdGhpcyBnbyBpbiB0aGlzIGRy YWZ0IG9yIGluIHRoZSBwbGFubmVkIHVzYWdlIGd1aWRlPw0KQ2hhaXJzPw0KDQpbWXVuZmVpXSBJ IHRoaW5rIFJpY2NhcmRvJ3Mgc3VnZ2VzdGlvbiBtYWtlcyBzZW5zZS4gSXQncyBiZXR0ZXIgdG8g aGF2ZSBzb21lIA0KbWV0cmljcyB0byBqdWRnZSB0aGlzIGluIGJvdGggcHJvdG9jb2wgc3BlY2lm aWNhdGlvbiBhbmQgdXNhZ2UgZ3VpZGUuDQoNCg0KPiBBbHNvLCB0aGVyZSBpcyB0aGUgcHJvYmxl bSB0aGF0IHdoZW4gQSBjcmFzaGVzIGl0IHJlbWFpbnMgcmVnaXN0ZXJlZA0KPiB3aXRoIHRoZSB0 cmFja2VyLCBhbHRob3VnaCBtYXliZSB0aGlzIGlzIG5vdCBhIHByb2JsZW0gZGlyZWN0bHkNCj4g cmVsYXRlZCB3aXRoIFBQU1BQLg0KPg0KDQpUaGlzIGlzIGFkZHJlc3NlZCBpbiB0aGUgY3VycmVu dCBiYXNlIHRyYWNrZXIgcHJvcG9zYWwuIEEgcGVlciBuZWVkcyB0byANCnBlcmlvZGljYWxseSBy ZWZyZXNoIGl0cyByZWdpc3RyYXRpb24gdG8gc3RheSB0cmFja2VkLg0KDQoNCj4gPT0gUGFnZSAx MCwgU2VjdGlvbiAzID09DQo+DQo+ICAgICBJdCBpcyBzYWlkIHRoYXQgImFic2VuY2Ugb2YgYW55 IHJlc3BvbnNlIGluZGljYXRlcyBhbmQgZXJyb3IiIGFuZA0KPiB0aGF0ICJJbnZhbGlkIG1lc3Nh Z2VzIGFyZSBkaXNjYXJkZWQsIGFuZCBmdXJ0aGVyIGNvbW11bmljYXRpb24gd2l0aA0KPiB0aGUg cGVlciBTSE9VTEQgYmUgc3RvcHBlZC4iDQo+DQo+IElzbid0IHRoaXMgY3JpdGVyaW9uIGEgYml0 IHRvbyBzdHJvbmc/ICBJZiBhIHJlcXVlc3QgaXMgbG9zdCAoZS5nLiwNCj4gYmVjYXVzZSBvZiBj b25nZXN0aW9uKSwgdGhlIHNlbmRlciB3aWxsIGludGVycHJldCB0aGUgYWJzZW5jZSBvZg0KPiBy ZXNwb25zZSBhcyBhbiBlcnJvciBvciBhIGJhZCBwZWVyLiAgQWxzbywgaG93IGxvbmcgc2hvdWxk IGEgcGVlciB3YWl0DQo+IGZvciBkZWNsYXJpbmcgYWJzZW5jZSBvZiByZXNwb25zZT8gIFNob3Vs ZCB3ZSBnaXZlIGd1aWRlbGluZXM/DQo+DQoNCldlIGNvdWxkIGdpdmUgZ3VpZGVsaW5lcywgYnV0 IGFnYWluLCBJJ20gbm90IHN1cmUgdGhhdCBpcyBjdXN0b21hcnkuIEkgDQphc3N1bWUgaW1wbGVt ZW50ZXJzIGFwcGx5IGNvbW1vbiBzZW5zZSBhbmQsIGZvciBleGFtcGxlLCBub3QgZGVjbGFyZSBh IA0KcGVlciBkZWFkIGFmdGVyIDEgcGFja2V0IGxvc3Mgb3ZlciBhbiB1bnJlbGlhYmxlIHRyYW5z cG9ydC4gSW52YWxpZCANCm1lc3NhZ2VzIG1lYW4gdGhhdCB0aGVyZSBpcyByZWFsbHkgc29tZXRo aW5nIHdyb25nIGFuZCB0aGF0IHNlbmRlciBhbmQgDQpyZWNlaXZlciBkb24ndCB1bmRlcnN0YW5k IGVhY2hvdGhlciwgc28gdGhlbiB0aGUgcmVjZWl2ZXIgcmVhbGx5IHNob3VsZCANCnN0b3AgdGhl IGludGVyYWN0aW9uLg0KDQoNCj4gPT0gUGFnZSAxMiwgU2VjdGlvbiAzLjkuID09DQo+DQo+IEl0 IGlzIHNhaWQgIlRoZSBDSE9LRSBhbmQgVU5DSE9LRSBtZXNzYWdlcyBhcmUgaW5mb3JtYXRpb25h bCBhcyBhIHBlZXINCj4gaXMgbm90IHJlcXVpcmVkIHRvIHJlc3BvbmQgdG8gUkVRVUVTVHMuIiAg SG93ZXZlciwgaWYgSSB1bmRlcnN0YW5kDQo+IGNvcnJlY3RseSwgaWYgYSBwZWVyIGRvZXMgbm90 IHJlc3BvbmQgdG8gUkVRVUVTVHMsIHRoZSBwZWVyIHdpbGwgYmUNCj4gYmFubmVkLCBhY2NvcmRp bmcgdG8gdGhlIGNyaXRlcmlvbiBpbiBTZWN0aW9uIDMuICBBbSBJIG1pc3NpbmcNCj4gc29tZXRo aW5nPw0KPg0KDQpObywgSSBkb24ndCB0aGluayB5b3UgYXJlIG1pc3Npbmcgc29tZXRoaW5nLiBU aGUgaWRlYSBpcyB0aGF0IGEgcGVlciBQIA0KcmVxdWVzdGluZyBjaHVua3MgZnJvbSBwZWVyIFEg d2lsbCBsb29rIGZvciBhbm90aGVyIHBlZXIgUiB3aGVuIFEgDQpkb2Vzbid0IHNlbmQgY2h1bmtz LCBhbmQgUSBkaWRuJ3Qgc2VuZCBhIENIT0tFIHRvIGFubm91bmNlIHRoZSBmYWN0IGl0IA0Kd291 bGRuJ3QgYmUgcmVzcG9uZGluZy4gUCBzaG91bGQgdGFrZSBpbnRvIGFjY291bnQgcGFja2V0IGxv c3MgYW5kIHN3YXJtIA0Kc2l6ZSAoaWYgdGhlcmUgaXMganVzdCAxIG90aGVyIHBlZXIgaW4gdGhl IHN3YXJtLCBkb24ndCBkaXNjb25uZWN0KSwgb2YgDQpjb3Vyc2UuIElmIFAgaXMgbm90IGdldHRp bmcgY2h1bmtzIGZyb20gUSBpdCBtb3ZlcyBvbi4NCg0KDQo+ID09IFBhZ2UgMTMsIFNlY3Rpb24g My4xMC4yID09DQo+DQo+IEkgaGF2ZSBhIGNvdXBsZSBvZiBkb3VidHMgYWJvdXQgdGhpcw0KPg0K PiAgICAgKiBUaGlzIHN1cHBvc2VzIHRoYXQgQSBjYW4gc2VuZCBtZXNzYWdlcyB0byBCLg0KPg0K PiAgICAgICBzbyB0aGlzIHNob3VsZCBub3QgYmUgYSBwcm9ibGVtLiBXb3VsZCBpdCBiZSB3b3J0 aCBhZGRpbmcgYQ0KPiBzZW50ZW5jZSB0byBlbXBoYXNpemUgdGhpcyBwb2ludD8gKGUuZy4gIk5v dGUgdGhhdCBBIGNhbiBzZW5kIGENCj4gbWVzc2FnZSB0byBCIHNpbmNlIGJ5IDMuMTAuMSBBIG11 c3QgaGF2ZSBleGNoYW5nZWQgbWVzc2FnZXMgd2l0aCBDLi4uIg0KDQpTdXJlLg0KDQoNCj4gICAg KiBXaXRoIHRoaXMgbW9kZWwgb2YgaG9sZSBwdW5jaGluZywgdGhlIHBlZXIgY2FuIG9ubHkgY29u bmVjdA0KPiBpbml0aWFsbHkgdG8gcGVlcnMgd2l0aCBwdWJsaWMgSVA7IGluIHBhcnRpY3VsYXIs IHRoZSBhZGRyZXNzZXMNCj4gcHJvdmlkZWQgYnkgdGhlIHRyYWNrZXIgbXVzdCBiZSBwdWJsaWMg SVBzLiAgQW0gSSByaWdodD8NCj4NCg0KWWVzLg0KDQoNCj4gPT0gUGFnZSAxNiwgbGFzdCBwYXJh Z3JhcGggb2YgU2VjdGlvbiA0LjMuMSA9PQ0KPg0KPiAgICAgIEltcGxlbWVudGF0aW9uIG5vdGU6 DQo+ICAgICAgICAgIFRvIHJlY29yZCB3aGljaCBjaHVua3MgLi4uIGRpc2N1c3NlZCBpbiBkZXRh aWwgaW4gW0JJTk1BUF0NCj4NCg0KWW91IGFyZSByaWdodC4NCg0KDQo+ID09IFBhZ2UgMTYsIFNl Y3Rpb24gNC4zLjIgPT0NCj4NCj4gQW5vdGhlciBzdHlsaXN0aWMgZGV0YWlsLiAgSXQgaXMgc2Fp ZCB0aGF0ICIuLi5hbiBpbXBsZW1lbnRhdGlvbiBNQVkNCj4gY2hvb3NlIHRvIHVzZSBBQ0sgbWVz c2FnZXMuLi4iIHRoYW4gbGF0ZXIgIldoZW4gYSByZWNlaXZpbmcgcGVlciBoYXMNCj4gc3VjY2Vz c2Z1bGx5IGNoZWNrZWQgLi4uIGl0IE1VU1Qgc2VuZCBhbiBBQ0sgbWVzc2FnZS4uLiIuDQoNCldp bGwgYmUgY29ycmVjdGVkLg0KDQoNCj4gPT0gVG9wIG9mIFBhZ2UgMTcsIFNlY3Rpb24gNC40ID09 DQo+DQo+ICAgICAiV2hlbiBhIHJhbmdlIHRyYW5zbGF0ZXMgdG8gbXVsdGlwbGUgYmlucywgdGhl IGJ5dGUtcmFuZ2UgcGVlciB0aGUNCj4gYnl0ZS1yYW5nZSBwZWVyIHNob3VsZCBzZW5kIG11bHRp cGxlIGUuZy4gSEFWRSBtZXNzYWdlLiINCj4NCj4gVGhpcyBzZW50ZW5jZSBsb29rcyBhIGJpdCBn YXJibGVkLCBhdCB0aGUgdmVyeSBsZWFzdCAidGhlIGJ5dGUtcmFuZ2UNCj4gcGVlciIgaXMgcmVw ZWF0ZWQgdHdpY2UuDQo+DQoNCldpbGwgYmUgY29ycmVjdGVkLg0KDQoNCj4gPT0gUGFnZSAyMCwg U2VjdGlvbiA1LjMgPT0NCj4NCj4gICAgICJUaGUgaGFzaGVzIG5lY2Vzc2FyeSB0byB2ZXJpZnkg YSBjaHVuayBhcmUgaW4gcHJpbmNpcGxlIGl0cw0KPiBzaWJsaW5nJ3MgaGFzaCBhbmQgYWxsIGl0 cyB1bmNsZSBoYXNoZXMgLi4uIGNhbiBiZSBvcHRpbWl6ZWQgIg0KPg0KPiBJZiBJIHVuZGVyc3Rh bmQgY29ycmVjdGx5LCB0aGlzIG9wdGltaXphdGlvbiByZXF1aXJlcyB0aGF0IGEgcGVlciBNVVNU DQo+IHNhdmUgYW5kIHByZXNlcnZlIGFsbCB0aGUgcmVjZWl2ZWQgaGFzaGVzLg0KDQpZZXMuIFRo ZSByZXF1aXJlbWVudCB0aGF0IGEgc2VuZGVyIG11c3QgYmUgYWJsZSB0byBwcm92aWRlIHRoZXNl IGhhc2hlcyANCmltcGxpZXMgdGhhdCB5b3Ugc2hvdWxkIHJlY29yZCB0aGVtLiBJJ2xsIGV4cGxp Y2l0bHkgYWRkIHRoZSBjb25jbHVzaW9uIA0KdGhhdCB0aGlzIG1lYW5zIHlvdSBNVVNUIHJlY29y ZCB0aGVtLCAqaWYqIHlvdSBwbGFuIHRvIGFubm91bmNlIHlvdSBoYXZlIA0KdGhlbSB0byBvdGhl cnMuDQoNCkluIG90aGVyIHdvcmRzLCBsaW1pdGVkIGRldmljZXMgY2FuIGNpcmN1bWVudCB0aGlz IHJlcXVpcmVtZW50IGJ5IG5vdCANCnNlbmRpbmcgSEFWRXMgdG8gb3RoZXJzIGFmdGVyIHRoZXkg cmVjZWl2ZWQgYSBjaHVuay4gSGVuY2UgdGhleSBhcmUgbm90IA0KYW5ub3VuY2luZyB0aGUgYXZh aWxhYmlsaXR5IGFuZCBhcmUgbm90IHJlcXVpcmVkIHRvIHByb3ZpZGUgdGhlbS4gTm90IA0Kc2Vu ZGluZyBIQVZFcyBpcyBhbGxvd2VkIGJ5IHRoZSBwcm90b2NvbC4gTm90ZSwgaG93ZXZlciwgdGhh dCB0aGlzIGRvZXMgDQpyZXF1aXJlIHRoYXQgdGhlIGltcGxlbWVudGF0aW9uIHVzZXMgYSByZWNp cHJvY2l0eSBwb2xpY3kgdGhhdCBhbGxvd3MgDQp0aGlzIGJlaGF2aW91ciwgYXMgdGhlIGxpbWl0 ZWQgZGV2aWNlcyBhcmUgYWN0dWFsbHkgZnJlZXJpZGluZy4NCg0KDQo+ID09IFBhZ2UgMjksIFNl Y3Rpb24gOC4yLiAiVmVyc2lvbiBvcHRpb24iID09DQo+DQo+IE1heWJlIHRoaXMgaXMgdGhpbmtp bmcgYSBiaXQgaW4gYWR2YW5jZSwgYnV0IHdoYXQgc2hvdWxkIGEgcGVlciBzZXQgYXMNCj4gdmVy c2lvbiB2YWx1ZSB3aGVuIHRoZSBwZWVyIGlzIGFibGUgdG8gInNwZWFrIiBtb3JlIHRoYW4gb25l IHByb3RvY29sDQo+IHZlcnNpb24/DQoNCkRvIHlvdSBoYXZlIHBvaW50ZXJzIHRvIHByb3RvY29s cyB3aGVyZSB0aGlzIG1lY2hhbmlzbSBpcyB1c2VkPyBUaGlzIA0KY291bGQgc2F2ZSBhIGZldyBy b3VuZHRyaXBzIG9mIEhBTkRTSEFLRSBtZXNzYWdlcywgc28gZ29vZCBmb3IgDQp0aW1lLXRpbGwt cGxheWJhY2sgaWYgdGhlcmUgYXJlIGluZGVlZCBzZXZlcmFsIGluY29tcGF0aWJsZSB2ZXJzaW9u cywgDQp3aGljaCBJIGhvcGUgdGhlcmUgd2lsbCBub3QgYmUgO28pDQoNCg0KPiA9PSBQYWdlIDM0 LCBTZWN0aW9uIDkuMy4gQ2hhbm5lbHMgPT0NCj4NCj4gSXQgaXMgc2FpZCB0aGF0DQo+DQo+ICAg ICAiLi4uIFBQU1BQLW92ZXItVURQIHVzZXMgYSBtdWx0aXBsZXhpbmcgc2NoZW1lLCBjYWxsZWQg ImNoYW5uZWxzIi4uLiINCj4NCj4gTGF0ZXIgaXQgaXMgc2FpZCB0aGF0DQo+DQo+ICAgICAiV2hl biBjaGFubmVscyBhcmUgdXNlZC4uLiINCj4NCj4gTXkgZG91YnQgaXM6IGlzIHRoZSB1c2Ugb2Yg Y2hhbm5lbHMgbWFuZGF0b3J5IHdpdGggVURQPyAgSWYgeWVzLCB0aGUNCj4gaHlwb3RoZXNpcyAi d2hlbiBjaGFubmVscyBhcmUgdXNlZC4uLiIgaXMgcmVkdW5kYW50Ow0KDQpZZXMgaXQgaXMgbWFu ZGF0b3J5LiBQYXJkb24gbWUgaWYgSSdtIHdyb25nLCBidXQgeW91ciBwb2ludCBtYXkganVzdCBi ZSANCmdyYW1tYXRpY2FsLCAiV2hlbiBYIiBpbiBFbmdsaXNoIGltcGxpZXMgdGhhdCBYIHdpbGwg YmUgdGhlIGNhc2UgYXQgc29tZSANCnBvaW50LiBTbyB5b3Ugc2F5ICJXaGVuIEkgZGllIiBub3Qg IklmIEkgZGllIiwgYnV0IEknbSBub3QgYSBuYXRpdmUgDQpzcGVha2VyIG15c2VsZi4gSSdsbCBt YWtlIGl0IGNsZWFyZXIuDQoNCg0KPiA9PSBQYWdlIDQyLCBTZWN0aW9uIDEzLjIuMi4gPT0NCj4N Cj4gVGhpcyBzZWN0aW9uIGlzIGFib3V0IHVzaW5nIHRoZSB0cmFja2VyIGFzIGNlcnRpZmljYXRp b24gYXV0aG9yaXR5Lg0KPiBJdCBpcyBzYWlkDQo+DQo+ICAgICAiVXBvbiByZWNlaXB0LCB0aGUg dHJhY2tlciBjcmVhdGVzIGEgbWVtYmVyc2hpcCBjZXJ0aWZpY2F0ZSBmcm9tDQo+IHRoZSByZXF1 ZXN0IHdpdGggc3dhcm0gSUQgUywgYSB0aW1lc3RhbXAgVCBhbmQgdGhlIGV4dGVybmFsIElQIGFu ZA0KPiBwb3J0IGl0IHJlY2VpdmVkIHRoZSBtZXNzYWdlIGZyb20uLi4iDQo+DQo+IEFtIEkgd3Jv bmcsIG9yIHRoaXMgc2NoZW1lIGNvdWxkIGZhaWwgaWYgdGhlIHBlZXIgaXMgYmVoaW5kIGENCj4g c3ltbWV0cmljIE5BVD8gIFdvdWxkIGl0IGJlIHdvcnRoIHRvIGFkZCBhdCBsZWFzdCBhIG5vdGUg YWJvdXQgdGhpcz8NCj4NCg0KWW91IGFyZSByaWdodCwgYnV0IHRoYXQgcHJvYmxlbSBhcHBsaWVz IGZvciBhbnkgdHJhY2tlciByZWdpc3RyYXRpb24uDQpJJ2xsIGFkZCBhIG5vdGUuDQoNCkNVLA0K ICAgICBBcm5vDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcHBzcA== ------=_001_NextPart132753443508_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Arno, Riccardo,
    Please see inline.
 
BR
Yunfei
 
zhangyunfei
 
From: Arno Bakker
Date: 2012-11-21 20:49
To: ppsp@ietf.org
Subject: Re: [ppsp] peer protocol in WG last=20 call
Hi Riccardo
 
thanks for the in-depth review! Please = see inline.
 
On 19/11/2012 11:45, Riccardo Bernardini wro= te:
>
> First, the easy stuff.  Some = typos:
>
 
Will be corrected.
 
 
> Now to the "consistent" stuff:
>
> =3D=3D Page 9, Section 2.3 =3D=3D<= /DIV>
>      "If A crashes = ungracefully, peers should remove A from the= ir peer
> list when they detect it no l= onger send messages."
>
> How much is "too much"?  Shou= ld we leave the peer free
> to decide or should we give a= t least some guidelines?
>
 
Your proposal makes sense, I'm just not=  sure what is customary in RFCs.
Should this go in this draft or in=  the planned usage guide?
Chairs?
 
[Yunfei] I think Riccardo's suggestion makes= sense.=20 It's better to have some
metrics to judge this in both protocol speci= fication=20 and usage guide.
 
 
> Also, there is the problem that&nb= sp;when A crashes it remains registered
> with the tracker, although maybe t= his is not a problem directly
> related with PPSPP.
>
 
This is addressed in the current base&n= bsp;tracker proposal. A peer needs to 
periodically refresh its registration to sta= y tracked.
 
 
> =3D=3D Page 10, Section 3 =3D=3D
>
>     It is said that = ;"absence of any response indicates and erro= r" and
> that "Invalid messages are discarded,&n= bsp;and further communication with
> the peer SHOULD be stopped."
>
> Isn't this criterion a bit too&nbs= p;strong?  If a request is lost (e.g.,<= /DIV>
> because of congestion), the sender = ;will interpret the absence of
> response as an error or a bad=  peer.  Also, how long should a pe= er wait
> for declaring absence of response? = ; Should we give guidelines?
>
 
We could give guidelines, but again, I'= m not sure that is customary. I 
assume implementers apply common sense and,&= nbsp;for example, not declare a 
peer dead after 1 packet loss over = ;an unreliable transport. Invalid 
messages mean that there is really some= thing wrong and that sender and 
receiver don't understand eachother, so then=  the receiver really should 
stop the interaction.
 
 
> =3D=3D Page 12, Section 3.9. =3D= =3D
>
> It is said "The CHOKE and UNC= HOKE messages are informational as a peer
> is not required to respond to = ;REQUESTs."  However, if I understand
> correctly, if a peer does not = ;respond to REQUESTs, the peer will be
> banned, according to the criterion = ;in Section 3.  Am I missing
> something?
>
 
No, I don't think you are missing = something. The idea is that a peer P&nb= sp;
requesting chunks from peer Q will look=  for another peer R when Q 
doesn't send chunks, and Q didn't send&= nbsp;a CHOKE to announce the fact it 
wouldn't be responding. P should take i= nto account packet loss and swarm 
size (if there is just 1 other pee= r in the swarm, don't disconnect), of <= /DIV>
course. If P is not getting chunks = ;from Q it moves on.
 
 
> =3D=3D Page 13, Section 3.10.2 =3D= =3D
>
> I have a couple of doubts abo= ut this
>
>     * This supposes that=  A can send messages to B.
>
>       so this shoul= d not be a problem. Would it be wo= rth adding a
> sentence to emphasize this point? = (e.g. "Note that A can send a
> message to B since by 3.10.1 = A must have exchanged messages with C..."
 
Sure.
 
 
>    * With this model of&= nbsp;hole punching, the peer can only connec= t
> initially to peers with public IP;=  in particular, the addresses
> provided by the tracker must be&nb= sp;public IPs.  Am I right?
>
 
Yes.
 
 
> =3D=3D Page 16, last paragraph of&= nbsp;Section 4.3.1 =3D=3D
>
>      Implementation note:
>          To&nb= sp;record which chunks ... discussed in deta= il in [BINMAP]
>
 
You are right.
 
 
> =3D=3D Page 16, Section 4.3.2 =3D= =3D
>
> Another stylistic detail.  It is&n= bsp;said that "...an implementation MAY
> choose to use ACK messages..." tha= n later "When a receiving peer has
> successfully checked ... it MUST s= end an ACK message...".
 
Will be corrected.
 
 
> =3D=3D Top of Page 17, Section&nbs= p;4.4 =3D=3D
>
>     "When a range transl= ates to multiple bins, the byte-range peer&n= bsp;the
> byte-range peer should send multiple&nb= sp;e.g. HAVE message."
>
> This sentence looks a bit garbled,=  at the very least "the byte-range
> peer" is repeated twice.
>
 
Will be corrected.
 
 
> =3D=3D Page 20, Section 5.3 =3D=3D=
>
>     "The hashes necessary&nbs= p;to verify a chunk are in principle it= s
> sibling's hash and all its uncle&n= bsp;hashes ... can be optimized "
>
> If I understand correctly, this op= timization requires that a peer MUST
> save and preserve all the received=  hashes.
 
Yes. The requirement that a sender must=  be able to provide these hashes 
implies that you should record them. I'= ll explicitly add the conclusion 
that this means you MUST record them,&n= bsp;*if* you plan to announce you have =
them to others.
 
In other words, limited devices can cir= cument this requirement by not 
sending HAVEs to others after they rece= ived a chunk. Hence they are not 
announcing the availability and are not = ;required to provide them. Not 
sending HAVEs is allowed by the protoco= l. Note, however, that this does 
require that the implementation uses a = reciprocity policy that allows 
this behaviour, as the limited devices = are actually freeriding.
 
 
> =3D=3D Page 29, Section 8.2. "Vers= ion option" =3D=3D
>
> Maybe this is thinking a bit = in advance, but what should a peer set&= nbsp;as
> version value when the peer is&nbs= p;able to "speak" more than one protocol
> version?
 
Do you have pointers to protocols where=  this mechanism is used? This 
could save a few roundtrips of HANDSHAK= E messages, so good for 
time-till-playback if there are indeed sever= al incompatible versions, 
which I hope there will not be ;o)=
 
 
> =3D=3D Page 34, Section 9.3. Chann= els =3D=3D
>
> It is said that
>
>     "... PPSPP-over-UDP uses&= nbsp;a multiplexing scheme, called "channels"..."
>
> Later it is said that
>
>     "When channels are u= sed..."
>
> My doubt is: is the use of&nb= sp;channels mandatory with UDP?  If yes,&nbs= p;the
> hypothesis "when channels are used..."&= nbsp;is redundant;
 
Yes it is mandatory. Pardon me if = I'm wrong, but your point may just be&n= bsp;
grammatical, "When X" in English implies&nbs= p;that X will be the case at some =
point. So you say "When I die" not=  "If I die", but I'm not a native&= nbsp;
speaker myself. I'll make it clearer.
 
 
> =3D=3D Page 42, Section 13.2.2. = =3D=3D
>
> This section is about using the&nb= sp;tracker as certification authority.
> It is said
>
>     "Upon receipt, the t= racker creates a membership certificate from
> the request with swarm ID S, = a timestamp T and the external IP and
> port it received the message from.= .."
>
> Am I wrong, or this scheme co= uld fail if the peer is behind a
> symmetric NAT?  Would it be w= orth to add at least a note about = this?
>
 
You are right, but that problem applies=  for any tracker registration.
I'll add a note.
 
CU,
     Arno
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart132753443508_=------ From riccardo.bernardini@uniud.it Fri Nov 23 09:13:33 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D32521F8471 for ; Fri, 23 Nov 2012 09:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfHXLCyn8Z2R for ; Fri, 23 Nov 2012 09:13:32 -0800 (PST) Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id 4519121F8561 for ; Fri, 23 Nov 2012 09:13:31 -0800 (PST) Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id 6A286B72A49; Fri, 23 Nov 2012 18:13:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at talitha1 Received: from smtp.uniud.it ([158.110.1.136]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10028) with ESMTP id tCz9DPeu7Dtz; Fri, 23 Nov 2012 18:13:28 +0100 (CET) Received: from webmail.uniud.it (webmail2.cc.uniud.it [158.110.1.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uniud.it (Postfix) with ESMTPSA id 65A9FB0035; Fri, 23 Nov 2012 18:13:28 +0100 (CET) Received: from 158.110.27.77 ([158.110.27.77]) by webmail.uniud.it (Horde Framework) with HTTP; Fri, 23 Nov 2012 18:13:28 +0100 Message-ID: <20121123181328.10352avqtdet10oo@webmail.uniud.it> Date: Fri, 23 Nov 2012 18:13:28 +0100 From: Riccardo Bernardini To: arno@cs.vu.nl References: <20121119114547.60502iibxkcnt0bf@webmail.uniud.it> <50ACCDF2.9070402@cs.vu.nl> In-Reply-To: <50ACCDF2.9070402@cs.vu.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) Cc: ppsp@ietf.org Subject: Re: [ppsp] peer protocol in WG last call X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 17:13:33 -0000 Hi Arno, please see inline. Arno Bakker ha scritto: > Hi Riccardo > > thanks for the in-depth review! Please see inline. > > On 19/11/2012 11:45, Riccardo Bernardini wrote: >> >> First, the easy stuff. Some typos: >> > > Will be corrected. > > >> Now to the "consistent" stuff: >> >> == Page 9, Section 2.3 == >> "If A crashes ungracefully, peers should remove A from their peer >> list when they detect it no longer send messages." >> >> How much is "too much"? Should we leave the peer free >> to decide or should we give at least some guidelines? >> > > Your proposal makes sense, I'm just not sure what is customary in RFCs. > Should this go in this draft or in the planned usage guide? > Chairs? > > >> Also, there is the problem that when A crashes it remains registered >> with the tracker, although maybe this is not a problem directly >> related with PPSPP. >> > > This is addressed in the current base tracker proposal. A peer needs > to periodically refresh its registration to stay tracked. > > >> == Page 10, Section 3 == >> >> It is said that "absence of any response indicates and error" and >> that "Invalid messages are discarded, and further communication with >> the peer SHOULD be stopped." >> >> Isn't this criterion a bit too strong? If a request is lost (e.g., >> because of congestion), the sender will interpret the absence of >> response as an error or a bad peer. Also, how long should a peer wait >> for declaring absence of response? Should we give guidelines? >> > > We could give guidelines, but again, I'm not sure that is customary. > I assume implementers apply common sense and, for example, not > declare a peer dead after 1 packet loss over an unreliable > transport. Invalid messages mean that there is really something > wrong and that sender and receiver don't understand eachother, so > then the receiver really should stop the interaction. > > >> == Page 12, Section 3.9. == >> >> It is said "The CHOKE and UNCHOKE messages are informational as a peer >> is not required to respond to REQUESTs." However, if I understand >> correctly, if a peer does not respond to REQUESTs, the peer will be >> banned, according to the criterion in Section 3. Am I missing >> something? >> > > No, I don't think you are missing something. The idea is that a peer > P requesting chunks from peer Q will look for another peer R when Q > doesn't send chunks, and Q didn't send a CHOKE to announce the fact > it wouldn't be responding. P should take into account packet loss > and swarm size (if there is just 1 other peer in the swarm, don't > disconnect), of course. If P is not getting chunks from Q it moves on. > > >> == Page 13, Section 3.10.2 == >> >> I have a couple of doubts about this >> >> * This supposes that A can send messages to B. >> >> so this should not be a problem. Would it be worth adding a >> sentence to emphasize this point? (e.g. "Note that A can send a >> message to B since by 3.10.1 A must have exchanged messages with C..." > > Sure. > > >> * With this model of hole punching, the peer can only connect >> initially to peers with public IP; in particular, the addresses >> provided by the tracker must be public IPs. Am I right? >> > > Yes. > > >> == Page 16, last paragraph of Section 4.3.1 == >> >> Implementation note: >> To record which chunks ... discussed in detail in [BINMAP] >> > > You are right. > > >> == Page 16, Section 4.3.2 == >> >> Another stylistic detail. It is said that "...an implementation MAY >> choose to use ACK messages..." than later "When a receiving peer has >> successfully checked ... it MUST send an ACK message...". > > Will be corrected. > > >> == Top of Page 17, Section 4.4 == >> >> "When a range translates to multiple bins, the byte-range peer the >> byte-range peer should send multiple e.g. HAVE message." >> >> This sentence looks a bit garbled, at the very least "the byte-range >> peer" is repeated twice. >> > > Will be corrected. > > >> == Page 20, Section 5.3 == >> >> "The hashes necessary to verify a chunk are in principle its >> sibling's hash and all its uncle hashes ... can be optimized " >> >> If I understand correctly, this optimization requires that a peer MUST >> save and preserve all the received hashes. > > Yes. The requirement that a sender must be able to provide these > hashes implies that you should record them. I'll explicitly add the > conclusion that this means you MUST record them, *if* you plan to > announce you have them to others. > > In other words, limited devices can circument this requirement by > not sending HAVEs to others after they received a chunk. Hence they > are not announcing the availability and are not required to provide > them. Not sending HAVEs is allowed by the protocol. Note, however, > that this does require that the implementation uses a reciprocity > policy that allows this behaviour, as the limited devices are > actually freeriding. > > >> == Page 29, Section 8.2. "Version option" == >> >> Maybe this is thinking a bit in advance, but what should a peer set as >> version value when the peer is able to "speak" more than one protocol >> version? > > Do you have pointers to protocols where this mechanism is used? This > could save a few roundtrips of HANDSHAKE messages, so good for > time-till-playback if there are indeed several incompatible > versions, which I hope there will not be ;o) [Riccardo] No specific protocol comes to my mind. I checked the RFC 6709 "Design Considerations for Protocol Extensions" (http://tools.ietf.org/html/rfc6709) for hints. In Section 4.1 there is a list of possible solutions for protocol versioning. Should I propose a solution here "on the spot," I would suggest, inspired by the RFC, to make the payload of the version option a string of bytes, one for every supported version. Suppose node A initiates the connection toward node B. Node A puts in the option all the version it supports, B picks a supported version (maybe the largest one?[supposing that later versions are better]) and sends back the HANDSHAKE with a single value in the option field. An alternative solution, where the option payload has a fixed length, could be that A puts the numbers of the oldest and the newest supported version and B picks one version in that interval. > > >> == Page 34, Section 9.3. Channels == >> >> It is said that >> >> "... PPSPP-over-UDP uses a multiplexing scheme, called "channels"..." >> >> Later it is said that >> >> "When channels are used..." >> >> My doubt is: is the use of channels mandatory with UDP? If yes, the >> hypothesis "when channels are used..." is redundant; > > Yes it is mandatory. Pardon me if I'm wrong, but your point may just > be grammatical, "When X" in English implies that X will be the case > at some point. So you say "When I die" not "If I die", but I'm not a > native speaker myself. I'll make it clearer. [Riccardo] I am not a native speaker, either. Maybe some native English speaker could help us here. > > >> == Page 42, Section 13.2.2. == >> >> This section is about using the tracker as certification authority. >> It is said >> >> "Upon receipt, the tracker creates a membership certificate from >> the request with swarm ID S, a timestamp T and the external IP and >> port it received the message from..." >> >> Am I wrong, or this scheme could fail if the peer is behind a >> symmetric NAT? Would it be worth to add at least a note about this? >> > > You are right, but that problem applies for any tracker registration. > I'll add a note. > > CU, > Arno Riccardo > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > -- Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine From a.bakker@vu.nl Thu Nov 29 04:35:32 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D0A21F89F2 for ; Thu, 29 Nov 2012 04:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMF-1-EwWNZ4 for ; Thu, 29 Nov 2012 04:35:18 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id A8D4E21F8933 for ; Thu, 29 Nov 2012 04:35:17 -0800 (PST) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 29 Nov 2012 13:35:15 +0100 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 29 Nov 2012 13:35:15 +0100 Message-ID: <50B756A9.9080400@cs.vu.nl> Date: Thu, 29 Nov 2012 13:35:53 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Riccardo Bernardini References: <20121119114547.60502iibxkcnt0bf@webmail.uniud.it> <50ACCDF2.9070402@cs.vu.nl> <20121123181328.10352avqtdet10oo@webmail.uniud.it> In-Reply-To: <20121123181328.10352avqtdet10oo@webmail.uniud.it> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp@ietf.org Subject: Re: [ppsp] peer protocol in WG last call X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 12:35:32 -0000 Hi Riccardo please see inline: On 23/11/2012 18:13, Riccardo Bernardini wrote: > > [Riccardo] > No specific protocol comes to my mind. I checked the RFC 6709 "Design > Considerations for Protocol Extensions" > (http://tools.ietf.org/html/rfc6709) for hints. In Section 4.1 there > is a list of possible solutions for protocol versioning. [...] > An alternative solution, where the option payload has a fixed length, > could be that A puts the numbers of the oldest and the newest > supported version and B picks one version in that interval. > I like the min/max versioning you propose here. I'll add a protocol option to hold the minimum version supported that is sent on the first HANDSHAKE in addition to the existing optional that will carry the max. The reply handshake will just have the existing version option that will contain the protocol selected by the receiver to use. If no common version is found, a closing HANDSHAKE is sent. I'll update the draft soon to accommodate your and Yunfei's suggestions. CU, Arno From zongning@huawei.com Thu Nov 29 18:40:31 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F1521F892F for ; Thu, 29 Nov 2012 18:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrwvXo5ZfqdP for ; Thu, 29 Nov 2012 18:40:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6705221F8686 for ; Thu, 29 Nov 2012 18:40:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMA73460; Fri, 30 Nov 2012 02:40:29 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Nov 2012 02:40:13 +0000 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Nov 2012 02:40:28 +0000 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.99]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Fri, 30 Nov 2012 10:40:19 +0800 From: Zongning To: stefano previdi , ppsp , zhangyunfei Zhang Thread-Topic: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item Thread-Index: AQHNwOQYkyQQEWjxokuIgJ2/6wYgEZgBvf2Q Date: Fri, 30 Nov 2012 02:40:19 +0000 Message-ID: References: <1388AC0A-2E2E-4EE5-8868-688E7BE6E252@cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 02:40:31 -0000 Hi, I read the draft and support adopting this document as WG item. I also see some next-step work to further improve the draft later on (after= becoming a WG draft). 1) most tutorial text (e.g. 1.1 Use Scenarios, 1.2 Assumptions) could be me= rged to PPSP survey WG draft; 2) if properties listed in Table 4 like upload/download bytes are mandatory= or just examples for STAT_REPORT? If mandatory, why? Why not other propert= ies such as physical link status, online time? I think we need elaborate mo= re on this. It seems the current reference to Table 6 is wrong. 3) I would suggest to briefly describe distributed tracker in error and rec= overy section. I am happy to work with authors on the above issues. -Ning > -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > stefano previdi > Sent: Monday, November 12, 2012 10:43 PM > To: ppsp; zhangyunfei Zhang > Subject: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item >=20 >=20 > All, >=20 > during our our IETF85 PPSP WG meeting, the authors of > draft-cruz-ppsp-base-tracker-protocol-01 requested the adoption > of the document as WG item. >=20 > Please, send your comments (support, non-support, concerns, ...) > to the mailing list not later than November 30, 2012. >=20 > Thanks. > s. >=20 >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp