IETF Logo Mail Archive

Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Tue, 30 July 2013 10:44 UTC

Return-Path: <rachel.huang@huawei.com>
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 18BEF21E8056 for <ppsp@ietfa.amsl.com>; Tue, 30 Jul 2013 03:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[AWL=-2.146, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
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 R6yH6N4tKQlP for <ppsp@ietfa.amsl.com>; Tue, 30 Jul 2013 03:44:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0C49B21E8084 for <ppsp@ietf.org>; Tue, 30 Jul 2013 03:44:07 -0700 (PDT)
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 AVO31582; Tue, 30 Jul 2013 10:44:01 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 11:43:51 +0100
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 11:43:58 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Tue, 30 Jul 2013 18:43:51 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: "arno@cs.vu.nl" <arno@cs.vu.nl>, "ppsp@ietf.org" <ppsp@ietf.org>
Thread-Topic: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt
Thread-Index: AQHOjQSU3nuf+AK/R0eACq2dSsOfPJl9BM4w
Date: Tue, 30 Jul 2013 10:43:51 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4585ACAC@nkgeml501-mbs.china.huawei.com>
References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <51F78163.8050605@cs.vu.nl>
In-Reply-To: <51F78163.8050605@cs.vu.nl>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.168.91]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt
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, 30 Jul 2013 10:44:14 -0000

Hi Arno,

Thanks for your comments. Please see my reply inline.

-----邮件原件-----
发件人: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] 代表 Arno Bakker
发送时间: 2013年7月30日 17:04
收件人: ppsp@ietf.org
主题: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi all

I have some comments on the extended tracker protocol's motivation. The draft lists 4 use cases that the base protocol "may not be able to deal with".

"1. The peer list of a specific swarm obtained by a peer may be out of date":

	I always assumed that when the initial peer list received via
	the base protocol is outdated, a peer would send a new CONNECT
	message with a PeerNum attribute to get a new list. So why is
	extra support needed?

[Rachel]: I think the peer should first disconnect from the swarm, and then send a new CONNECT message to get a new list. Actually, I think this procedure is more complicated than having a new message ( in this spec, we define a new message FIND) to deal with it.

"2. A peer may have the requirement to inform the tracker its new network address when the peer has changed its primary network attachment."

	a) Isn't this the role of mobile IP? and b) can't the base 	
	CONNECT handle this?

[Rachel]: I think this case is talking about the peer switches its network address during the streaming. For example, a peer is firstly using WIFI to connect to the tracker. But during the streaming, the WIFI has problem and the peer decides to switch to a wired network but it doesn't want to stop the streaming. Actually, I think the base CONNECT can't handle it. Because it can't "CONNECT" to the same swarm twice, right? 

It seems most of the spec is actually about finding peers based on what content they have and not these two specific use cases, so perhaps they can be removed?

[Rachel]: No. It's not just about finding peers based on content. As I explained above, base CONNECT can't deal with these two case, that's why new message FIND is required.

Regards,
      Arno

_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

v2.23.0 | Report a Bug | By Email