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

Hi Ning,

-----邮件原件-----
发件人: Zongning 
发送时间: 2013年7月31日 20:25
收件人: Huangyihong (Rachel); arno@cs.vu.nl
抄送: ppsp@ietf.org
主题: RE: [ppsp] 答复: FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

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.

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

[Rachel]: yep, not mobility issues. It's just about the updated information of peer should be notified to the tracker. It seems the base tracker protocol already has the ability to do such thing. So I'm okay to remove this issue out of the extended tracker protocol.

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