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

From: Martin Stiemerling <[email-masked]>
Date: Wed, 9 Nov 2011 14:46:13 +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

[email-masked]<mailto:[email-masked]>

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> 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)
[email-masked]<x-msg://127/[email-masked]>
[email-masked]<x-msg://127/[email-masked]>
[email-masked]<x-msg://127/[email-masked]>
www.ieee-pt.org<http://www.ieee-pt.org/>
Advancing technology for humanity.

On 31/10/2011, at 11:22, [email-masked]<mailto:[email-masked]> 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

---

From: Rui Cruz <[email-masked]>
Date: Thu, 10 Nov 2011 11:55:00 +0000

Hi Martin,

Please read inline my comments.

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
[email-masked] 
[email-masked]
[email-masked]
www.ieee-pt.org

> -          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 inform…

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…

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

> 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 in…

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
>  
> [email-masked]
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Cruz
> [email-masked] 
> [email-masked]
> [email-masked]
> www.ieee-pt.org
> On 31/10/2011, at 11:22, [email-masked] wrote:
> 
> 
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: Martin Stiemerling <[email-masked]>
Date: Sun, 13 Nov 2011 03:45:07 +0100

Hi Rui,

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

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