Subject: Re: [ppsp] Progress on core tracker protocol?

From: Arno Bakker <[email-masked]>
Date: Tue, 10 Jul 2012 15:35:11 +0200

Hi Rui et al

after reading the base protocol -00 I have the following comments:

* General: basic design now nice and simple, description still verbose.

* p. 14: The Terminated state does not make much sense, IMHO and is 
equivalent to INIT.

* p. 24: In a PeerGroup in a CONNECT a peer may provide a list of IP 
addresses. How to you intend to protect against malicious peers 
registering victim IP addresses as part of an amplification attack (see
draft-ietf-ppsp-peer-protocol-02, p. 13.2.3). For IP addresses (other 
than the one from which the request comes from) some form of return 
routability check is needed.

* p. 31: Seeders will need to be able to retrieve peer lists from the 
tracker too, in particular when the seeder is behind a NAT itself. 
Please adjust the spec to allow this.

* p. 35: For the peer protocol's security we need the tracker to return 
a true random sample of the list of registered peers in a swarm (see 
peer draft Sec. 13.2.3). Could you make this the default behaviour, or 
allow a peer to request this explicitly?

Regards,
      Arno

---

From: Johan Pouwelse <[email-masked]>
Date: Tue, 10 Jul 2012 19:25:22 +0200

> Filename:  draft-cruz-ppsp-base-tracker-protocol
> Title:  PPSP Tracker Protocol--Base Protocol (PPSP-TP/1.0)
> Number of pages: 41

Excellent to see progress on the Tracker protocol front. I've reviewed
this document, see below.

>From draft-cruz-ppsp-base-tracker-protocol :
       2) In PEER REGISTERED state, if Peer-ID is valid, the tracker
          processes the requested action(s) for the valid swarm information.

I would argue against putting this complexity and registration process
in the base protocol.
It's not needed for a basic implementation, right?

The base protocol now requires full xml parsing and generation.
>From draft-cruz-ppsp-base-tracker-protocol :
   The generic format of a Request is the following:
   <?xml version="1.0" encoding="UTF-8"?>
   <PPSPTrackerProtocol xmlns="TBD" schemaLocation="TBD" version="1.0">
     <Request></Request>
     <TransactionID></TransactionID>
     <PeerID></PeerID>
     <SwarmID></SwarmID>
     <PeerNum></PeerNum>
     <PeerGroup></PeerGroup>
     <StatisticsGroup></StatisticsGroup>
   </PPSPTrackerProtocol>

I would argue against this lack of (bandwidth) efficiency.
The tracker protocol from Bittorrent has been around for 10+ years now.
A few years ago they gave it an efficiency upgrade:
http://bittorrent.org/beps/bep_0015.html
This improvement now yields: "The protocol proposed here uses 4
packets and about 618 bytes".

What is the cost in bytes of a single session for this protocol?

This base protocol definition is a good step forward, but the above
(non-IETF) tracker specification is 5 pages in length, the current
draft is 41 pages.
Trimming down to 8 pages is probably doable by both simplification
(e.g. no registration, timer admin, fully stateless) of this base
protocol and text reduction.
For instance, the following example section should be omitted I
believe, which should not reduce the value of the document.
========
   The process used for media streaming distribution assumes a segment
   (chunk) transfer scheme whereby the original content (that can be
   encoded using adaptive or scalable techniques) is chopped into small
   segments having the following representations:

   1. Adaptive - alternate representations with different qualities and
      bitrates; a single representation is non-adaptive;
   2. Scalable description levels - multiple additive descriptions
      (i.e., addition of descriptions refine the quality of the video);
   3. Scalable layered levels - nested dependent layers corresponding to
      several hierarchical levels of quality, i.e., higher enhancement
      layers refine the quality of the video of lower layers.
   4. Scalable multiple views - views correspond to mono (2D) and
      stereoscopic (3D) videos, with several hierarchical levels of
      quality.

  -johan.

On 29 June 2012 18:45, Rui Cruz <[email-masked]> wrote:
> Hi,
>
> Just to inform you that the Base Tracker Protocol was published a while ago.
>
> A new version of I-D, draft-cruz-ppsp-base-tracker-protocol-00.txt
> has been successfully submitted by Rui Santos Cruz and posted to the
> IETF repository.
>
> Filename:  draft-cruz-ppsp-base-tracker-protocol
> Revision:  00
> Title:  PPSP Tracker Protocol--Base Protocol (PPSP-TP/1.0)
> Creation date:  2012-06-29
> WG ID:  Individual Submission
> Number of pages: 41
> URL:
> http://www.ietf.org/internet-drafts/draft-cruz-ppsp-base-tracker-protocol-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-cruz-ppsp-base-tracker-protocol
> Htmlized:
> http://tools.ietf.org/html/draft-cruz-ppsp-base-tracker-protocol-00
>
>
> Abstract:
>   This document specifies the base Peer-to-Peer Streaming Protocol-
>   Tracker Protocol (PPSP-TP/1.0), an application-layer control
>   (signaling) protocol for the exchange of meta information between
>   trackers and peers.  The specification outlines the architecture of
>   the protocol and its functionality, and describes message flows,
>   message processing instructions, message formats, formal syntax and
>   semantics.  The PPSP Tracker Protocol enables cooperating peers to
>   form content streaming overlay networks to support near real-time
>   Structured Media content (audio, video, associated timed text and
>   metadata) delivery, such as adaptive multi-rate, layered (scalable)
>   and multi-view (3D), in live, time-shifted and on-demand modes.
>
>
> Regards,
>
> Rui Cruz
> [email-masked]
>
> IST/INESC-ID/INOV - Lisbon, Portugal
> __________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>
> On 28/06/2012, at 02:46, zhangyunfei wrote:
>
> Thank Rui for the information.
> P.S.: For the WG, Arno has published a new version of the peer protocol.
> Please review it and publish your comments. Thanks.
>
> BR
> Yunfei
>
> ________________________________
> zhangyunfei
>
> From: Rui Cruz
> Date: 2012-06-28 00:41
> To: Johan Pouwelse
> CC: Rui Cruz; ppsp
> Subject: Re: [ppsp] Progress on core tracker protocol?
> The PPSP-TP base Tracker Protocol draft will be published before the end of
> June.
> It does essentially what we had discussed during IETF 83.
> The PPSP-TP Extended Tracker Protocol will bring all those more
> sophisticated features, and will be published afterwards (during July)
>
> Cumprimentos/Regards,
> Rui Cruz
>
> Sent from my iPad2
>
> On 27/06/2012, at 16:52, Johan Pouwelse <[email-masked]> wrote:
>
> There was agreement for the need to create a core tracker protocol. Any
> progress to report, since last month?
> What do you think of my proposal below for the focus of this
> really-limited-to-the-core protocol?
>
>
> This document specifies the Peer-to-Peer Streaming Protocol--Core Tracker
> Protocol (PPSP-CTP), an application-layer control protocol for facilitating
> Peer-2-Peer streaming. This core protocol is limited to a peer discovery
> request message and reply message.
> The PPSP-CTP protocol is limited to the GET-PEERS message and subsequent
> reply with a peer list. This core protocol is the only requirement for a
> simple streaming service, along with the PPSP peer protocol. We refer to an
> upcoming Extended Tracker Protocol for more sophisticated features. For
> instance,  the exchange of meta information, content information, statistics
> reporting, etc.
>
>
>  -johan.
> On Tuesday, June 5, 2012, Rui Cruz wrote:
>>
>> Hi,
>>
>> The Tracker Protocol is  being split to a base specification draft and to
>> extensions.
>> We hope to have the base specification submitted in a couple of weeks.
>>
>>
>> Regards,
>>
>> Rui Cruz
>> [email-masked]
>>
>> IST/INESC-ID/INOV - Lisbon, Portugal
>> __________________________________________
>> ppsp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ppsp
>>
>> On 04/06/2012, at 10:39, stefano previdi wrote:
>>
>> All,
>>
>> here are some notes i preparation of the next PPSP meeting we're
>> going to have in Vancouver (http://www.ietf.org/meeting/84/index.html)
>>
>> 1. Peer Protocol - chunk addressing mechanism
>>   We currently have two proposals that I'd try to name as:
>> . Bin Notation
>> . Ranges
>>   Both proposals have been discussed in the mailing list and it
>>   looks to me we're NOT achieving agreement/consensus on any of
>>   them also due to lack of participation of the WG into the
>>   discussion (other than the authors of each proposal).
>>
>>   Therefore, as of today, we can reasonably explore the
>>   following options:
>>   Option-1: We propose both solutions in the peer protocol
>>             specification and we define them both MANDATORY so
>>             to cope with interoperability issues.
>>   Option-2: we select one option through a WG vote (this is my
>>             least preferred option).
>>
>>   Since I'd really prefer to avoid Option-2, I can only consider
>>   the "dual" specification. WG opinion on this is requested.
>>
>>   Again, it would be very beneficial to the WG if current
>>   implementors of streaming protocols would/could speak-up and
>>   give their opinion (see point 4 below).
>>
>> 2. Peer Protocol - Security Section
>>   The IESG will not accept any protocol specification without a
>>   consistent security section (IOW: way more than what we
>>   currently have) although there are some arguments on whether
>>   we need the security mechanisms in the base spec.
>>
>>   Arno and Zong Ning proposed some text and we need to agree/amend
>>   it asap so to update the draft. I'd like to close this one and
>>   have a new version of the draft for next meeting.
>>
>> 3. Tracker Protocol
>>   After IETF83 we agreed to split into two distinct drafts: base
>>   specification and optional extensions.
>>
>>   Authors, it would be good to have a first submission before next
>>   meeting.
>>
>> 4. Survey draft.
>>   We need to refresh/re-submit and the chairs proposed the
>>   authors/editors to include a section on deployment experiences
>>   and more precisely on chunk addressing and security mechanisms.
>>   Hopefully this will also feed ongoing discussions.
>>
>> 5. Meeting during IETF84.
>>   We have requested a slot for Vancouver meeting. Anyone
>>   interested, please request an agenda slot asap to Yunfei or
>>   myself.
>>
>> Let us know if anything is missing.
>>
>> Thanks.
>>
>> Stefano & Yunfei
>> _______________________________________________
>> ppsp mailing list
>> [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: Tue, 10 Jul 2012 21:54:25 +0100

Thanks for the comments.

The PPSP protocols are for Media Streaming, not simple file sharing. The requirements are different and so, any comparison with BitTorrent should take that in consideration.
Besides that, Media Streaming "sessions" are typically limited in time (even a "live program" may not take longer than 24 hours?), while file downloads in BitTorrents may take "months" to complete.

> It's not needed for a basic implementation, right?

Where is the complexity of registration? The peer just sends a peer-ID that needs to be validated. If valid, the tracker registers that peer as active. Only ONE request message is sent.
In BitTorrent, besides the peer_id it also needs a connection_id to be validated before the tracker accepts the peer, and this requires exchanging at least two requests (connect and announce).  

> What is the cost in bytes of a single session for this protocol?

This protocol uses ONE request message (CONNECT) to get the peer "connected", "announced" in several swarms, and, if leech, receive the peer lists for the corresponding swarms. 
It supports IPv4 and IPv6. The responses can be as rich as desired in terms of information for the peer.

The BitTorrent protocol over UDP does not support IPv6 (yet) and besides the connect requires one "announce" per swarm.

For a seeder joining the same number of swarms, for example 10,  perhaps the cost is not so different as each BitTorrent "announce" uses around 64 bytes for the request. 

BitTorrent:  			"connect" + 10x"announce" = ~656 bytes (and 11xRTT)
PPSP Tracker/1.0: 	CONNECT (with 10 swarms) = ~640 bytes (using gzip content encoding) and 1xRTT.

The same reasoning could be made for the responses, as BitTorrent would use one response with peer list for each announce. For the same 10 swarms,  it would be 10 requests and 10 responses, while for our protocol all that would be included in the response to the single CONNECT request. 
Additionally, for the same effect, it would take much longer for BitTorrent in terms of transit time to achieve the same result.  

Regards,

Rui Cruz
[email-masked]

---

From: Rui Cruz <[email-masked]>
Date: Tue, 10 Jul 2012 22:44:40 +0100

Hi Arno,

Thanks for your comments.

> * p. 14: The Terminated state does not make much sense, IMHO and is equivalent to INIT.

The "per-Peer-ID" state machine is destroyed when the peer is de-registered and so it does not returns to an INIT state (that is transient).

>  For IP addresses (other than the one from which the request comes from) some form of return routability check is needed.

The peer may inform the tracker of its IP addresses, but the peer Transport Address (REFLEXIVE) "candidate", the one from which the request comes from, is the one that is returned in peer lists by the tracker. 

A return routability check could be implemented, if required just by mandating a STAT_REPORT after a successful CONNECT carrying a key received in the response to the CONNECT. If the peer does not answer with the key, then it would be de-registered from the tracker. 

> * p. 31: Seeders will need to be able to retrieve peer lists from the tracker too, in particular when the seeder is behind a NAT itself. Please adjust the spec to allow this.

I see. The spec can be adjusted to include that option.

> * p. 35: For the peer protocol's security we need the tracker to return a true random sample of the list of registered peers in a swarm (see peer draft Sec. 13.2.3). Could you make this the default behaviour, or allow a peer to request this explicitly?

The "default behavior" is the tracker to return a randomly selected subset of the peers in a swarm satisfying certain criteria (location, status, special policies), not all the peers (unless their number is even lower than the one requested by the peer). I suppose this satisfies your concern, but we can stress it in the text. 

Regards,

Rui Cruz
[email-masked]

On 10/07/2012, at 14:35, Arno Bakker wrote:

> * p. 14: The Terminated state does not make much sense, IMHO and is equivalent to INIT.
> 
> * p. 24: In a PeerGroup in a CONNECT a peer may provide a list of IP addresses. How to you intend to protect against malicious peers registering victim IP addresses as part of an amplification attack (see
> draft-ietf-ppsp-peer-protocol-02, p. 13.2.3). For IP addresses (other than the one from which the request comes from) some form of return routability check is needed.
> 
> * p. 31: Seeders will need to be able to retrieve peer lists from the tracker too, in particular when the seeder is behind a NAT itself. Please adjust the spec to allow this.
> 
> * p. 35: For the peer protocol's security we need the tracker to return a true random sample of the list of registered peers in a swarm (see peer draft Sec. 13.2.3). Could you make this the default behaviour, or allow a peer to request this explicitly?
> 
> Regards,
>     Arno