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

Hi, Cruz.

Please see inline.

________________________________
From: Rui Cruz [rui.cruz@ieee-pt.org]
Sent: Wednesday, July 31, 2013 8:42 PM
To: Zongning
Cc: Rui Cruz; Huangyihong (Rachel); arno@cs.vu.nl; ppsp@ietf.org
Subject: Re: [ppsp] 答复: FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

Please read inline.

Regards,
Rui Cruz

On 31/07/2013, at 13:25, Zongning <zongning@huawei.com<mailto:zongning@huawei.com>> wrote:

Hi, Rachel and Arno,

Please see inline.

________________________________________
From: ppsp-bounces@ietf.org<mailto:ppsp-bounces@ietf.org> [ppsp-bounces@ietf.org<mailto:ppsp-bounces@ietf.org>] on behalf of Huangyihong (Rachel) [rachel.huang@huawei.com<mailto:rachel.huang@huawei.com>]
Sent: Tuesday, July 30, 2013 9:49 PM
To: arno@cs.vu.nl<mailto:arno@cs.vu.nl>
Cc: ppsp@ietf.org<mailto:ppsp@ietf.org>
Subject: [ppsp] 答复:  FW: New Version Notification       for draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi Arno,

Please see inline.

Best regards,
Rachel

-----邮件原件-----
发件人: Arno Bakker [mailto:arno@cs.vu.nl<mailto:arno@cs.vu.nl>]
发送时间: 2013年7月30日 19:31
收件人: Huangyihong (Rachel)
抄送: ppsp@ietf.org<mailto:ppsp@ietf.org>
主题: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi Rachel and all

please see inline.

On 30/07/2013 12:43, Huangyihong (Rachel) wrote:

"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.

I may have been misreading the base protocol spec for a long time then.
Table 8 of the base protocol indeed does not list that a "CONNECT action=join" while in tracking state is a valid transition. IMHO, I think it should for both LEECH and SEED, retrieving a new set of peers for the swarm you are in is basic functionality. Or FIND must be moved into the base protocol spec.

[Rachel]: All right. Let's see how it works in the meeting.

[ZONG]: If I recall correctly, we decided to keep base track protocol simple - the reason we have extended tracker protocol. So we have a basic and small set of functionalities for CONNECT and define other functions in other messages. I tend to keep FIND with functions such as peer list update in extended draft then.

[CRUZ] I fully agree with Zong. The Base Tracker Protocol was agreed in consensus to be simple, and that other functionalities would be expressed in extended versions.

"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?

There are many IETF drafts to deal with IP-address change, and IMHO there is no need to add another one here.

[Rachel]: I think this case is similar to the first case, because first case is about getting the update information from the tracker to peer, and this one is about providing the updated information of the peer to the tracker. So the conclusion made to the first case could also apply to this case.

[ZONG]: I guess what Arno mentioned is that current IETF MIP mechanisms handle IP address change while keeping session untouched. I agree that tracker protocol should not re-invent new MIP tech. :)) I think what Rachel stated is about notifying new IP address to tracker using tracker protocol, which is not handle mobility issues, right?

[CRUZ] The obvious method relies on the STAT_REPORT request, that is issued periodically or whenever required. When receiving such message from a Registered Peer already tracked in one or more swarms, the tracker updates the public IP address seen from the requesting peer.

[ZONG]: So I assuming that you are agree with me - we only handle IP address update report, rather than dealing with IP mobility issues, right? :))

CU,
    Arno
_______________________________________________
ppsp mailing list
ppsp@ietf.org<mailto:ppsp@ietf.org>
https://www.ietf.org/mailman/listinfo/ppsp
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp