Subject: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item

From: stefano previdi <[email-masked]>
Date: Mon, 12 Nov 2012 15:43:23 +0100

All,

during our our IETF85 PPSP WG meeting, the authors of 
draft-cruz-ppsp-base-tracker-protocol-01 requested the adoption 
of the document as WG item.

Please, send your comments (support, non-support, concerns, ...) 
to the mailing list not later than November 30, 2012.

Thanks.
s.

---

From: "Guyingjie (Yingjie)" <[email-masked]>
Date: Mon, 12 Nov 2012 15:36:44 +0000

I support to adopt draft-cruz-ppsp-base-tracker-protocol-01 as a WG item. 

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 stefano previdi
发送时间: 2012年11月12日 8:43
收件人: ppsp; zhangyunfei Zhang
主题: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item

All,

during our our IETF85 PPSP WG meeting, the authors of
draft-cruz-ppsp-base-tracker-protocol-01 requested the adoption of the document as WG item.

Please, send your comments (support, non-support, concerns, ...) to the mailing list not later than November 30, 2012.

Thanks.
s.

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

---

From: Rui Cruz <[email-masked]>
Date: Mon, 12 Nov 2012 15:49:05 +0000

I also support adopting draft-cruz-ppsp-base-tracker-protocol-01 as a WG item.

Regards,

Rui Cruz
[email-masked]

IST/INESC-ID/INOV - Lisbon, Portugal
__________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: Xiajinwei <[email-masked]>
Date: Tue, 13 Nov 2012 01:03:28 +0000

I support this work to be adopted by PPSP WG.

BR
Jinwei

> 发送时间: 2012年11月12日 22:43

---

From: João Pedro Taveira <[email-masked]>
Date: Mon, 12 Nov 2012 15:52:21 +0000

Best Regards
-- 
João Pedro Taveira Pinto Silva - [email-masked] - +351 96 69 13 777 - +351
213 100 413
Development Engineer - Information Systems Unit
INOV - Inesc Inovação - http://www.inov.pt - +351-213100444

On 12/11/12 15:49, Rui Cruz wrote:
> [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> On 12/11/2012, at 15:36, "Guyingjie (Yingjie)" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> 发件人: [email-masked] <mailto:[email-masked]>
>> [mailto:[email-masked] <mailto:[email-masked]>] 代表 stefano previdi
>> 发送时间: 2012年11月12日 8:43
>> Please, send your comments (support, non-support, concerns, ...) to the
>> mailing list not later than November 30, 2012.
>>
>> Thanks.
>> s.
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: zhangyunfei <[email-masked]>
Date: Tue, 13 Nov 2012 09:47:13 +0800

I have reviewed the draft and sent comments to the email list. Speaking individually, I support the adoption of the document as the WG item.

Yunfei

zhangyunfei

From: stefano previdi
Date: 2012-11-12 22:43
To: ppsp; zhangyunfei Zhang
Subject: Request: draft-cruz-ppsp-base-tracker-protocol as WG item

All,

Thanks.
s.

---

From: Arno Bakker <[email-masked]>
Date: Tue, 13 Nov 2012 11:07:48 +0100

> to the mailing list not later than November 30, 2012.

Hi all

the basics are generally ok, but I do have the following comments and 
concerns:

p. 13. Why doesn't a peer in SEED mode connect to other peers? 
Especially in a world with NAT boxes it may be necessary for seeders to 
initiate the connection themselves.

p. 14. IMHO STAT_REPORT should be optional to have a tracker protocol 
that provides just the basics, which is returning a list of peers for a 
given swarm. See also below.

p. 15. IMHO the transient states TERMINATED and START should be removed 
from the tracker and peer state machines, respectively. They are 
transitions, not states.

p. 16. A Table 6 defining STAT_REPORT properties is missing, Table 6 
currently defines Response values.

My major concern is security, in particular, when the tracker supports
returning peers based on criteria specified by the client. At present
a client can specify the preferred capabilities of a returned peer
in terms of its NAT ability, load (in terms of number of peers), online 
time and upload bandwidth level (see p. 20). For a tracker to be able to 
reply to such queries it must receive this information somehow. 
Currently this is done by self-reporting of registering peers.

It is unclear how this feature can work reliably in an environment with 
malicious peers which will lie about their capabilities in order to 
attract peers. The draft suggests a global trust mechanism, but that is 
currently not available. I therefore propose to remove this 
capability-based peer selection until that time. Instead, the tracker 
should always return a random sample from the peer population (a feature 
required by the current peer protocol (-03, Sec.13.2.3) and not yet 
addressed in the draft.)

So I support the transition to Working Group Document, provided that the 
above concerns are resolved to the working group's satisfaction ASAP.

CU,
    Arno

P.S. Typos / nits:

p. 10. "since it joins" -> "since it joined"

p. 13. "HTTT/1.1" -> "HTTP/1.1"

p. 29. "If the length of the message does not matches the 
Content-Length" How will you know, given HTTP is run over TCP which is a 
byte stream?

---

From: Rui Cruz <[email-masked]>
Date: Tue, 13 Nov 2012 12:18:47 +0000

Hi Arno, All,

First of all, thanks for spotting those typos in the text.
About Content-Lenght information mismatch, this is an issue of HTTP message formatting, not of the Tracker Protocol Requests/Responses.

Answering Arno's concerns:

> p. 13. Why doesn't a peer in SEED mode connect to other peers? Especially in a world with NAT boxes it may be necessary for seeders to initiate the connection themselves.
Nothing prevents a peer with all content (seed) to connect to other peers. But that is an implementation of the Peer, and the Peer Protocol, not of the Tracker, or the Tracker Protocol.

> p. 14. IMHO STAT_REPORT should be optional to have a tracker protocol that provides just the basics, which is returning a list of peers for a given swarm. See also below.
The STAT_REPORT has two purposes: 1) a status heart-beat (mandatory) for the tracker to keep the peer Registered (facilitating cleaning up of inactive/vanished peers in the swarm);  2) reporting statistic data (optional)

> p. 15. IMHO the transient states TERMINATED and START should be removed from the tracker and peer state machines, respectively. They are transitions, not states.
The Tracker has a State Machine (Figure 4), and each Peer-ID Transaction State Machine. While there is at least one Registered and active peer in a swarm the Tracker is in State STARTED. Each TSM of a Peer-ID, when TERMINATEs is removed, but if it is the LAST one, then, when TERMINATEs, the Tracker SM transitions from the STARTED state to the TERMINATED State, which is transient, returning the Tracker to INIT State (started but no activity, no peers, no swarms).

> p. 16. A Table 6 defining STAT_REPORT properties is missing, Table 6 currently defines Response values.
In fact, an extra line in Table 4 erroneously refers to Table 6 on @property values. That extra line needs to be either removed (as the only @property defined for the base-protocol is "StreamStatistics") and replaced by a sentence in section 8.2 or point to a new table, not Table 6, with that information.

> returning peers based on criteria specified by the client.
.....
> For a tracker to be able to reply to such queries it must receive this information somehow.
That information can be received by the Tracker in STAT_REPORTs.

> The draft suggests a global trust mechanism, but that is currently not available. I therefore propose to remove this capability-based peer selection until that time. Instead, the tracker should always return a random sample from the peer population.
This is an implementation issue of the Tracker service.
The tracker protocol itself supports the transfer of the associated information, if desired. The most basic information is just the number of peers to be returned in a list, without reference to any "special" capabilities. The PeerNUM element and attributes are not even mandatory.

> the tracker should always return a random sample from the peer population (a feature required by the current peer protocol (-03, Sec.13.2.3) and not yet addressed in the draft.)
Again, this is just an implementation issue of the Tracker service.
The tracker protocol itself is able to transport that information, but is not involved in the selection process, be it random or based on specified criteria.

Regards,

Rui Cruz
[email-masked]

On 13/11/2012, at 10:07, Arno Bakker <[email-masked]> wrote:

> the basics are generally ok, but I do have the following comments and concerns:
> 
> p. 13. Why doesn't a peer in SEED mode connect to other peers? Especially in a world with NAT boxes it may be necessary for seeders to initiate the connection themselves.
> 
> p. 14. IMHO STAT_REPORT should be optional to have a tracker protocol that provides just the basics, which is returning a list of peers for a given swarm. See also below.
> 
> p. 15. IMHO the transient states TERMINATED and START should be removed from the tracker and peer state machines, respectively. They are transitions, not states.
> 
> p. 16. A Table 6 defining STAT_REPORT properties is missing, Table 6 currently defines Response values.
> 
> in terms of its NAT ability, load (in terms of number of peers), online time and upload bandwidth level (see p. 20). For a tracker to be able to reply to such queries it must receive this information somehow. Currently this is done by self-reporting of registering peers.
> 
> It is unclear how this feature can work reliably in an environment with malicious peers which will lie about their capabilities in order to attract peers. The draft suggests a global trust mechanism, but that is currently not available. I therefore propose to remove this capability-based peer selection until that time. Instead, the tracker should always return a random sample from the peer population (a feature required by the current peer protocol (-03, Sec.13.2.3) and not yet addressed in the draft.)
> 
> So I support the transition to Working Group Document, provided that the above concerns are resolved to the working group's satisfaction ASAP.
> 
> CU,
>   Arno
> 
> P.S. Typos / nits:
> 
> p. 29. "If the length of the message does not matches the Content-Length" How will you know, given HTTP is run over TCP which is a byte stream?
>

---

From: Arno Bakker <[email-masked]>
Date: Wed, 14 Nov 2012 08:14:18 +0100

Hi Rui et al.

please see inline:

On 13/11/2012 13:18, Rui Cruz wrote:
>> Especially in a world with NAT boxes it may be necessary for seeders
>> to initiate the connection themselves.
> Nothing prevents a peer with all content (seed) to connect to other
> peers. But that is an implementation of the Peer, and the Peer Protocol,
> not of the Tracker, or the Tracker Protocol.
>

At the moment when peerMode is SEED the tracker appears not to send a 
peer list (p. 27 at bottom). Please clarify how a seed obtains a peer 
list, e.g. does PeerNum take priority over peerMode?

> The STAT_REPORT has two purposes: 1) a status heart-beat (mandatory) for
> the tracker to keep the peer Registered (facilitating cleaning up of
> inactive/vanished peers in the swarm); 2) reporting statistic data
> (optional)
>

For function 1, CONNECT suffices, see p. 17 2nd item. This means that
STAT_REPORT can be made truly optional. At the moment STAT_REPORT is 
mandatory ("This request message MUST be sent periodically to the 
tracker", p. 14.)

>> The draft suggests a global trust mechanism, but that is currently not
>> available. I therefore propose to remove this capability-based peer
>> selection until that time. Instead, the tracker should always return a
>> random sample from the peer population.
> The tracker protocol itself supports the transfer of the associated
> information, if desired. The most basic information is just the number
> of peers to be returned in a list, without reference to any "special"
> capabilities. The PeerNUM element and attributes are not even mandatory.
>

But if it is currently not possible to implement a tracker service that 
offers this functionality and is secure in a malicious environment, the 
support for it should not be in the tracker protocol, IMHO.

CU,
     Arno

P.S. Typo: There are also references to a Section 8.6 in the draft, 
which no longer exist.

---

From: Rui Cruz <[email-masked]>
Date: Wed, 14 Nov 2012 12:36:15 +0000

Hi Arno,

Please see inline.

Regards,

Rui Cruz
[email-masked]

On 14/11/2012, at 07:14, Arno Bakker <[email-masked]> wrote:

> At the moment when peerMode is SEED the tracker appears not to send a peer list (p. 27 at bottom). Please clarify how a seed obtains a peer list, e.g. does PeerNum take priority over peerMode?
Using only the base protocol (the extended protocol provides extra control in this area) the condition you mention might be turned implicit if peerNum is supplied when peerMode is SEED.
I personally have no objection with that condition.
If WG agrees a paragraph can be added to describe it.

> STAT_REPORT can be made truly optional. At the moment STAT_REPORT is mandatory ("This request message MUST be sent periodically to the tracker", p. 14.)
The control mechanism on active peers in a swarm,and therefore the capability to provide useful peer lists, needs a periodic status reported from the peers, otherwise the tracker would be just a simple and useless log. 
As such, the STAT_REPORT for periodic status cannot be turned optional. It is the simple mechanism that allows the tracker to provide useful information.

The CONNECT message in the base protocol is restricted to certain conditions. The second item you mention refers to an active peer (already joined in one or in N swarms) requesting to LEAVE the one or the N swarms, or to switch (LEAVE[x] + JOIN[y]) between two swarms. Those conditions either turn the peer inactive (the tracker would delete the peer records) or keep the peer as active but in a different swarm. These actions do not completely replace a periodic status report, in special when the duration of the streaming is high (hours). 

> But if it is currently not possible to implement a tracker service that offers this functionality and is secure in a malicious environment, the support for it should not be in the tracker protocol, IMHO.
I do not agree with your position stating that a (global) trust functionality is "not possible" to be offered.
An implementation of a tracker service can perfectly offer a trust functionality. It might not be "global" but can be offered.
In EU Project SARACEN we have an implementation of a trust/reputation functionality.
Additionally, peer selection criteria (from the tracker) is not restricted to "peer capabilities" (real or fake) but also to network location (the tracker service may use that criterion, independently of the information provided by the peer).

> 
> CU,
>    Arno
> 
> P.S. Typo: There are also references to a Section 8.6 in the draft, which no longer exist.
Thanks, again. We already had noticed that typo, it should be 8.3.

---

From: Arno Bakker <[email-masked]>
Date: Wed, 21 Nov 2012 13:56:48 +0100

Hi Rui et al,

please see inline.

On 14/11/2012 13:36, Rui Cruz wrote:
> Using only the base protocol (the extended protocol provides extra
> control in this area) the condition you mention might be turned implicit
> if peerNum is supplied when peerMode is SEED.

Please do.

> The CONNECT message in the base protocol is restricted to certain
> conditions.

IMHO, these restrictions on CONNECT could be lifted to allow it to be 
used for refreshing registrations, yielding a very simple 1 message 
protocol.

>> But if it is currently not possible to implement a tracker service
>> that offers this functionality and is secure in a malicious
>> environment, the support for it should not be in the tracker protocol,
>> IMHO.
> I do not agree with your position stating that a (global) trust
> functionality is "not possible" to be offered.
> An implementation of a tracker service can perfectly offer a trust
> functionality. It might not be "global" but can be offered.

Let me phrase it differently: Can you build a PPSP-based YouTube that 
securely uses this property-based peer selection? If not, the draft 
should make it clear that property-based selections can only be safely 
used under specific conditions.

CU,
     Arno

---

From: Zongning <[email-masked]>
Date: Fri, 30 Nov 2012 02:40:19 +0000

Hi,

I read the draft and support adopting this document as WG item.

I also see some next-step work to further improve the draft later on (after becoming a WG draft).
1) most tutorial text (e.g. 1.1 Use Scenarios, 1.2 Assumptions) could be merged to PPSP survey WG draft;
2) if properties listed in Table 4 like upload/download bytes are mandatory or just examples for STAT_REPORT? If mandatory, why? Why not other properties such as physical link status, online time? I think we need elaborate more on this. It seems the current reference to Table 6 is wrong.
3) I would suggest to briefly describe distributed tracker in error and recovery section.

I am happy to work with authors on the above issues.

-Ning

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> stefano previdi
> Sent: Monday, November 12, 2012 10:43 PM
> Subject: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item
> 
> 
> All,
>