Re: [ppsp] Progress on core tracker protocol?

[Johan Pouwelse <[e-mail]>]

> 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 <[e-mail]> 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
> [e-mail]
>
> IST/INESC-ID/INOV - Lisbon, Portugal
> __________________________________________
> ppsp mailing list
> [e-mail]
> 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 <[e-mail]> 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
>> [e-mail]
>>
>> IST/INESC-ID/INOV - Lisbon, Portugal
>> __________________________________________
>> ppsp mailing list
>> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ppsp
>>
>>
> _______________________________________________
> ppsp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp
>
>