Subject: Re: [ppsp] Reviewing the tracker protocol

From: Rui Cruz <[email-masked]>
Date: Wed, 10 Jul 2013 13:12:41 +0100

Hi Yunfei,

Many Thanks for your review.

On your comments, they were really helpful, and provided a good guidance for the changes.
The new version of the draft will be published this week, after review by all authors, but before the cutoff date.

Please read inline answers to your comments.

Regards,

Rui Cruz
[email-masked]

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

On 10/06/2013, at 10:50, yunfei zhang <[email-masked]> wrote:

> Hi All,
>    I have reviewed the tracker protocol draft and here is my comments:
> 
> Overall: I think this draft is on the right way of a RFC. Implementors can write most of the codes on the communication bw peers and trackers according to the draft. There are clear examples on the syntax and semantics for reference.

RSC: Those are good news indeed.
> 
> Comments:
> 1.Abstrct: Since the main body doesn't invlove in different messages in either adaptive multi-rate, layered (scalable) or multi-view (3D) videos scenarios and this is mainly on different metadata out of scope of this draft, it's better to remove the related description in the abstract (See more in comment #16).
RSC: The last sentence just highlights that PPSP (tracker) protocol enables peers to form content streaming overlay networks supporting near real-time media content delivery, whichever the "encoding structure" these contents might have, and then lists examples. Appendix C, is just tutorial, clarifying the different  video "encoding structures" supported. However, I agree that a draft should be issued with descriptions of use cases, but detailed, and I intend to do so.

> 2.Terminology:
>   a)Adaptive Streaming: "...for the same streaming session" is a little bit confusing. Do you mean in a same viewing or just the same streaming content?
RSC: corrected and moved to Appendix C
>   b)Chunk: The definition in the Problem statement has been updated according to the review. 
RSC: Updated
>   c)Definition related to presentation: Since the discussion of adaptive multi-rate, layered (scalable)
>    and multi-view (3D) videos scenarios is in the appendix, it seems better to move them in the appendix.
RSC: moved to Appendix C
>   d) Media component: It seems not so clear on the definition.
RSC: moved to Appendix C
>   e)peer-ID: There is a missing ","after IP address.
RSC: Corrected
>   f) PPSP:The definition in the Problem statement has been updated according to the review. 
RSC: Updated
>   g) Scalable Streaming: MVC is not explained clearly like SVC and MDC.
RSC: MVC description enhanced and the term "Scalable Streaming" was moved to Appendix C. 
>   h) Segment: Is it same as Chunk? Do we need the definition of Segement-ID?
RSC: Definition of SEGMENT clarified. A new term, "SEGMENT CHUNK" was added to Terminology. 
>   i) Tracker:The conception of "channel" is not explained.
RSC: Definition of Tracker modified to follow Problem Statement definition.
> 3.Enrollment and Bootstrap:
>    1)Since more roles like player and portal are introduced, it's better to move the description on these roles,e.g., the relationship bw client media player and the peer, currently in appendix, into this part.
RSC: Descriptions of CLIENT MEDIA PLAYER and SERVICE PORTAL were added in section 2.1
>    2) It's better to clarify that Portal+ MPD file is not the only means to locate the tracker.
RSC: The first paragraph of section 2.1 was modified to clarify that the exemplified methods are "not exhaustive".
> 4.section 2.3, PPSP-TP should be present in the terminology.
RSC: A new term "PPSP-TP" added to Terminology
> 5.Section 2.3.2, in the CONNECT part:
>    a) When a peer registers in the tracker, it may not ask any swarm; 
RSC: The base tracker protocol requires the presence of SWARM ID in the connect message, meaning that a swarm action is mandatory. if the connect message does not ask swarm actions of join and/or leave and the peer is not yet registered, it is an error condition, as described in section 4.1.
>    b) Peer IP addresses is not sufficient to locate a peer;
RSC: The CONNECT message contains PEER ID, peer (ip) addresses and other associate information as described in TABLE 3. What is the other information that is still required to locate a peer? can you give an example? 
Anyway, some text was added to the description of CONNECT to stress that peer location information is also handled by the tracker.
>    c) Doesn't the peer registers the Peer mode type informationl?
RSC: description of CONNECT was complemented with that information.
> 6. P13, Para2,"each Peer-ID is modeled" or "each peer is modeled"?
RSC: OK, leaving just "peer" is better.
> 7.Section 2.4.1,4)When Tracking, is there a need to send again a "CONNECT"?
RSC:  In the base tracker protocol there is only one "ACTION SIGNAL" message, the CONNECT. The other message is not for actions but for information exchange.
While a peer is beeing tracked (in TRACKING STATE), to LEAVE a swarm or JOIN a swarm it is required to send a CONNECT message.
> 8. How to convey the SM state information to the tracker?
RSC: The state machine and flow diagram is inner implementation of the tracker.
> 
> 9.Section 3.1, transaction-ID is not explained in terminology part.
RSC: Definition of TRANSACTION ID added to Terminology.
> 10. Table 2, it's suggested to add the attribute "battery power"for mobile peers.
RSC: "battery power" is a mobile specific attribute, not generic. Attributes considered of interest can be added by a "request-response extension" of the protocol as described in section 7.1
> 
> 11.Section 4.1, it's better to limit the maximum number of the peers in the peerlist to avoild DoS attack or maliciously getting the whole picture of the active peers in short time for profit.
RSC: A limit of 30 entries was introduced. This limit allows a PEER LIST to fit a single datagram, when using binary encoding.
> 12. P29,Are PEER REGISTERED and TRACKING states in the tracker or peers?
RSC: The state machine is of the Tracker
> 
> 13. Section 6.4, it's not clear about pro-incentive parameter.Needs more descrption.
RSC: Complementary information was added in section 6.4.
> 14.In the security part, the maclious action of asking peer-list with large amount of peers should be noted.
RSC: PEER LIST requests and PEER LIST sizes returned by the Tracker are limited to a maximum of 30 entries (30 peers) 
> 15.Appedix B1, the Authorization header field is not present in the example. And this mechanism should be highlighted.
RSC: The example in Appendix B contains the field Authorization:

   <Method> /<Resource> HTTP/1.1
   Host: <Host>
   Content-Lenght: <ContentLenght>
   Content-Type: <ContentType>
   Authorization: <AuthToken>

   [Request_Body]  

> 16. It's better to have sperate drafts to discuss Appedix C.
RSC: Agreed. Appendix C is given as a simple example. Separate drafts can describe in detail the Use Scenarios.
> 17. Does OAth 2.0 well suit the authentication bw tracker and peers? I understand that oAuth is best suited in 3rd-party application authorization,not authentication. Am I right?
RSC: An HTTP Basic authentication scheme, as defined in [RFC2617] can be used, or any other suitable/supported authentication method, as described in  [RFC6749].
> BR
> Yunfei

---

From: yunfei zhang <[email-masked]>
Date: Wed, 10 Jul 2013 22:39:46 +0800

Hi Rui,
   Please see inline.

BR
Yunfei

2013/7/10 Rui Cruz <[email-masked]>

> *Overall:* I think this draft is on the right way of a RFC. Implementors
> can write most of the codes on the communication bw peers and trackers
> according to the draft. There are clear examples on the syntax and
> semantics for reference.
>
>
> *Comments:*
> *1.Abstrct:* Since the main body doesn't invlove in different messages in
> either adaptive multi-rate, layered (scalable) or multi-view (3D) videos
> scenarios and this is mainly on different metadata out of scope of this
> draft, it's better to remove the related description in the abstract (See
> more in comment #16).
>
> RSC: The last sentence just highlights that PPSP (tracker) protocol
> enables peers to form content streaming overlay networks supporting near
> real-time media content delivery, whichever the "encoding structure" these
> contents might have, and then lists examples. Appendix C, is just tutorial,
> clarifying the different  video "encoding structures" supported. However, I
> agree that a draft should be issued with descriptions of use cases, but
> detailed, and I intend to do so.
>
> *2.Terminology:*
>   a)Adaptive Streaming: "...for the same streaming session" is a little
> bit confusing. Do you mean in a same viewing or just the same streaming
> content?
>
> *3.Enrollment and Bootstrap:*
>    1)Since more roles like player and portal are introduced, it's better
> to move the description on these roles,e.g., the relationship bw client
> media player and the peer, currently in appendix, into this part.
>
> RSC: The first paragraph of section 2.1 was modified to clarify that the
> exemplified methods are "not exhaustive".
>
> RSC: The base tracker protocol requires the presence of SWARM ID in the
> connect message, meaning that a *swarm action is mandatory*. if the
> connect message does not ask swarm actions of join and/or leave and the
> peer is not yet registered, it is an error condition, as described in
> section 4.1.
>
> RSC: The CONNECT message contains PEER ID, peer (ip) addresses and other
> associate information as described in TABLE 3. What is the other
> information that is still required to locate a peer? can you give an
> example?
> Anyway, some text was added to the description of CONNECT to stress that
> peer location information is also handled by the tracker.
>
【Yunfei】 That would be fine.

> RSC:  In the base tracker protocol there is only one "ACTION SIGNAL"
> message, the CONNECT. The other message is not for actions but for
> information exchange.
> While a peer is beeing tracked (in TRACKING STATE), to LEAVE a swarm or
> JOIN a swarm it is required to send a CONNECT message.
>
> RSC: "battery power" is a mobile specific attribute, not generic.
> Attributes considered of interest can be added by a "request-response
> extension" of the protocol as described in section 7.1
>
> 11.Section 4.1, it's better to limit the maximum number of the peers in
> the peerlist to avoild DoS attack or maliciously getting the whole picture
> of the active peers in short time for profit.
>
> RSC: A limit of 30 entries was introduced. This limit allows a PEER
> LIST to fit a single datagram, when using binary encoding.
>
> RSC: PEER LIST requests and PEER LIST sizes returned by the Tracker are
> limited to a maximum of 30 entries (30 peers)
>
> 15.Appedix B1, the Authorization header field is not present in the
> example. And this mechanism should be highlighted.
>
> 17. Does OAth 2.0 well suit the authentication bw tracker and peers? I
> understand that oAuth is best suited in 3rd-party application
> authorization,not authentication. Am I right?
>
> RSC: An HTTP Basic authentication scheme, as defined in [RFC2617] can be
> used, or any other suitable/supported authentication method, as described
> in  [RFC6749].
>
>
> BR
> Yunfei
>
>
>