Re: [ppsp] 答复: Selection of PPSP peer protocol draft

Martin Stiemerling <Martin.Stiemerling@neclab.eu> Tue, 29 November 2011 15:38 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 CB90621F87E2 for <ppsp@ietfa.amsl.com>; Tue, 29 Nov 2011 07:38:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.917
X-Spam-Level:
X-Spam-Status: No, score=-97.917 tagged_above=-999 required=5 tests=[AWL=-4.681, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_GB2312=1.345, 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 pbvqjfwetzwK for <ppsp@ietfa.amsl.com>; Tue, 29 Nov 2011 07:38:33 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B86EA21F86EE for <ppsp@ietf.org>; Tue, 29 Nov 2011 07:38:32 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0B13128000085; Tue, 29 Nov 2011 16:38:32 +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 47xxb0h58B5P; Tue, 29 Nov 2011 16:38:31 +0100 (CET)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id E1D96280001C4; Tue, 29 Nov 2011 16:38:16 +0100 (CET)
Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 16:38:16 +0100
From: Martin Stiemerling <Martin.Stiemerling@neclab.eu>
To: "Y. R. Yang" <yry@cs.yale.edu>, "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
Thread-Topic: [ppsp] 答复: Selection of PPSP peer protocol draft
Thread-Index: AQHMrqAZ0KHyHFg8m0q6bH/lt1gcJ5XD+61g
Date: Tue, 29 Nov 2011 15:38:15 +0000
Message-ID: <E84E7B8FF3F2314DA16E48EC89AB49F024E9141D@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> <16E4764B-EADF-4289-BA61-9A417B1DAF70@cs.yale.edu>
In-Reply-To: <16E4764B-EADF-4289-BA61-9A417B1DAF70@cs.yale.edu>
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="gb2312"
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:38:34 -0000

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


> -----Original Message-----
> From: Y. R. Yang [mailto:yry@cs.yale.edu]
> Sent: Tuesday, November 29, 2011 3:08 PM
> To: Yingjie Gu(yingjie)
> Cc: Martin Stiemerling; ppsp@ietf.org
> Subject: Re: [ppsp] 答复: Selection of PPSP peer protocol draft
> 
> 
> 
> On Nov 29, 2011, at 7:58 AM, "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
> wrote:
> 
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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?
> >
> > 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?
> 
> I would like to second Yingjie's question. It is important to discuss the objective
> first. There are indeed other options, e.g., based on reverse engineering, ppsp
> could use as a base one of those extremely widely deployed (with tens of
> millions of real users) protocols, as long as there is no IP issue.

This will effectively postpone the PPSP peer protocol until infinity. 

We have agreed in the WG to make a decision for a peer protocol around the IETF-82 meeting, based on the proposals available at this time. 

> 
> Protocol design is not an optimization problem, i.e., pick the optimal protocol.
> So what is the goal of ppsp? If time is the essence and the goal is to have a peer
> protocol coming out of IETF quickly, then swift can be a starting base.

I personally want a protocol that I can implement in the next 12 months. And swift makes me feel that I will be able to do this. When reading draft-gu-ppsp-peer... I'm, not sure that I will be able to implement this in the next 12 months. For instance, where is the start of the state machine in the draft??

  Martin

> Tanenbaum talked about the timing of standardization based on a camel shape.
> I feel that p2p streaming is already at the lower half of the body, i.e., many
> commercial protocols already exist. I am wondering on the opinions of the
> chairs and other seasoned IETFs on an approach that PPSP could take, to make
> a difference. I understand that many want to discuss the specific technical
> details, but then I see endless debates.
> 
> Thanks!
> 
> Richard
> 
> >
> > I agree with Cruz's opinion. This is not a selection of draft, we have more than
> one option.
> >
> >
> >
> >
> >
> > Best Regards
> > Gu Yingjie
> >
> > _______________________________________________
> > ppsp mailing list
> > ppsp@ietf.org
> > https://www.ietf.org/mailman/listinfo/ppsp

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