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

[Rui Cruz <[e-mail]>]

Hi Martin,

Please read inline my comments.

---------------------------
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
[phone] (ext 5044), +351.939 060 939 (mobile)
[e-mail] 
[e-mail]
[e-mail]
www.ieee-pt.org
Advancing technology for humanity.

On 09/11/2011, at 14:46, Martin Stiemerling wrote:

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

I agree that the Media Presentation Description may be considered orthogonal to the protocol. However, there are in fact dependencies related to the identification of trackers for the  media/stream (swarm) described in the MPD, as well as for the structure of the media/stream. This can be "compared" to a .torrent file, that plays somehow the role of the MPD in the case of BitTorrent protocol, and as you know, the .torrent file contains information about the trackers and the mapping of the chunks/pieces of the content.
I agree that description of the MPD can be moved, with the necessary adaptions in the main text, to an Appendix.

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

The Tracker protocol (as well as the Peer protocol) are bound to "VoD or Live streaming of multimedia" (with the necessary constraints), not for simple file sharing.
However, a very important principle should be observed, in my opinion, related to the role these protocols play in the streaming process, as they should be open to support both "Structured Media"  (SVC/MDC/MVC/multi-bitrate) and unstructured media, but not being involved in the decoding/encoding processes of the "Structured Media". 
It is the Media Player application, not the protocols associated with the transport of the Media, the entity that should "know" (via a requester/re-assembler module) how and what to request (to a "peer") and decode the received "Structured Media" (from the "peer") in order to "present" it to the User. 
As far as I know, other implementations of P2P media streaming, either do not support "Structured Media" or, to support it, are deeply involved in the requester/re-assembler decoding process, for example, splitting SVC layers or MDC descriptions in different "trees" (push mode), or using specific "piece picking" strategies and peer selection strategies for the selection of the SVC layers or MDC descriptions, but integrated into the P2P protocols. 
The Media Presentation Description just helps the processes (associated with the protocol) to know which are the Trackers controlling it and how to map the chunks in order to "inform" which Peer HAS which Chunk (and corresponding layers/descriptions etc.), but not tacking decisions on layer/description fetching priorities, unless "instructed" by the external requester/re-assembler module of the Media Player.

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

Ok, I agree with that. We will revise it for next version

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

A Peer may have JOINed several swarms, and be just contributing to those swarms, but the user may decide to LEAVE a specific swarm, not DISCONNECT from the system, and continue contributing or JOINing a new swarm to watch a content, while still contributing to other swarms. The semantics may seem similar but the purpose is more granular with the LEAVE. Eventually, the DISCONNECT message may play the same role as LEAVE when specifying a Swarm-ID. Let's discuss this option in the meeting and mailing list.
Figure 3 just gives a typical example, although I recognize that it should not raise these doubts. We will revise it.  

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

Agreed.

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

Agreed. The STAT_REPORT can be used for the same purpose. Let's discuss this option in the meeting and mailing list.

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

Also agreed. Let's discuss if we can just use standard HTTP error codes without overloading with multiple meaning, in the meeting and mailing list.

>  
>   Martin
>  
> [e-mail]
>  
> NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>  
> From: [e-mail] [mailto:[e-mail]] 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
> [phone] (ext 5044), +351.939 060 939 (mobile)
> [e-mail] 
> [e-mail]
> [e-mail]
> www.ieee-pt.org
> Advancing technology for humanity.
>  
> On 31/10/2011, at 11:22, [e-mail] 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
>  
> _______________________________________________
> ppsp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp