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

[Rui Cruz <[e-mail]>]

Hi Arno,

Please see inline.

Regards,

Rui Cruz
[e-mail]

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

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

> Hi Rui et al.
> 
> please see inline:
> 
> On 13/11/2012 13:18, Rui Cruz wrote:
>> 
>>> 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.
>> 
> 
> 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.

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

> 
> 
>>> My major concern is security, in particular, when the tracker supports
>>> 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.
>> 
> 
> 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.