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

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 11 Jul 2013 01:45:39 +0000

Dear all,

We have just submitted a new version of draft-huang-ppsp-extended-tracker-protocol. This update is just some editorial changes. No significant modification. Comments are highly appreciated. 

Best regards,
Rachel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 9:29 AM
To: Mario Serafim Nunes; Rui Santos Cruz; Rui Sant Cruz; Zongning; Mario Sera Nunes; Huangyihong (Rachel); Joao P. Taveira
Subject: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

A new version of I-D, draft-huang-ppsp-extended-tracker-protocol-03.txt
has been successfully submitted by Rachel Huang and posted to the
IETF repository.

Filename:	 draft-huang-ppsp-extended-tracker-protocol
Revision:	 03
Title:		 PPSP Tracker Protocol--Extended Protocol
Creation date:	 2013-07-11
Group:		 Individual Submission
Number of pages: 26
URL:             http://www.ietf.org/internet-drafts/draft-huang-ppsp-extended-tracker-protocol-03.txt
Status:          http://datatracker.ietf.org/doc/draft-huang-ppsp-extended-tracker-protocol
Htmlized:        http://tools.ietf.org/html/draft-huang-ppsp-extended-tracker-protocol-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-huang-ppsp-extended-tracker-protocol-03

Abstract:
This document specifies an extended Peer-to-Peer Streaming Protocol -
Tracker Protocol, which is a new extension protocol complementing the
basic core messages and usages specified in the base tracker protocol
for the exchange of meta information between trackers and peers, such as
initial offer/request of participation in multimedia content streaming,
content information, peer lists and reports of activity and status. It
extends the base tracker protocol to include new optional messages
providing new usages in the communications between peer and tracker. The
extension protocol is retro-compatible with the base tracker protocol.

The IETF Secretariat

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Thu, 11 Jul 2013 18:04:55 +0800

Hi Rachel,

I found some inconsistencies in the new revision as follows for you to
consider: 

1, There are inconsistent description about DISCONNECT messages: On Page 5,
in Section 4.1.2, paragraph #2, it is stated that "The DISCONNECT Request
message is used when the peer intends to no longer participate in *all*
warms." However, On page 6, in Section 4.2, paragraph #1, it goes "the peer
DISCONNECTs from the corresponding swarm (swarm_b) while still sharing the
first content (swarm_a)". Subsequent relevant texts all seem to be comply
with the first one.

2, There are inconsistent description about the exemplified session in
Section 4.2 between the text and the Figure 1. For the figure does not catch
the status of ""the peer DISCONNECTs from the corresponding swarm (swarm_b)
while still sharing the first content (swarm_a)".

3, Mino typo: on page 9, paragraph labeled with "7)", the last sentence
should be "..., and transitions to TERMINATE s*t*ate for that Peer-ID."

A few questions about the protocol design:

1, What's the objective behind the "init-timer" scheme?

2, How would a peer be "joining the swarm with invalid Swarm_Id"?

3, In section 4.5, since there are extended messages with newly introduced
fields (e.g. contentgroup), you may also need to handle cases with "Unknown
fields" as well as "Unknown Messages".

4, In case a peer specifies the peergroup S (a subset of all the segments)
it's currently interested in with a FIND message, does it make sense for a
tracker to return a peer with only a subset S' of S to the requestor?

Lastly, as for the arrangement of contentgroup, it could be rather
bit-consuming if a peer is FINDing a scattered group of segments. I have
been proposing to use compression method to mitigate this matter.
http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap/ 
I would like to hear any feedback or comments from you TR guys about it:-)

BR
Lingli

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Huangyihong (Rachel)
发送时间: 2013年7月11日 9:46
收件人: [email-masked]
主题: [ppsp] FW: New Version Notification for
draft-huang-ppsp-extended-tracker-protocol-03.txt

Dear all,

We have just submitted a new version of
draft-huang-ppsp-extended-tracker-protocol. This update is just some
editorial changes. No significant modification. Comments are highly
appreciated. 

Best regards,
Rachel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 9:29 AM
To: Mario Serafim Nunes; Rui Santos Cruz; Rui Sant Cruz; Zongning; Mario
Sera Nunes; Huangyihong (Rachel); Joao P. Taveira
Subject: New Version Notification for
draft-huang-ppsp-extended-tracker-protocol-03.txt

Filename:	 draft-huang-ppsp-extended-tracker-protocol
Revision:	 03
Title:		 PPSP Tracker Protocol--Extended Protocol
Creation date:	 2013-07-11
Group:		 Individual Submission
Number of pages: 26
URL:
http://www.ietf.org/internet-drafts/draft-huang-ppsp-extended-tracker-protoc
ol-03.txt
Status:
http://datatracker.ietf.org/doc/draft-huang-ppsp-extended-tracker-protocol
Htmlized:
http://tools.ietf.org/html/draft-huang-ppsp-extended-tracker-protocol-03
Diff:
http://www.ietf.org/rfcdiff?url2=draft-huang-ppsp-extended-tracker-protocol-
03

Abstract:

The IETF Secretariat

_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 12 Jul 2013 01:55:22 +0000

Hi lingli,

Thank you for the review. Please see my reply inline.

Best regards,
Rachel

-----Original Message-----
From: 邓灵莉/Lingli Deng [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 6:05 PM
To: Huangyihong (Rachel); [email-masked]
Subject: 答复: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi Rachel,

[Rachel]: Yes, that's an error description of section 4.2. DISCONNECT message only has the ability to leave all the swarms the peer joined. I don't think DISCONNECT should have a same meaning of CONNECT (LEAVE). So this is one place that I omitted to modify. Thank you for pointing out.

[Rachel]: See above. Figure is consistent with the description of section 4.1.2.

[Rachel]: Okay.

[Rachel]: Previously, init-timer was used to wait for other messages after a peer has sent a "REGISTER" message to the tracker. And the "PEER REGISTERED" state was not transient at that time. But now, we have abandoned the "REGISTER" message and  "PEER REGISTERED" state is transient, so I think we don't need init-timer anymore. 

[Rachel]: My fault. It's a wrong description.  I think my intension is to say receiving a FIND message with a invalid Swarm_Id is considered a error condition.

[Rachel]: Good point. Thanks.

[Rachel]: I think yes. why not?

[Rachel]: Yes. I'm aware of it. I'm working on some ietf documents these days. I'll get you some responses in a few days.

BR
Lingli

-----邮件原件-----

Dear all,

Best regards,
Rachel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 9:29 AM
To: Mario Serafim Nunes; Rui Santos Cruz; Rui Sant Cruz; Zongning; Mario

Abstract:

The IETF Secretariat

---

From: Arno Bakker <[email-masked]>
Date: Tue, 30 Jul 2013 11:03:31 +0200

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?

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

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?

Regards,
      Arno

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 30 Jul 2013 10:43:51 +0000

Hi Arno,

Thanks for your comments. Please see my reply inline.

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Arno Bakker
发送时间: 2013年7月30日 17:04
收件人: [email-masked]
主题: 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":

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

[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

---

From: Arno Bakker <[email-masked]>
Date: Tue, 30 Jul 2013 13:30:34 +0200

Hi Rachel and all

please see inline.

On 30/07/2013 12:43, Huangyihong (Rachel) wrote:
> 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.

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

CU,
     Arno

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 30 Jul 2013 13:49:23 +0000

Hi Arno,

Please see inline.

Best regards,
Rachel

-----邮件原件-----
发件人: Arno Bakker [mailto:[email-masked]] 
发送时间: 2013年7月30日 19:31
收件人: Huangyihong (Rachel)
抄送: [email-masked]
主题: 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:
> 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.

> 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 

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.

CU,
     Arno

---

From: Zongning <[email-masked]>
Date: Wed, 31 Jul 2013 12:25:23 +0000

Hi, Rachel and Arno,

Please see inline.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Huangyihong (Rachel) [[email-masked]]
Sent: Tuesday, July 30, 2013 9:49 PM
To: [email-masked]
Cc: [email-masked]
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:[email-masked]]
发送时间: 2013年7月30日 19:31
收件人: Huangyihong (Rachel)
抄送: [email-masked]
主题: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi Rachel and all

please see inline.

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

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

CU,
     Arno

---

From: Rui Cruz <[email-masked]>
Date: Wed, 31 Jul 2013 13:42:00 +0100

Please read inline.

Regards,
Rui Cruz

> Please see inline.

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

> [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. :)…

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

---

From: Zongning <[email-masked]>
Date: Wed, 31 Jul 2013 12:53:27 +0000

Hi, Cruz.

Please see inline.

________________________________
From: Rui Cruz [[email-masked]]
Sent: Wednesday, July 31, 2013 8:42 PM
To: Zongning
Cc: Rui Cruz; Huangyihong (Rachel); [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Rachel and Arno,

Please see inline.

________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Huangyihong (Rachel) [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 30, 2013 9:49 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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:[email-masked]<mailto:[email-masked]>]
发送时间: 2013年7月30日 19:31
收件人: Huangyihong (Rachel)
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi Rachel and all

please see inline.

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

[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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ppsp
_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: Rui Cruz <[email-masked]>
Date: Wed, 31 Jul 2013 14:02:49 +0100

> [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? :))

[CRUZ] Yes, that is correct.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 31 Jul 2013 13:33:39 +0000

Hi Ning,

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

Hi, Rachel and Arno,

Please see inline.

Hi Arno,

Please see inline.

Best regards,
Rachel

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

Hi Rachel and all

please see inline.

[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