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

[Martin Stiemerling <[e-mail]>]

Hi Rui,

On 11/10/2011 12:55 PM, Rui Cruz wrote:
[...]
>
> 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.

This would be good, but please check also for the IETF choice for 
presentation descriptions: SDP.

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

I sense that you are saying that it is not necessary to capture the 
notion of structured or unstructured media in the tracker protocol. 
However, I might misunderstand your text.

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

I'm in support of SVC/MDC/AVC, as the ppsp protocols should definitely 
support those type of codecs. I'm only not sure what the impact is the 
protocols, though I see the impact to the presentation description and 
the mapping of codec elements to the transport.

> 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

Thanks!

>
>> -Table1/Request Messages:
>> oI 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.

Yes, let's discuss the messages at the meeting.

> Figure 3 just gives a typical example, although I recognize that it
> should not raise these doubts. We will revise it.
>
>> oKEEPALIVE is required on the semantically level, but it could be
>> modeled with another message.
>
> Agreed.
>
>> oThe 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.

Potentially the tracker protocol needs only a few methods, but can have 
additional parameters which convey the information needed to implement, 
for example, the keepalive.

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

The ALTO working group had a similar issue, i.e., reusing the HTTP error 
codes for the actual ALTO protocol, and it turned out that there is the 
need to have two levels of error codes. The HTTP ones for the HTTP level 
(which is the actual transport) and ALTO (our in our case tracker) 
specific error codes.

Both levels may not match in their error conditions. For instance, the 
HTTP request response pair may be completed successfully (no HTTP syntax 
errors, correct URIl, etc), but the tracker protocol itself may run into 
an error condition (e.g., swarm not found).

Thanks and see you at the meeting

   Martin