Re: [ppsp] Fw: RE: New draft for usage of PPSP

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Fri, 04 July 2014 07:23 UTC

Return-Path: <rachel.huang@huawei.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3792F1B278A for <ppsp@ietfa.amsl.com>; Fri, 4 Jul 2014 00:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vnr874QMtB8 for <ppsp@ietfa.amsl.com>; Fri, 4 Jul 2014 00:23:27 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CB41B2C29 for <ppsp@ietf.org>; Fri, 4 Jul 2014 00:23:26 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU04839; Fri, 04 Jul 2014 07:23:24 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 08:23:24 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 15:23:18 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: Di Wu <diwu2@seas.upenn.edu>, Fei Song <fsong@bjtu.edu.cn>, PPSP <ppsp@ietf.org>
Thread-Topic: Fw: RE: [ppsp] New draft for usage of PPSP
Thread-Index: AQHPly85Y6Q1cnqzF0exT9tQigkR9JuPZ1Sw//+NqACAAIldAA==
Date: Fri, 04 Jul 2014 07:23:17 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB861E981E@nkgeml501-mbs.china.huawei.com>
References: <201407031731421187028@bjtu.edu.cn> <eefda5baa5c5c3c3c9d1e5b9262a6622@seas.upenn.edu> <51E6A56BD6A85142B9D172C87FC3ABBB861E97AB@nkgeml501-mbs.china.huawei.com> <28131bc31a9fb0e6454557323ab6f438@seas.upenn.edu>
In-Reply-To: <28131bc31a9fb0e6454557323ab6f438@seas.upenn.edu>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.144]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ppsp/IZPjO2aoUqPYdiSv4Ky2YmHVMLI
Subject: Re: [ppsp] Fw: RE: New draft for usage of PPSP
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 04 Jul 2014 07:23:28 -0000

Hi Di Wu,

I take out the parts we agree on. Please see Inline.

BR,
Rachel
> >> > As for issue 6, I'm not sure that PPSP system should provide
> >> > message to change its PeerMode when the peer gets the whole
> >> > content. If it wants to become SEED, it can leave the swarm and
> >> > join the swarm again as SEED.
> >> As for issue 6, we think PPSP system should consider it to provided a
> >> better service for peers.
> > [Rachel]: Sure. I'm just explaining that base protocol could do it in
> > another way. Some peers may not want to share their content when they
> > finish downloading. If the ppsp system change it automatically. It
> > will be against those people's will. Let's see what WG thinks of it.
> >
> Yeah, you are right. But the way you illustrated is a little bit complex. That's
> why we put it into the limitation and gaps part. And as you explained below, the
> PeerMode usually used when a peer firstly connected to the tracker. Once they
> login to ppsp system and finished data transmission, the PeerMode may not
> represent their status. We are hoping to provide a simple way to solve this
> problem, which not defends peer's willing. For example, peers may change
> their PeerMode once they gets the whole content and are willing to share it
> with others via STAT_REPORT message. While another option is that PPSP
> system change it automatically (Just as you mentioned). For those people who
> are not willing to share the content, they could send CHONKE message to
> express their willing.
> 
[Rachel] It's a implementation v.s. protocol issue. IMO, we don't have to complex the protocol in order to simplify the implementation. So I think my option and your last option is acceptable, while the option to change STAT_REPORT is unnecessary.