Re: [ppsp] New Version Notification for draft-gu-ppsp-tracker-protocol-06.txt

Martin Stiemerling <Martin.Stiemerling@neclab.eu> Wed, 09 November 2011 14:46 UTC

Return-Path: <Martin.Stiemerling@neclab.eu>
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 6E91021F89B8 for <ppsp@ietfa.amsl.com>; Wed, 9 Nov 2011 06:46:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.3
X-Spam-Level:
X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 f8YW0GjmidQU for <ppsp@ietfa.amsl.com>; Wed, 9 Nov 2011 06:46:26 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 41E1521F8922 for <ppsp@ietf.org>; Wed, 9 Nov 2011 06:46:25 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 47D2C28000203; Wed, 9 Nov 2011 15:46:24 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb+-q4zbUpZe; Wed, 9 Nov 2011 15:46:24 +0100 (CET)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 22EEB28000101; Wed, 9 Nov 2011 15:46:14 +0100 (CET)
Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 9 Nov 2011 15:46:14 +0100
From: Martin Stiemerling <Martin.Stiemerling@neclab.eu>
To: Rui Cruz <rui.cruz@ieee.org>, ppsp <ppsp@ietf.org>
Thread-Topic: [ppsp] New Version Notification for draft-gu-ppsp-tracker-protocol-06.txt
Thread-Index: AQHMl+Tgz/dvQk6CsEytMJhmbjeDupWkanhw
Date: Wed, 09 Nov 2011 14:46:13 +0000
Message-ID: <E84E7B8FF3F2314DA16E48EC89AB49F024E6EDB4@Polydeuces.office.hd>
References: <20111031112206.30317.90541.idtracker@ietfa.amsl.com> <FE044FA7-7820-4D0B-861B-ACBEF14FC942@ieee.org>
In-Reply-To: <FE044FA7-7820-4D0B-861B-ACBEF14FC942@ieee.org>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.1.135]
Content-Type: multipart/alternative; boundary="_000_E84E7B8FF3F2314DA16E48EC89AB49F024E6EDB4Polydeucesoffic_"
MIME-Version: 1.0
Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-tracker-protocol-06.txt
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: Wed, 09 Nov 2011 14:46:30 -0000

[Speaking as individual]

Hi,

I have read the merged version of the tracker protocol and it is for me on the right technical track. I have some issues:

-          Section 3.7 deals with the media presentation description. I see this orthogonal to the tracker protocol, though there can be dependencies if the presentation description contains information about the trackers. However, it is not the task of the tracker protocol draft to define how the actual information about the location of trackers is conveyed to the peers. I would remove it completely, or add an appendix where the potential dependency between presentation description and information about trackers is discussed. This would give space to talk the many different presentation descriptions available out there.

-          The relationship between the tracker protocol and SVC/MDC/and friends is not clear to me just from reading the draft. I see codec issues more related to the presentation description but not the tracker protocol. However, I'm happy to be convinced by you that there is a relationship.

-          Figure 2: Is this referring to a particular implementation or is it meant to show the conceptual data structures? Anyhow, the relationships between the different parameters are not clear and it may not be required to flesh this completely out. I guess a purely textual description would be better, without going into the detail what the conceptual data structures of a tracker are.

-          Table1/Request Messages:

o    I see that the messages there are required on a semantically level, but I'm not so sure that we need all those messages in the protocol. For instance, the LEAVE and DISCONNECT messages are used in a combined way (or interchangeable way) in Figure 3 (see the bottom). Thus LEAVE seems to have a similar semantics like DISCONNECT.

o   KEEPALIVE is required on the semantically level, but it could be modeled with another message.

o   The point I'm trying to make: In the bittorrent tracker protocol, there is only a GET which pulls information about peers from the tracker to the peer and updates the tracker about the peer issuing the GET. This is also used as keep alive. This may be overloading a single message, but on the other hand hints to the fact that only a very limited amount of messages on the wire are required.

-          HTTP error codes vs. protocol error codes: I do not see the clear separation in the draft between what the HTTP error codes indicate and what the tracker protocol error codes are. For instance the HTTP error code 400 is already overloaded with 2 meanings: invalid syntax (by the way of what: HTTP or message body of HTTP) and version not supported. This does not look very clean, easy to implement, and also future proof.

  Martin

martin.stiemerling@neclab.eu<mailto:martin.stiemerling@neclab.eu>

NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

From: ppsp-bounces@ietf.org<mailto:ppsp-bounces@ietf.org> [mailto:ppsp-bounces@ietf.org]<mailto:[mailto:ppsp-bounces@ietf.org]> On Behalf Of Rui Cruz
Sent: Monday, October 31, 2011 4:50 PM
To: ppsp
Cc: Rui Cruz
Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-tracker-protocol-06.txt

Hi,

We have updated the PPSP Tracker Protocol draft, corresponding to the merge of the former drafts from Gu and Cruz.

The changes reflect the details and suggestions discussed in recent meetings and in the mailing list.

Please let us know your comments and suggestions.

Thanks.

---------------------------
Best Regards,

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
Av. Prof. Dr. Aníbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Porto Salvo, Portugal
+351 214 233 200 (ext 5044), +351.939 060 939 (mobile)
rui.cruz@ieee.org<x-msg://127/rui.cruz@ieee.org>
rui.s.cruz@ist.utl.pt<x-msg://127/rui.s.cruz@ist.utl.pt>
sec.portugal@ieee.org<x-msg://127/sec.portugal@ieee.org>
www.ieee-pt.org<http://www.ieee-pt.org/>
Advancing technology for humanity.

On 31/10/2011, at 11:22, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:


A new version of I-D, draft-gu-ppsp-tracker-protocol-06.txt has been successfully submitted by Rui Cruz and posted to the IETF repository.

Filename:       draft-gu-ppsp-tracker-protocol
Revision:       06
Title:              PPSP Tracker Protocol
Creation date:            2011-10-30
WG ID:                     Individual Submission
Number of pages: 44

Abstract:
  This document outlines the functionality required for an HTTP-based
  P2P Streaming Tracker Protocol, including requirements, functional
  entities and architecture, components, message flows, with detailed
  message processing instructions using an HTTP/XML encoding, the
  respective parameters, methods, and message formats, formal syntax
  and semantics. The PPSP Tracker Protocol proposed in this document
  extends the capabilities of PPSP to support adaptive and scalable
  video and 3D video, for Video On Demand (VoD) and Live video
  services. The Tracker Protocol is an application-level protocol for
  peers to publish/request content, provide peer lists to peers and
  peer status to Trackers.




The IETF Secretariat