Re: [ppsp] Progress on core tracker protocol?

Rui Cruz <rui.cruz@ieee.org> Tue, 10 July 2012 20:54 UTC

Return-Path: <rui.cruz@ieee-pt.org>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E51C11E80D9 for <ppsp@ietfa.amsl.com>; Tue, 10 Jul 2012 13:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.298
X-Spam-Level:
X-Spam-Status: No, score=-101.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYDDZgqbK1Ik for <ppsp@ietfa.amsl.com>; Tue, 10 Jul 2012 13:54:09 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5169D11E80BC for <ppsp@ietf.org>; Tue, 10 Jul 2012 13:54:07 -0700 (PDT)
Received: by weyu54 with SMTP id u54so55982wey.31 for <ppsp@ietf.org>; Tue, 10 Jul 2012 13:54:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=M6061VgTXKwr42BlBBrYjrMKJ4SGu0S3StdCkuuAjtQ=; b=AC9V+ZFyst713l9m9+MS/Qy6goM48Z9qDWbiXxtMU1yspOduGRTXGOTMpBKR85mh/Q EMso+GCeRxMN2dOoVJCmNZrpfDkI649XxorC0K5sdwx/EYwGN7Y4Da19NVkBVu5r4myw tQAQ8JKBPPGXQOVLvIpZKSnAquOmDCDcA3p1WCIFWZgL51YLLmzysE2SK8/VwZaCYfii 8Ac+EfiZxdJjzysOP7+VWOalXVn/MXXs3iaoRgoaLfIruvF9xWTrdzrCqknvhqlE+aqW HYcPgDpcF+Viu0RJ4SIWGGHcNg4+AWJnd0C0m/kYk1/GUnFzkA66tUuysAbBVW2+jpOt r6jA==
Received: by 10.216.235.81 with SMTP id t59mr20430632weq.156.1341953675793; Tue, 10 Jul 2012 13:54:35 -0700 (PDT)
Received: from airia.casa ([89.180.24.72]) by mx.google.com with ESMTPS id b7sm20764397wiz.9.2012.07.10.13.54.28 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 13:54:34 -0700 (PDT)
Sender: Rui Cruz <rui.cruz@ieee-pt.org>
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_11FC74A1-6C30-476C-BB70-C76A8976006C"
From: Rui Cruz <rui.cruz@ieee.org>
In-Reply-To: <CAJYQ-fQSrgrTS2K5cz3Xs3r7WO6EBfto8mATXkQKuZNOKpb8mg@mail.gmail.com>
Date: Tue, 10 Jul 2012 21:54:25 +0100
Message-Id: <20ED4BE8-28B1-4EAB-81DE-EAEBC5607200@ieee.org>
References: <CAJYQ-fQbj9WjSt8JTQdiULuaJu4LGbB9ErmrA_C2JN3Fjq6HQg@mail.gmail.com> <EDCDAC3A-EE05-417B-BEA0-0A881AE9D055@ieee-pt.org> <2012062809463963273025@chinamobile.com> <CEA67F8D-E25E-419E-ADC3-683ECEADDAF8@ieee-pt.org> <CAJYQ-fQSrgrTS2K5cz3Xs3r7WO6EBfto8mATXkQKuZNOKpb8mg@mail.gmail.com>
To: Johan Pouwelse <peer2peer@gmail.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQl18wfQnH46lmVJqu+QmfcQ4xzZeOOb5ZqI3Dzle9RkJ10r3kr4MtAvfGpREkFPt1s6Tlqm
Cc: Rui Cruz <rui.cruz@ieee.org>, ppsp <ppsp@ietf.org>
Subject: Re: [ppsp] Progress on core tracker protocol?
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 20:54:11 -0000

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.

> I would argue against putting this complexity and registration process
> in the base protocol.
> 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
rui.cruz@ieee.org

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

On 10/07/2012, at 18:25, Johan Pouwelse wrote:

>> 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 <rui.cruz@ieee-pt.org> 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
>> rui.cruz@ieee.org
>> 
>> IST/INESC-ID/INOV - Lisbon, Portugal
>> __________________________________________
>> ppsp mailing list
>> ppsp@ietf.org
>> 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 <peer2peer@gmail.com> 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
>>> rui.cruz@ieee.org
>>> 
>>> IST/INESC-ID/INOV - Lisbon, Portugal
>>> __________________________________________
>>> ppsp mailing list
>>> ppsp@ietf.org
>>> 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
>>> ppsp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ppsp
>>> 
>>> 
>> _______________________________________________
>> ppsp mailing list
>> ppsp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ppsp
>> 
>> 
> _______________________________________________
> ppsp mailing list
> ppsp@ietf.org
> https://www.ietf.org/mailman/listinfo/ppsp