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> wrote:

> Hi, Rachel and Arno,
> 
> Please see inline.
> 
> ________________________________________
> From: ppsp-bounces@ietf.org [ppsp-bounces@ietf.org] on behalf of Huangyihong (Rachel) [rachel.huang@huawei.com]
> Sent: Tuesday, July 30, 2013 9:49 PM
> To: arno@cs.vu.nl
> Cc: 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]
> 发送时间: 2013年7月30日 19:31
> 收件人: Huangyihong (Rachel)
> 抄送: 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.

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