Re: [ppsp] Selection of PPSP peer protocol draft

Martin Stiemerling <Martin.Stiemerling@neclab.eu> Tue, 29 November 2011 15:25 UTC

Return-Path: <Martin.Stiemerling@neclab.eu>
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 6BA2121F8BE4 for <ppsp@ietfa.amsl.com>; Tue, 29 Nov 2011 07:25:48 -0800 (PST)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsojnXHY9lZ2 for <ppsp@ietfa.amsl.com>; Tue, 29 Nov 2011 07:25:47 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 82BD221F8BF3 for <ppsp@ietf.org>; Tue, 29 Nov 2011 07:25:47 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DCB71280001C4; Tue, 29 Nov 2011 16:25:46 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o7L8yTWo1KP; Tue, 29 Nov 2011 16:25:46 +0100 (CET)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id BDE7F28000085; Tue, 29 Nov 2011 16:25:36 +0100 (CET)
Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 16:25:36 +0100
From: Martin Stiemerling <Martin.Stiemerling@neclab.eu>
To: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
Thread-Topic: [ppsp] Selection of PPSP peer protocol draft
Thread-Index: Acyqtvz2/G1P2VwpQ/iSlUDvVTm3/QDxjzKAAAQ+5IAABuThgA==
Date: Tue, 29 Nov 2011 15:25:36 +0000
Message-ID: <E84E7B8FF3F2314DA16E48EC89AB49F024E913B5@Polydeuces.office.hd>
References: <Acyqtvz2/G1P2VwpQ/iSlUDvVTm3/Q==@huawei.com> <E84E7B8FF3F2314DA16E48EC89AB49F024E8E253@Polydeuces.office.hd> <CAOc996taV+XZ_DOceWw45Y15_dW4S=7wN8fkPRgmd18NgXDbBA@mail.gmail.com> <00ab01ccae96$97f0cd50$c7d267f0$@com>
In-Reply-To: <00ab01ccae96$97f0cd50$c7d267f0$@com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.1.135]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "ppsp@ietf.org" <ppsp@ietf.org>
Subject: Re: [ppsp] Selection of PPSP peer protocol draft
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2011 15:25:48 -0000

[speaking as individual contributor and not as chair of the PPSP WG]

Hi Yingjie, 

> -----Original Message-----
> From: Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]
> Sent: Tuesday, November 29, 2011 1:58 PM
> To: Martin Stiemerling
> Cc: ppsp@ietf.org
> Subject: 答复: [ppsp] Selection of PPSP peer protocol draft
> 
> I would like to recall the history of peer protocol.
> We began to propose Tracker and Peer protocol at early 2010. Since the very
> beginning, we believe that Peer protocol should be consistent with Tracker
> Protocol. By consistence, I don't mean that they can co-exist, instead they
> should share the similar philosophy and should be able to interoperate.  That's
> why we call them a system, not two single protocols.

Aehm, we do not define systems here. We do define protocols. 

Anyhow, there is nothing against having two different sets of core people working on the tracker protocol and the peer protocol. We have the working group which will take care that the both can interact. 

Furthermore:
- the PPSP tracker protocol is optional to the PPSP peer protocol and
- the PPSP peer protocol is optional to the PPSP tracker protocol. 

The peer protocol must be able to operate without the tracker protocol, as an actual implementer of p2p tv system may chose a different way of distributing the information about other peers, e.g., via a DHT or via the regular bittorrent tracker protocol. 

The tracker protocol must be able to operate without the peer protocol, as somebody might chose to use the PPSP tracker protocol with a proprietary peer protocol.

> 
> PPSP had spent a lot of time on discussion on whether the PPSP standards
> should use Tracker-based or Full-mesh architecture (finally, WG got consensus
> on tracker-based), and how the Tracker and Peer protocol should work, which is
> in the Requirements draft. We always regards the requirements draft as a
> guidance on Tracker and peer protocol. Based on the requirements draft, we
> proposed draft-gu-ppsp-tracker-protocol and peer-protocol.

This sounds as your proposal for both protocols is authorative, because your proposal is based on the requirements draft. I would say that any protocol proposal is about to follow the requirements. 

> 
> The WG has spent a lot of effort on PPSP Survey, because we want to extract
> common features on current PPSP system, instead of base on a single private
> protocol.

What is the conclusion??

> 
> I agree that Swift works, and it is a research project supported by many
> research groups, and I think those show support for swift are mostly involved in
> SWIFT project.
> It will be easier for PPSP to get to an RFC published if we defining a protocol
> based on a mature private protocol. But what about other private protocols?
> ANY ONE of the protocols introduced in Survey draft can work well and most of
> them have much huge number of users than SWIFT, and even much better
> performance. Shall we take them into consideration?

Well, we potentially could go and examine all proprietary protocols out there, including the attached IPR and the willingness of the protocol owners to transfer the protocol to the IETF. 

This will keep us busy for another 1 or 2 years without being able to progress the specification of the protocols. 

> 
> I hate to make this selection as an attack on each other draft. And I hope those
> from SWIFT won't look at my email as an attack to their protocols. I just wonder
> what does PPSP WG want, a mature private protocol or a developing protocols
> based on widely survey?

The WG must do the selection based on technical arguments. It is not about attacking the other drafts, but to find out what is the best technical solution. 

And technically speaking, your peer protocol draft lacks a lot of details, as compared to the swift draft. 

However, to repeat this again:
If there are features in your protocol draft which are missing in the swift proposal, write them up and post them to the list. 

  Martin

martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014